深入了解嵌入式编程

能从PC机器编程去看嵌入式问题，那是第一步；学会用嵌入式编程思想，那是第二步；用PC的思想和嵌入式的思想结合在一起，应用于实际的项目，那是第三步。很多朋友都是从PC编程转向嵌入式编程的。在中国，嵌入式编程的朋友很少是正儿八经从计算机专业毕业的，都是从自动控制啊，电子相关的专业毕业的。这些童鞋们，实践经验雄厚，但是理论知识缺乏；计算机专业毕业的童鞋很大一部分去弄网游、网页这些独立于操作系统的更高层的应用了。也不太愿意从事嵌入式行业，毕竟这条路不好走。他们理论知识雄厚，但缺乏电路等相关的知识，在嵌入式里学习需要再学习一些具体的知识，比较难走。虽然没有做过产业调查，但从我所见和所招聘人员，从事嵌入式行业的工程师，要么缺乏理论知识，要么缺乏实践经验。很少两者兼备的。究其原因，还是中国的大学教育的问题。这里不探讨这个问题，避免口水战。我想列出我实践中的几个例子。引起大家在嵌入式中做项目时对一些问题的关注。第一个问题：同事在uC/OS-II下开发一个串口的驱动程序，驱动和接口在测试中均为发现问题。应用中开发了个通讯程序，串口驱动提供了一个查询驱动缓冲区字符的函数：GetRxBuffCharNum()。 高层需要接受一定数量的字符以后才能对包做解析。一个同事撰写的代码，用伪代码表示如下：bExit = FALSE;do {    if (GetRxBuffCharNum() >= 30)           bExit = ReadRxBuff(buff, GetRxBuffCharNum());} while (!bExit);这段代码判断当前缓冲区中超过30个字符，就将缓冲区中全部字符读到缓冲区中，直到读取成功为止。逻辑清楚，思路也清楚。但这段代码是不能正常工作。如果是在PC机上，定然是没有任何问题，工作的异常正常。但在嵌入式里真的是不得而知了。同事很郁闷，不知道为什么。来请我解决问题，当时我看到代码，就问了他，GetRxBuffCharNum()是怎么实现的？打开一看：unsigned GetRxBuffCharNum(void){    cpu_register reg;    unsigned num;    reg = interrupt_disable();    num = gRxBuffCharNum;    interrupt_enable(reg);    return (num);}很明显，由于在循环中，interruput_disable()和interrupt_enable()之间是个全局临界区域，保证gRxBufCharNum的完整性。但是，由于在外层的do { } while() 循环中，CPU频繁的关闭中断，打开中断，这个时间非常的短。实际上CPU可能不能正常的响应UART的中断。当然这和uart的波特率、硬件缓冲区的大小还有CPU的速度都有关系。我们使用的波特率非常高，大约有3Mbps。uart起始信号和停止信号占一个比特位。一个字节需要消耗10个周期。3Mbps的波特率大约需要3.3us传输一个字节。3.3us能执行多少个CPU指令呢？100MHz的ARM，大约能执行150条指令左右。结果关闭中断的时间是多长呢？一般ARM关闭中断都需要4条以上的指令，打开又有4条以上的指令。接收uart中断的代码实际上是不止20条指令的。所以，这样下来，就有可能出现丢失通信数据的Bug，体现在系统层面上，就是通信不稳定。修改这段代码其实很简单，最简单的办法是从高层修改。即：bExit = FALSE;do {    DelayUs(20); //延时 20us，一般采用空循环指令实现    num = GetRxBuffCharNum();    if (num > 能从PC机器编程去看嵌入式问题，那是第一步；学会用嵌入式编程思想，那是第二步；用PC的思想和嵌入式的思想结合在一起，应用于实际的项目，那是第三步。很多朋友都是从PC编程转向嵌入式编程的。在中国，嵌入式编程的朋友很少是正儿八经从计算机专业毕业的，都是从自动控制啊，电子相关的专业毕业的。这些童鞋们，实践经验雄厚，但是理论知识缺乏；计算机专业毕业的童鞋很大一部分去弄网游、网页这些独立于操作系统的更高层的应用了。也不太愿意从事嵌入式行业，毕竟这条路不好走。他们理论知识雄厚，但缺乏电路等相关的知识，在嵌入式里学习需要再学习一些具体的知识，比较难走。虽然没有做过产业调查，但从我所见和所招聘人员，从事嵌入式行业的工程师，要么缺乏理论知识，要么缺乏实践经验。很少两者兼备的。究其原因，还是中国的大学教育的问题。这里不探讨这个问题，避免口水战。我想列出我实践中的几个例子。引起大家在嵌入式中做项目时对一些问题的关注。第一个问题：同事在uC/OS-II下开发一个串口的驱动程序，驱动和接口在测试中均为发现问题。应用中开发了个通讯程序，串口驱动提供了一个查询驱动缓冲区字符的函数：GetRxBuffCharNum()。 高层需要接受一定数量的字符以后才能对包做解析。一个同事撰写的代码，用伪代码表示如下：bExit = FALSE;do {    if (GetRxBuffCharNum() >= 30)           bExit = ReadRxBuff(buff, GetRxBuffCharNum());} while (!bExit);这段代码判断当前缓冲区中超过30个字符，就将缓冲区中全部字符读到缓冲区中，直到读取成功为止。逻辑清楚，思路也清楚。但这段代码是不能正常工作。如果是在PC机上，定然是没有任何问题，工作的异常正常。但在嵌入式里真的是不得而知了。同事很郁闷，不知道为什么。来请我解决问题，当时我看到代码，就问了他，GetRxBuffCharNum()是怎么实现的？打开一看：unsigned GetRxBuffCharNum(void){    cpu_register reg;    unsigned num;    reg = interrupt_disable();    num = gRxBuffCharNum;    interrupt_enable(reg);    return (num);}很明显，由于在循环中，interruput_disable()和interrupt_enable()之间是个全局临界区域，保证gRxBufCharNum的完整性。但是，由于在外层的do { } while() 循环中，CPU频繁的关闭中断，打开中断，这个时间非常的短。实际上CPU可能不能正常的响应UART的中断。当然这和uart的波特率、硬件缓冲区的大小还有CPU的速度都有关系。我们使用的波特率非常高，大约有3Mbps。uart起始信号和停止信号占一个比特位。一个字节需要消耗10个周期。3Mbps的波特率大约需要3.3us传输一个字节。3.3us能执行多少个CPU指令呢？100MHz的ARM，大约能执行150条指令左右。结果关闭中断的时间是多长呢？一般ARM关闭中断都需要4条以上的指令，打开又有4条以上的指令。接收uart中断的代码实际上是不止20条指令的。所以，这样下来，就有可能出现丢失通信数据的Bug，体现在系统层面上，就是通信不稳定。修改这段代码其实很简单，最简单的办法是从高层修改。即：bExit = FALSE;do {    DelayUs(20); //延时 20us，一般采用空循环指令实现    num = GetRxBuffCharNum();    if (num >= 30)        bExit = ReadRxBuff(buff, num);} while (!bExit);这样，让CPU有时间去执行中断的代码，从而避免了频繁关闭中断造成的中断代码执行不及时，产生的信息丢失。在嵌入式系统里，大部分的RTOS应用都是不带串口驱动。自己设计代码时，没有充分考虑代码与内核的结合。造成代码深层次的问题。RTOS之所以称为RTOS，就是因为对事件的快速响应；事件快速的响应依赖于CPU对中断的响应速度。驱动在Linux这种系统中都是与内核高度整合，一起运行在内核态。RTOS虽然不能抄袭linux这种结构，但有一定的借鉴意义。从上面的例子可以看清楚，嵌入式需要开发人员对代码的各个环节需要了解清楚。第二个例子：同事驱动一个14094串转并的芯片。串行信号是采用IO模拟的，因为没有专用的硬件。同事就随手写了个驱动，结果调试了3、4天，仍旧是有问题。我实在看不下去了，就去看了看，控制的并行信号有时候正常有时候不正常。我看了看代码，用伪代码大概是：for (i = 0; i < 8; i++){    SetData((data >> i) & 0x1);    SetClockHigh();    for (j = 0; j < 5; j++);    SetClockLow();}将数据的8个bit在每个高电平从bit0到bit7依次发送出去。应该是正常的啊。看不出问题在哪啊？我仔细想了想，有看了14094的datasheet，明白了。原来，14094要求clock的高电平持续10个ns，低电平也要持续10个ns。这段代码之做了高电平时间的延时，没有做低电平的延时。如果中断插在低电平之间工作，那么这段代码是可以的。但是如果CPU没有中断插在低电平时执行，则是不能正常工作的。所以就时好时坏。修改也比较简单：for (i = 0; i < 8; i++){    SetData((data >> i) & 0x1);    SetClockHigh();    for (j = 0; j < 5; j++);    SetClockLow();    for (j = 0; j < 5; j++);}这样就完全正常了。但是这个还是不能很好移植的一个代码，因为编译器一优化，就有可能造成这两个延时循环的丢失。丢失了，就不能保证高电平低电平持续10ns的要求，也就不能正常工作了。所以，真正的可以移植的代码，应该把这个循环做成一个纳秒级的DelayNs(10);像Linux一样，上电时，先测量一下，nop指令执行需要多长时间执行，多少个nop指令执行10ns。执行一定的nop指令就可以了。利用编译器防止优化的编译指令或者特殊的关键字，防止延时循环被编译器优化掉。如GCC中的__volatile__ __asm__("nop;\n");从这个例子中可以清楚的看到，写好一段好代码，是需要很多知识支撑的。你说呢？嵌入式往往没有操作系统支撑，或者因为有操作系统支撑，但因为种种的限制，操作系统提供的功能少得可怜。所以，很多代码不能像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 定然给一个无定义指令的错误。引起程序员的重视。在嵌入式里，全部都留给了程序员去寻找了。内存溢出发生在任何一个不经意的时刻，你给整个前后台的系统(或操作系统)分配了多大的堆？多大的栈？在通常情况下系统的调用深度是多少(最大是多少)，占用多少栈？光看程序的功能正确还不够，还需要统计这些参数。不然，只要有一个地方有溢出。对系统都是致命的。嵌入式系统要求系统连续工作时间长，稳定性可靠性要求苛刻。是需要一些时间仔细的磨这些系统的。