上次聊了一下嵌入式编程的复杂性,很多朋友们在我QQ上留言。很感谢大家,关于嵌入式编程的复杂性话题,还有很多内容,这里再和大家继续上次的话题随便说说。


嵌入式往往没有操作系统支撑,或者因为有操作系统支撑,但因为种种的限制,操作系统提供的功能少得可怜。所以,很多代码不能像PC编程那样天马行空,任意驰骋。今天就聊聊内存分配的问题,内存碎片,可能大家都不陌生。然而在嵌入式系统里,最怕的就是内存碎片,也是系统稳定的头号杀手。我曾经做了一个项目,系统中有很多的malloc和free,尺寸不一,从60多个字节到64KB的不等。使用一款RTOS作为支撑。当时我有两个选择,一个是使用C系统库的malloc和free,另外一个是使用操作系统提供的固定内存分配。我们系统的设计要求要能稳定运行3个月以上。实际上连续运行6天左右就宕机了。各种问题都怀疑过,最后定为在内存分配上,其实就是长时间,大量的内存分配后,系统的内存变得零散而无法连续。虽有大空间,但却无法分配连续的空间。当有大空间申请时,只能是宕机完蛋。为了使系统达到原先的设计需求,我们在PC机上模拟了整个硬件,将嵌入式代码在 PC机上跑起来,并重载了malloc和free,做了个复杂的统计程序。统计系统的内存行为。运行了若干天以后,将数据提取出来分析,虽然申请的内存5花八门,还是有些规律,我们把100个字节以下的归为一类,512B的归为一类,1KB的归为一类,2KB归为一类,64KB一下归为一类。统计出每类的数量,在原先的基础上加上30%的余量。做成固定内存申请,使得系统稳定连续运行的时间大大加长。嵌入式就这样,不怕方法原始,就怕性能不达要求。



内存溢出问题,内存溢出问题嵌入式系统比PC系统更可怕! 往往是没有察觉的就溢出了。都很难想到,尤其是C/C++的初学者,对指针不熟悉,查都没法查。由于PC系统有MMU,内存发生严重的越界时,有MMU的保护,不会产生严重的灾难后果。而嵌入式往往没有MMU,差别很大,系统代码都被破坏了还能跑。只是只有上帝和那个CPU才知道跑得是什么。我们来看看这段代码:


char  *strcpy(char *dest, const char * src)

{

           assert(dest != NULL && src != NULL);

           while (*src != '\0')

          {

                   *dest++ = *src++;

          }

          *dest = '\0';

         return (dest);

}

这个代码是一个字符串拷贝的代码,PC机这样写,基本上就可以了。但嵌入式要提防一件事情,那就是 src真的以'\0'结束的。要不是得话,那就悲剧了。到什么时候能结束,呵呵,只有上帝老人家才知道。这段代码侥幸能跑完成的话,估计也别想程序能正常的跑了。因为dest指向的内存区域都被破坏的差不多了。为了和标准C/C++的库兼容,还真的没什么好办法,所以这个问题只能留给程序员自己检查。


相同的,

memcpy( dest, src, n);

内存拷贝同样的问题,要提防n传递个负值进去。这个是拷贝多少个字节,负值被强制类型转换成正的。变成一个很大的正数,造成dest之后的内存全部被破坏……


嵌入式里的内存指针必须做严格的检查才能使用,内存的尺寸也必须进行严格的调试。不然的话,悲剧是很难避免的。如一个函数指针,虽然在嵌入式里赋了个NULL,0。若是ARM的话,连个异常错误都没有,直接复位了,因为调用这个函数指针即便是让代码从0开始运行。而0是ARM上电后运行的第一条代码的位置。在ARM7上尤其如此。这种悲剧比PC上悲情多了,MMU 定然给一个无定义指令的错误。引起程序员的重视。在嵌入式里,全部都留给了程序员去寻找了。


内存溢出发生在任何一个不经意的时刻,你给整个前后台的系统(或操作系统)分配了多大的堆?多大的栈?在通常情况下系统的调用深度是多少(最大是多少),占用多少栈?光看程序的功能正确还不够,还需要统计这些参数。不然,只要有一个地方有溢出。对系统都是致命的。嵌入式系统要求系统连续工作时间长,稳定性可靠性要求苛刻。是需要一些时间仔细的磨这些系统的。


欢迎将您身边发生的嵌入式编程的复杂的例子给我。和我一起探讨嵌入式的复杂性。谢谢。