能从PC机器编程去看嵌入式问题,那是第一步;
学会用嵌入式编程思想,那是第二步;
用PC的思想和嵌入式的思想结合在一起,应用于实际的项目,那是第三步。
很多朋友都是从PC编程转向嵌入式编程的。
在中国,嵌入式编程的朋友很少是正儿八经从计算机专业毕业的,都是从自动控制,电子相关的专业毕业的。
这些童鞋们,实践经验雄厚,但是理论知识缺乏;计算机专业毕业的童鞋很大一部分去弄网游、网页这些独立于操作系统的更高层的应用了。
也不太愿意从事嵌入式行业,毕竟这条路不好走。他们理论知识雄厚,但缺乏威廉希尔官方网站 等相关的知识,在嵌入式里学习需要再学习一些具体的知识,比较难走。
虽然没有做过产业调查,但从我所见和所招聘人员,从事嵌入式行业的工程师,要么缺乏理论知识,要么缺乏实践经验。
很少两者兼备的。究其原因,还是中国的大学教育的问题。这里不探讨这个问题,避免口水战。我想列出我实践中的几个例子。引起大家在嵌入式中做项目时对一些问题的关注。
第一个例子:
同事在uC/OS-II下开发一个串口的驱动程序,驱动和接口在测试中均未发现问题。应用中开发了个通讯程序,串口驱动提供了一个查询驱动缓冲区字符的函数:GetRxBuffCharNum()。
应用层需要接收一定数量的字符以后才能对包做解析。一个同事撰写的代码,用伪代码表示如下:
![图片](https://mmbiz.qpic.cn/mmbiz_png/K9mVOHgVt7xewibMy12Xyg6ahGaXF216WBnC60QicfdbvYtZu2nfxeUzyeyibW5yvCfrRGUIJ0HV0SmNS5oCjdvqg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
这段代码判断当前缓冲区中超过30个字符,就将缓冲区中全部字符读到缓冲区中,直到读取成功为止。
逻辑清楚,思路也清楚。但这段代码是不能正常工作。如果是在PC机上,定然是没有任何问题,工作很正常。但在嵌入式里真的是不得而知了。同事很郁闷,不知道为什么。
来请我解决问题,当我看到代码时,就问了他,GetRxBuffCharNum()是怎么实现的?打开一看:
![图片](https://mmbiz.qpic.cn/mmbiz_png/K9mVOHgVt7xewibMy12Xyg6ahGaXF216WDOcJiao8ibNdDFYvpZ4zzvC5x03IoFOFV81mjLTUDBuDFzFznPTGiacFQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
很明显,由于在循环中,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,体现在系统层面上,就是通信不稳定。
修改这段代码其实很简单,最简单的办法是从高层修改。即:
![图片](https://mmbiz.qpic.cn/mmbiz_png/K9mVOHgVt7xewibMy12Xyg6ahGaXF216Wvvn6bP7CGoPX9bwaSkA4gfcJCnhLAKiaIVvg63icGlliaUIsbYMmGzsMA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
这样,让CPU有时间去执行中断的代码,从而避免了频繁关闭中断造成的中断代码执行不及时,产生的信息丢失。
在嵌入式系统里,大部分的RTOS应用都是不带串口驱动。自己设计代码时,没有充分考虑代码与内核的结合。会造成代码深层次的问题。
RTOS之所以称为RTOS,就是因为对事件的快速响应;事件快速的响应依赖于CPU对中断的响应速度。
驱动在Linux这种系统中都是与内核高度整合,一起运行在内核态。RTOS虽然不能抄袭linux这种结构,但有一定的借鉴意义。
从上面的例子可以看清楚,嵌入式需要开发人员对代码的各个环节需要了解清楚。
第二个例子:
同事驱动一个14094串转并的芯片。串行信号是采用IO模拟的,因为没有专用的硬件。同事就随手写了个驱动,结果调试了3、4天,仍旧是有问题。
我实在看不下去了,就去看了看,控制的并行信号有时候正常有时候不正常。我看了看代码,用伪代码大概是:
![图片](https://mmbiz.qpic.cn/mmbiz_png/K9mVOHgVt7xewibMy12Xyg6ahGaXF216Wf7ZeC3OdVhMeXweiaLZDfVicgrMxmF4L8yiaB1Av1eEbz7cTFibJ8A7u0w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
将数据的8个bit在每个高电平从bit0到bit7依次发送出去。应该是正常的啊。看不出问题在哪啊?
我仔细想了想,又看了14094 的datasheet,明白了。
原来,14094 要求 clock 的高电平持续 10个ns,低电平也要持续 10个ns。这段代码只做了高电平时间的延时,没有做低电平的延时。如果中断插在低电平之间工作,那么这段代码是可以的。
但是如果CPU没有中断插在低电平时执行,则是不能正常工作的。所以就时好时坏。
修改也比较简单:
![图片](https://mmbiz.qpic.cn/mmbiz_png/K9mVOHgVt7xewibMy12Xyg6ahGaXF216WcA5Y7oOoAPbTxWCnhNZUjMP3kGgtD9SKfPnVBlCOfExwVpRvCJYfBA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
这样就完全正常了。但是这个还是不能很好移植的代码,因为编译器一优化,就有可能造成这两个延时循环的丢失。
丢失了,就不能保证高电平低电平持续10ns的要求,也就不能正常工作了。
所以,真正的可以移植的代码,应该把这个循环做成一个纳秒级的DelayNs(10);
像Linux一样,上电时,先测量一下,nop 指令执行需要多长时间执行,多少个 nop指令执行10ns。
执行一定的nop指令就可以了。利用编译器防止优化的编译指令或者特殊的关键字,防止延时循环被编译器优化掉。如 GCC 中的
volatile asm ("nop;\\n");
从这个例子中可以清楚的看到,写好一段好代码,是需要很多知识支撑的。你说呢?
全部0条评论
快来发表一下你的评论吧 !