能從PC機(jī)器編程去看嵌入式問題，那是第一步；

學(xué)會(huì)用嵌入式編程思想，那是第二步；

用PC的思想和嵌入式的思想結(jié)合在一起，應(yīng)用于實(shí)際的項(xiàng)目，那是第三步。

很多朋友都是從PC編程轉(zhuǎn)向嵌入式編程的。

在中國，嵌入式編程的朋友很少是正兒八經(jīng)從計(jì)算機(jī)專業(yè)畢業(yè)的，都是從自動(dòng)控制，電子相關(guān)的專業(yè)畢業(yè)的。

這些童鞋們，實(shí)踐經(jīng)驗(yàn)雄厚，但是理論知識(shí)缺乏；計(jì)算機(jī)專業(yè)畢業(yè)的童鞋很大一部分去弄網(wǎng)游、網(wǎng)頁這些獨(dú)立于操作系統(tǒng)的更高層的應(yīng)用了。

也不太愿意從事嵌入式行業(yè)，畢竟這條路不好走。他們理論知識(shí)雄厚，但缺乏電路等相關(guān)的知識(shí)，在嵌入式里學(xué)習(xí)需要再學(xué)習(xí)一些具體的知識(shí)，比較難走。

雖然沒有做過產(chǎn)業(yè)調(diào)查，但從我所見和所招聘人員，從事嵌入式行業(yè)的工程師，要么缺乏理論知識(shí)，要么缺乏實(shí)踐經(jīng)驗(yàn)。

很少兩者兼?zhèn)涞?。究其原因，還是中國的大學(xué)教育的問題。這里不探討這個(gè)問題，避免口水戰(zhàn)。我想列出我實(shí)踐中的幾個(gè)例子。引起大家在嵌入式中做項(xiàng)目時(shí)對(duì)一些問題的關(guān)注。

第一個(gè)例子：

同事在uC/OS-II下開發(fā)一個(gè)串口的驅(qū)動(dòng)程序，驅(qū)動(dòng)和接口在測(cè)試中均未發(fā)現(xiàn)問題。應(yīng)用中開發(fā)了個(gè)通訊程序，串口驅(qū)動(dòng)提供了一個(gè)查詢驅(qū)動(dòng)緩沖區(qū)字符的函數(shù)：GetRxBuffCharNum()。

應(yīng)用層需要接收一定數(shù)量的字符以后才能對(duì)包做解析。一個(gè)同事撰寫的代碼，用偽代碼表示如下：

![圖片](https://mmbiz.qpic.cn/mmbiz_png/K9mVOHgVt7xewibMy12Xyg6ahGaXF216WBnC60QicfdbvYtZu2nfxeUzyeyibW5yvCfrRGUIJ0HV0SmNS5oCjdvqg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)

這段代碼判斷當(dāng)前緩沖區(qū)中超過30個(gè)字符，就將緩沖區(qū)中全部字符讀到緩沖區(qū)中，直到讀取成功為止。

邏輯清楚，思路也清楚。但這段代碼是不能正常工作。如果是在PC機(jī)上，定然是沒有任何問題，工作很正常。但在嵌入式里真的是不得而知了。同事很郁悶，不知道為什么。

來請(qǐng)我解決問題，當(dāng)我看到代碼時(shí)，就問了他，GetRxBuffCharNum()是怎么實(shí)現(xiàn)的？打開一看：

![圖片](https://mmbiz.qpic.cn/mmbiz_png/K9mVOHgVt7xewibMy12Xyg6ahGaXF216WDOcJiao8ibNdDFYvpZ4zzvC5x03IoFOFV81mjLTUDBuDFzFznPTGiacFQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)

很明顯，由于在循環(huán)中，interruput_disable() 和 interrupt_enable() 之間是個(gè)全局臨界區(qū)域，保證 gRxBufCharNum 的完整性。

但是，由于在外層的do { } while() 循環(huán)中，CPU頻繁地關(guān)閉中斷，打開中斷，這個(gè)時(shí)間非常的短。

實(shí)際上CPU也許會(huì)不能正常地響應(yīng)UART的中斷。當(dāng)然這和uart的波特率、硬件緩沖區(qū)的大小還有CPU的速度都有關(guān)系。我們使用的波特率非常高，大約有3Mbps。

uart起始信號(hào)和停止信號(hào)占一個(gè)比特位。一個(gè)字節(jié)需要消耗10個(gè)周期。3Mbps的波特率大約需要3.3us傳輸一個(gè)字節(jié)。

通過分析波形，透徹理解 UART 通信

3.3us能執(zhí)行多少個(gè)CPU指令呢？

100MHz的ARM，大約能執(zhí)行150條指令左右。關(guān)閉中斷的時(shí)間是多長(zhǎng)呢？一般ARM關(guān)閉中斷都需要 4 條以上的指令，打開又有 4 條以上的指令。

接收 uart 中斷的代碼實(shí)際上是不止 20 條指令的。所以，這樣下來，就有可能出現(xiàn)丟失通信數(shù)據(jù)的Bug，體現(xiàn)在系統(tǒng)層面上，就是通信不穩(wěn)定。

修改這段代碼其實(shí)很簡(jiǎn)單，最簡(jiǎn)單的辦法是從高層修改。即：

![圖片](https://mmbiz.qpic.cn/mmbiz_png/K9mVOHgVt7xewibMy12Xyg6ahGaXF216Wvvn6bP7CGoPX9bwaSkA4gfcJCnhLAKiaIVvg63icGlliaUIsbYMmGzsMA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)

這樣，讓CPU有時(shí)間去執(zhí)行中斷的代碼，從而避免了頻繁關(guān)閉中斷造成的中斷代碼執(zhí)行不及時(shí)，產(chǎn)生的信息丟失。

在嵌入式系統(tǒng)里，大部分的RTOS應(yīng)用都是不帶串口驅(qū)動(dòng)。自己設(shè)計(jì)代碼時(shí)，沒有充分考慮代碼與內(nèi)核的結(jié)合。會(huì)造成代碼深層次的問題。

RTOS之所以稱為RTOS，就是因?yàn)閷?duì)事件的快速響應(yīng)；事件快速的響應(yīng)依賴于CPU對(duì)中斷的響應(yīng)速度。

驅(qū)動(dòng)在Linux這種系統(tǒng)中都是與內(nèi)核高度整合，一起運(yùn)行在內(nèi)核態(tài)。RTOS雖然不能抄襲linux這種結(jié)構(gòu)，但有一定的借鑒意義。

從上面的例子可以看清楚，嵌入式需要開發(fā)人員對(duì)代碼的各個(gè)環(huán)節(jié)需要了解清楚。

第二個(gè)例子：

同事驅(qū)動(dòng)一個(gè)14094串轉(zhuǎn)并的芯片。串行信號(hào)是采用IO模擬的，因?yàn)闆]有專用的硬件。同事就隨手寫了個(gè)驅(qū)動(dòng)，結(jié)果調(diào)試了3、4天，仍舊是有問題。

我實(shí)在看不下去了，就去看了看，控制的并行信號(hào)有時(shí)候正常有時(shí)候不正常。我看了看代碼，用偽代碼大概是：

![圖片](https://mmbiz.qpic.cn/mmbiz_png/K9mVOHgVt7xewibMy12Xyg6ahGaXF216Wf7ZeC3OdVhMeXweiaLZDfVicgrMxmF4L8yiaB1Av1eEbz7cTFibJ8A7u0w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)

將數(shù)據(jù)的8個(gè)bit在每個(gè)高電平從bit0到bit7依次發(fā)送出去。應(yīng)該是正常的啊?？床怀鰡栴}在哪??？

我仔細(xì)想了想，又看了14094 的datasheet，明白了。

原來，14094 要求 clock 的高電平持續(xù) 10個(gè)ns，低電平也要持續(xù) 10個(gè)ns。這段代碼只做了高電平時(shí)間的延時(shí)，沒有做低電平的延時(shí)。如果中斷插在低電平之間工作，那么這段代碼是可以的。

但是如果CPU沒有中斷插在低電平時(shí)執(zhí)行，則是不能正常工作的。所以就時(shí)好時(shí)壞。

修改也比較簡(jiǎn)單：

![圖片](https://mmbiz.qpic.cn/mmbiz_png/K9mVOHgVt7xewibMy12Xyg6ahGaXF216WcA5Y7oOoAPbTxWCnhNZUjMP3kGgtD9SKfPnVBlCOfExwVpRvCJYfBA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)

這樣就完全正常了。但是這個(gè)還是不能很好移植的代碼，因?yàn)榫幾g器一優(yōu)化，就有可能造成這兩個(gè)延時(shí)循環(huán)的丟失。

丟失了，就不能保證高電平低電平持續(xù)10ns的要求，也就不能正常工作了。

所以，真正的可以移植的代碼，應(yīng)該把這個(gè)循環(huán)做成一個(gè)納秒級(jí)的DelayNs(10);

像Linux一樣，上電時(shí)，先測(cè)量一下，nop 指令執(zhí)行需要多長(zhǎng)時(shí)間執(zhí)行，多少個(gè) nop指令執(zhí)行10ns。

執(zhí)行一定的nop指令就可以了。利用編譯器防止優(yōu)化的編譯指令或者特殊的關(guān)鍵字，防止延時(shí)循環(huán)被編譯器優(yōu)化掉。如 GCC 中的

volatile asm ("nop;\\n");

從這個(gè)例子中可以清楚的看到，寫好一段好代碼，是需要很多知識(shí)支撐的。你說呢？