经验与教训(1)－－嵌入式开发随笔（dlmu2001）

经验与教训－－嵌入式开发随笔（dlmu2001）

 

1.系统和平台熟悉

 

在一个新的平台上开发或者移植一款软件的时候，首先应该充分平台或者

操作系统的各种属性，这些属性包括但不仅限于：

1)系统的任务调度，任务间的通信机制

任务调度包括是否是多任务实时操作系统，任务以何种方式存在的，如何添加和管理任务？任务间的优先级如何设置？任务间的优先级设置？任务堆栈？任务间的通信机制包括了解系统提供的通信机制，各种通信机制的优劣，通信细节等等。

案例1：

曾经在某一个平台上做一个软件，创建了多个任务，由于各个任务实现者不一样，一个漫不经心的错误造成了本该是高优先级的任务没有在优先级上体现出来，A，B，C，D4个任务，本来应当是A>B>C>D，结果设置成A>C>B>D，为此debug了一上午

教训：1)多方协作开发事先要把优先级定好，书面文档描述

      2)写代码的时候一定要切忌马虎，有时候一些漫不经心的错误会无法估计地增加很多调试时间。即使是测试代码，也要严谨。养成写完代码检查的习惯！

案例2：

代码执行到一个函数突然跑飞，检查函数没有问题，大家都知道，跑飞在嵌入式系统中是很难跟踪定位问题了，只能根据经验不断做实验缩小疑点范围最后发现是该任务堆栈设置太小所致

案例3：

移植一款软件到某一款手机，代码加载上去发现开不了机原因：多个任务的堆栈开销大于系统提供的堆栈资源

2)系统的内存管理

系统采用的是动态内存机制还是静态内存机制，如果是内存分块机制，则需要了解块的划分标准和使用细节。如果是动态内存机制，则需要了解是否有动态内存泄漏的监测工具。在嵌入式系统中，资源是个很大的问题，因此，还需要了解系统总的内存资源是个什么样的情况，本软件或程序又可以使用多大的内存开销。BTW，资源的统计还包括定时器、内务、优先级等。

案例4：

代码执行到某个函数跑飞，该函数由于历史原因是一个嵌套比较深的函数，笔者不是特别熟悉，基本没有用单步，trace或者缩小范围的方法来定位问题。后来想到在熟悉平台的时候做过实验，当申请内存申请不到的情况下，会引起任务挂起。写了段测试代码，果然验证了这个猜测。

教训1)最好不要有多层嵌套的代码啦，非嵌套不可，拜托不要递归，      以上两点恶心行为如果都具备了，那千万不要在里面分配动      态内存，否则十有八九会搞死人

    2)接触一个系统最好是能写个测试程序熟悉一下，不要迷信文档      或者技术支持的话文档里说内存分配失败不会阻塞会返回失败，多次找FAE确认，呵呵，最后还是实践是硬道理啊

案例5：

还是以上的项目，系统是用分块的方式来实现动态内存的，系统还不是特别成熟，分块也不科学，资源又不够用，本来许诺的资源开销满足不了，导致项目到中期要将某些模块的内存分配方式由动态改为静态，还好，一切顺利

教训1)软件应该对内存的分配做出适配，提高可移植性，容易从一种     方式很快地过渡到另一种方式

    2)开始开发前一定要了解系统现有的资源

   

3）编译器选项

如：

有的平台会将char默认为有符号型，有的会默认为无符号型，如果你在代码中将其作为有符号型来使用，编译的时候必须注意这种编译选项，很多编译器都有这种编译选项。否则，程序可能走的流程会跟你的思路不一样

 

高低位字节问题，有的编译器有这种选项，如果代码会收到高低位影响的话，那就要注意了，如果没有这个选项，也要理解编译器的高低位。确定是否要对代码做出适配。

 

4）调试手段

这个不用再说了吧，工欲善其事，必先利其器，后面我们再对调试手段做进一步的探讨

 

5）其它

可能系统有一些特殊的问题，比如奇偶地址对齐的问题，这个一方面要仔细的看文档，一方面要写测试程序做下测试，虽然要花点时间，但是决对是值得的。