嵌入式編程和PC編程究竟有何區別

在中國，嵌入式編程的朋友很少是正兒八經從計算機專業畢業的，都是從自動控制啊，電子相關的專業畢業的。這些童鞋們，實踐經驗雄厚，但是理論知識缺乏；計算機專業畢業的童鞋很大一部分去弄網遊、網頁這些獨立於操作系統的更高層的應用了。也不太願意從事嵌入式行業，畢竟這條路不好走。他們理論知識雄厚，但缺乏電路等相關的知識，在嵌入式裡學習需要再學習一些具體的知識，比較難走。

能從PC機器編程去看嵌入式問題，那是第一步；學會用嵌入式編程思想，那是第二步；用PC的思想和嵌入式的思想結合在一起，應用於實際的項目，那是第三步。很多朋友都是從PC編程轉向嵌入式編程的。在中國，嵌入式編程的朋友很少是正兒八經從計算機專業畢業的，都是從自動控制啊，電子相關的專業畢業的。這些童鞋們，實踐經驗雄厚，但是理論知識缺乏；計算機專業畢業的童鞋很大一部分去弄網遊、網頁這些獨立於操作系統的更高層的應用了。也不太願意從事嵌入式行業，畢竟這條路不好走。他們理論知識雄厚，但缺乏電路等相關的知識，在嵌入式裡學習需要再學習一些具體的知識，比較難走。雖然沒有做過產業調查，但從我所見和所招聘人員，從事嵌入式行業的工程師，要麼缺乏理論知識，要麼缺乏實踐經驗。很少兩者兼備的。究其原因，還是中國的大學教育的問題。這裡不探討這個問題，避免口水戰。我想列出我實踐中的幾個例子。引起大家在嵌入式中做項目時對一些問題的關注。第一個問題：同事在uC/OS-II下開發一個串口的驅動程序，驅動和接口在測試中均未發現問題。應用中開發了個通訊程序，串口驅動提供了一個查詢驅動緩衝區字符的函數：GetRxBuffCharNum()。 高層需要接受一定數量的字符以後才能對包做解析。一個同事撰寫的代碼，用偽代碼表示如下：

<code>

這段代碼判斷當前緩衝區中超過30個字符，就將緩衝區中全部字符讀到緩衝區中，直到讀取成功為止。邏輯清楚，思路也清楚。但這段代碼是不能正常工作。如果是在PC機上，定然是沒有任何問題，工作的異常正常。但在嵌入式裡真的是不得而知了。同事很鬱悶，不知道為什麼。來請我解決問題，當時我看到代碼，就問了他，GetRxBuffCharNum()是怎麼實現的？打開一看：

<code>

很明顯，由於在循環中，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，體現在系統層面上，就是通信不穩定。修改這段代碼其實很簡單，最簡單的辦法是從高層修改。即：

<code>

這樣，讓CPU有時間去執行中斷的代碼，從而避免了頻繁關閉中斷造成的中斷代碼執行不及時，產生的信息丟失。在嵌入式系統裡，大部分的RTOS應用都是不帶串口驅動。自己設計代碼時，沒有充分考慮代碼與內核的結合。造成代碼深層次的問題。RTOS之所以稱為RTOS，就是因為對事件的快速響應；事件快速的響應依賴於CPU對中斷的響應速度。驅動在Linux這種系統中都是與內核高度整合，一起運行在內核態。RTOS雖然不能抄襲linux這種結構，但有一定的借鑑意義。從上面的例子可以看清楚，嵌入式需要開發人員對代碼的各個環節需要了解清楚。第二個例子：

<code>

將數據的8個bit在每個高電平從bit0到bit7依次發送出去。應該是正常的啊。看不出問題在哪啊？我仔細想了想，又看了14094的datasheet，明白了。原來，14094要求clock的高電平持續10個ns，低電平也要持續10個ns。這段代碼只做了高電平時間的延時，沒有做低電平的延時。如果中斷插在低電平之間工作，那麼這段代碼是可以的。但是如果CPU沒有中斷插在低電平時執行，則是不能正常工作的。所以就時好時壞。修改也比較簡單：

<code>

這樣就完全正常了。但是這個還是不能很好移植的一個代碼，因為編譯器一優化，就有可能造成這兩個延時循環的丟失。丟失了，就不能保證高電平低電平持續10ns的要求，也就不能正常工作了。所以，真正的可以移植的代碼，應該把這個循環做成一個納秒級的DelayNs(10);像Linux一樣，上電時，先測量一下，nop指令執行需要多長時間執行，多少個nop指令執行10ns。執行一定的nop指令就可以了。利用編譯器防止優化的編譯指令或者特殊的關鍵字，防止延時循環被編譯器優化掉。如GCC中的

<code>

從這個例子中可以清楚的看到，寫好一段好代碼，是需要很多知識支撐的。你說呢？嵌入式往往沒有操作系統支撐，或者因為有操作系統支撐，但因為種種的限制，操作系統提供的功能少得可憐。所以，很多代碼不能像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才知道跑得是什麼。我們來看看這段代碼：

<code>

這個代碼是一個字符串拷貝的代碼，PC機這樣寫，基本上就可以了。但嵌入式要提防一件事情，那就是 src真的以'\\0'結束的。要不是的話，那就悲劇了。到什麼時候能結束，呵呵，只有上帝老人家才知道。這段代碼僥倖能跑完成的話，估計也別想程序能正常的跑了。因為dest指向的內存區域都被破壞的差不多了。為了和標準C/C++的庫兼容，還真的沒什麼好辦法，所以這個問題只能留給程序員自己檢查。相同的，

<code>

內存拷貝同樣的問題，要提防n傳遞個負值進去。這個是拷貝多少個字節，負值被強制類型轉換成正的。變成一個很大的正數，造成dest之後的內存全部被破壞……嵌入式裡的內存指針必須做嚴格的檢查才能使用，內存的尺寸也必須進行嚴格的調試。不然的話，悲劇是很難避免的。如一個函數指針，雖然在嵌入式裡賦了個NULL,0。若是ARM的話，連個異常錯誤都沒有，直接復位了，因為調用這個函數指針即便是讓代碼從0開始運行。而0是ARM上電後運行的第一條代碼的位置。在ARM7上尤其如此。這種悲劇比PC上悲情多了，MMU 定然給一個無定義指令的錯誤。引起程序員的重視。在嵌入式裡，全部都留給了程序員去尋找了。內存溢出發生在任何一個不經意的時刻，你給整個前後臺的系統(或操作系統)分配了多大的堆？多大的棧？在通常情況下系統的調用深度是多少(最大是多少)，佔用多少棧？光看程序的功能正確還不夠，還需要統計這些參數。不然，只要有一個地方有溢出。對系統都是致命的。嵌入式系統要求系統連續工作時間長，穩定性可靠性要求苛刻。是需要一些時間仔細的磨這些系統的。

嵌入式系統的調試往往很複雜，可用的手段並不像PC編程那麼多，開發成本較PC系統也要大很多。嵌入式系統調試主要手段只有JTAG為代表的單步追蹤、printf夾殺大法等。

這兩種調試方法在嵌入式中也不盡然全部能解決問題。Jtag需要調試者有一個調試設備(有可能很昂貴)，和目標系統相連。使用類似GDB Client等軟件登錄調試設備，跟蹤運行程序。說實話，這個方法對嵌入式來講是終極的調試辦法，也是比較好的調試方法。但仍然有幾個不足,當斷點過多時，超出硬件的限制，某些低檔的CPU不支持更多的斷點，就需要JTAG利用軟件模擬，或採用軟件陷阱(軟中斷或異常)等辦法實現斷點。機理比較複雜，簡單點說，1.不能進行長時間調試，不太穩定; 2.有可能影響程序的運行時刻的行為，通過時序影響。掛接JTAG系統後，利用硬件實現的斷點不會影響系統運行的速度，但是軟件實現的斷點是必定犧牲一些性能的。可靠性也要打折扣的。當斷點太多，而系統又進入臨界區域，可能會造成斷點不起作用。因為嵌入式實現全局臨界區域往往需要關閉中斷，有些CPU沒有非屏蔽中斷，當斷點超過一定數量，使用軟件斷點，而軟件斷點又需要在中斷工作的情況下使用……特別調試時序問題和高速通信類的代碼，JTAG幫助並不大。通信過程往往很快，通信包也是接二連三，才能完成一個完整的動作。如果是高速通訊，斷點是無法讓程序完成工作的。所以只能使用printf夾殺的辦法，printf夾殺辦法很好。但是也要注意幾個問題：嵌入式系統往往沒有屏幕，printf輸出是通過串口輸出。而串口工作模式有兩種，一種是查詢，另外一種是中斷，或DMA。不管哪種，調試輸出的printf只能使用查詢的辦法輸出，千萬不要使用中斷或DMA的辦法。不管是前後臺程序也好，還是操作系統也好，都有不方便的時候，也許在全局臨界內需要打印(關閉了中斷)，也許需要在中斷裡打印(不允許嵌套中斷)，也許要在一些驅動裡打印(很多配合的設備沒有初始化，內存分配和中斷並不能很好的工作)。在這些情況下，利用Uart中斷輸出字符是不明智的。所以調試輸出只能使用查詢的辦法。不要幻想著使用什麼牛叉的辦法，不必了。一句話，不可靠！既然做調試，那可靠的輸出結果是第一要求。也就是因為如此，printf也會影響代碼的工作效率，串口最高的波特率115200bps，越快速的CPU越是浪費時間，因為需要等待上一個字符輸出完畢，這段時間完全是通過空轉消耗這部分時間。所以使用printf要有一些技巧，在不影響一些關鍵時序的位置下再打印，而不是隨意爛打……淹沒了bug。以上這兩種辦法並不能很好的解決全部的問題，在實際中如果嵌入式系統有一兩個LED燈，嘗試用IO口將其在特殊的情況下點亮熄滅的辦法，也可表示程序的狀態。這種辦法適合調試中斷、臨界區域這些問題。點亮LED燈需要的時間是非常短的，基本上是一條內存讀寫命令，如果IO口寄存器是CPU統一編址的話。基本上造成的影響微乎其微。在調試一些複雜的時序的時候，還可以使用空閒的IO口，將其在特殊的情況下拉低，拔高，然後利用數字示波器或者邏輯分析儀抓取再具體分析。特別是分析一段代碼的執行頻度，執行時間，優化效果等。對整體的性能提升等，有非常大的意義。對於簡單的單片機，廠商開發軟件都有個時序統計的功能。但對於有cache和MMU的單片機，時序統計並不準，往往不如用示波器測得的準。如果沒有示波器利用CPU內部的時間計數器也可以實現時間的統計，需要結合printf使用。我一個同事，調試飛利浦的ARM7，由於飛利浦ARM7外擴的RAM全部是靜態RAM，即使在CPU死機情況下，只要不斷電，SRAM裡的數據也不會丟失，由於SRAM和內部的SRAM統一編址，所以，訪問起來也就是一條讀寫指令，速度很快。利用這個特性，他把程序的模塊和點全部標記上，當系統運行不正常，將ARM7復位以後，ARM7上電第一個工作就是取出復位前的數據打印出來。由此可調試ARM7的代碼，非常巧妙的辦法。如果只有SDRAM的朋友們是不能用這種辦法的，因為只要系統復位，SDRAM沒有刷新，數據即會丟失。

地球人都知道，嵌入式的最大挑戰在於硬件和軟件同時成熟；出了個問題，不知道是軟件問題還是硬件問題。當然，可以通過虛擬的方式解決大部分問題，但虛擬終歸是虛擬。不是實際，上了實際的板子，還是有不少問題。嵌入式領域，特別是底層技術，由軟件(驅動)和硬件兩個部分組成。解決起來，需要兩個部分的知識，對人員的素質要求更高。我曾經遇到很多棘手的問題，都是複雜的系統問題。1、一個系統要求連續不斷的24小時工作，即使斷電，也要保存斷電狀態。在電源正常時，就必須恢復斷電前的狀態，繼續工作。實際中，我們也這樣做了軟件，但是實際效果並不是所想的那樣。一萬次斷電，總有那麼幾十次不正常；又沒辦法重現，只能是猜來猜去。因為系統斷電，這個也不好調試，掛著JTAG，系統現在斷電了，目標板也就沒電了。也就沒辦法調試跟蹤單步了。本來的設計思路是，控制電路利用電容存儲的一些些能量在斷電後繼續工作，保存狀態，保存好後，進入待機狀態。測試檢測斷電的信號後，也是沒有問題的。後來，這個問題變成懸疑問題了……這個系統分為兩個模塊，工作模塊和控制模塊。控制模塊有電容繼續供電，而工作模塊沒有電容工作；所以當發生斷電時，全系統不是同一時間斷電的。當控制模塊檢測到斷電時，實際上工作模塊早都沒電了，所以工作模塊不能正確的傳遞相關的數據回來，造成控制模塊不能正確的工作。兩個斷電的時序非常的接近，無法判斷其先後。解決的方法也很簡單，就是把斷電檢測模塊以工作模塊為主進行同步，就沒有問題了。

首先多處理器分為好幾種，處理器是同一型號，大家完全一樣，通過一種通訊方式連接，如多口的RAM，rapidIO，千兆級以太網，或者PCI-E等；處理器不同型號，甚至架構都完全不一樣。之間通過一種通訊方式連接，同上，如多口RAM、RapidIO等；同一個芯片中集成了多個CPU。這幾個CPU什麼都共享，屬於比多口RAM還要緊耦合的系統。為什麼要用多處理器？

大規模的並行運算；想利用多個CPU的特點，如DM642這樣的方案，應用於複雜的視頻方案。想利用DSP的浮點計算能力，同時也使用ARM的事務計算能力；單純的提高系統的性能。對於普通的應用，提高系統性能是基本出發點。但嵌入式系統應用多處理器並不是一個簡單的事情。多處理器的軟件設計難度很大，調試也是很大的問題。如果不採用操作系統處理，採用前後臺系統。那麼自己還要設計一個通信算法，還要設計一個結果整合系統。這樣的系統自己設計很多東西，其中總線的可靠和容錯設計至關重要。 所以可能的話，利用成熟穩定的操作系統來支持多處理器可以減少不少的開發難度。然而，尋找這樣的一個操作系統並非易事。首先要明確自己的應用，需要線程進程遷移嗎？需要處理器平衡嗎? 對於多處理器，如果不支持線程進程遷移，那也就談不上處理器任務的動態平衡，不然只能事前指定好線程進程運行於哪個處理器。對於異構型多處理器，線程遷移和進程遷移並沒有多大的實際意義。對於追求利益的公司來說，目前還談不上實用價值。所以，遷移只限於對稱處理器。然而，對稱處理器也不是什麼進程可遷移。對於對稱處理器，操作系統封裝好底層，讓用戶開發起來像是對一個CPU再做開發，當然不可能與單個CPU完全一致，但起碼減輕了許多難度。很多朋友問我RTEMS可以跑在x86這樣的CMP的多處理器上嗎？當然。但是，設計起來又不同於普通的對稱多處理器。因為，CMP處理器上的CPU共享了許多東西，中斷，內存，總線，他們的編址空間基本上都是一致的。對於RTEMS這樣的RTOS來說，它採用的是異構型的方式支持對稱處理器，即有幾個CPU就得跑幾個RTEMS。那麼通訊顯得尤為重要，多個RTEMS需要多個系統的TICK，那麼TICK從哪裡來，CMP共享著很多資源，那麼就要求，使用者必須為RTEMS手動的指定中斷源，劃分內存空間，這就造成了，CMP上的多個CPU雖然都是跑RTEMS，但是想關於CPU的驅動很多都是不一樣的。這種緊耦合的系統是非常難辦的。

相對於CMP，同 種CPU組成的SMP就要簡單一些，因為全部驅動都是一樣的，可能會因為通信方式的問題，通信驅動要特殊處理一下，但這會極大的減輕了開發的壓力和調試的難度。總好比每個CPU一個Core，那是要崩潰了。特別是調試問題，所以從經濟角度的問題考慮，還是比較喜歡這種多個相同的單個CPU組成的多處理器系統。

很多時候，對於那個異構型的處理器，當然用RTEMS也可以輕鬆擺平，但是還是一個問題，多個核心需要自己的RTEMS支持，開發多有不便。況且，操作系統的調試還是比較複雜的。所以現實版的方案都是，異構型處理器當中負責事務運算的處理器跑操作系統，而負責計算的處理器採用前後臺系統，簡單的通過共享內存通訊，響應操作系統的計算請求。這樣大大的減小了開發難度，反正操作系統把DSP當作了個硬件的寄存器，寫幾個寄存器就能得到結果，或者是輸入一組天文一樣的數據，得到一個複雜的結果。Anyway，總之這樣的反應式的處理方式是絕大部分工程中採用的方式。就是簡單、可靠、實用。看來，嵌入式系統中的多處理器還是與應用高度的相關

閱讀更多 程控教育學院 的文章

關鍵字: 中央處理器 設計