|
能從PC機器編程去看嵌入式問題，那是第一步；學會用嵌入式編程思想，那是第二步；用PC的思想和嵌入式的思想結合在一起，應用于實際的項目，那是第三步。很多朋友都是從PC編程轉向嵌入式編程的。在中國，嵌入式編程的朋友很少是正兒八經從計算機專業畢業的，都是從自動控制啊，電子相關的專業畢業的。這些童鞋們，實踐經驗雄厚，但是理論知識缺乏；計算機專業畢業的童鞋很大一部分去弄網游、網頁這些獨立于操作系統的更高層的應用了。也不太愿意從事嵌入式行業，畢竟這條路不好走。他們理論知識雄厚，但缺乏電路等相關的知識，在嵌入式里學習需要再學習一些具體的知識，比較難走。 從事嵌入式行業的工程師，要么缺乏理論知識，要么缺乏實踐經驗。很少兩者兼備的。究其原因，還是中國的大學教育的問題。這里不探討這個問題，避免口水戰。我想列出我實踐中的幾個例子。引起大家在嵌入式中做項目時對一些問題的關注。 01 第一個問題： 同事在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這種結構，但有一定的借鑒意義。 從上面的例子可以看清楚，嵌入式需要開發人員對代碼的各個環節需要了解清楚。 01 第二個例子： 同事驅動一個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"); 從這個例子中可以清楚的看到，寫好一段好代碼，是需要很多知識支撐的。你說呢？ 這真的是一個充滿挑戰的領域。 以下課程可免費試聽C語言、電子、PCB、STM32、Linux、FPGA、JAVA、安卓等。 想學習的你和我聯系預約就可以免費聽課了。 宋工企鵝號：3524-6590-88 Tel/WX：173--1795--1908 |
