嵌入式系統是一種“完全嵌入受控器件內部，為特定應用而設計的專用計算機系統”，根據英國電氣工程師協會( U.K. Institution of Electrical Engineer)的定義，嵌入式系統為控制、監視或輔助設備、機器或用于工廠運作的設備。與個人計算機這樣的通用計算機系統不同，嵌入式系統通常執行的是帶有特定要求的預先定義的任務。由于嵌入式系統只針對一項特殊的任務，設計人員能夠對它進行優化，減小尺寸降低成本。嵌入式系統通常進行大量生產，所以單個的成本節約，能夠隨著產量進行成百上千的放大。 嵌入式系統是以應用為中心，以計算機技術為基礎，并且軟硬件可裁剪，適用于應用系統對功能、可靠性、成本、體積、功耗有嚴格要求的專用計算機系統。它一般由嵌入式微處理器、外圍硬件設備、嵌入式操作系統以及用 戶的應用程序等四個部分組成，用于實現對其他設備的控制、監視或管理等功能。 嵌入式系統的設計技術主要包括硬件設計技術和軟件設計技術兩大類。其中，硬件設計領域的技術主要包括芯片級設計技術和電路板級設計技術兩個方面。 芯片級設計技術的核心是編譯/綜合、庫/IP、測試/驗證。編譯/綜合技術使設計者用抽象的方式描述所需的功能，并自動分析和插入實現細節。庫/IP技術將預先設計好的低抽象級實現用于高級。測試/驗證技術確保每級功能正確，減少各級之間反復設計的成本。 下面我們先來介紹一些基本的開發流程。 嵌入式系統開發流程 第一步：建立開發環境 操作系統一般使用Redhat Linux，選擇定制安裝或全部安裝，通過網絡下載相應的GCC交叉編譯器進行安裝(比如，arm-linux-gcc、arm-uclibc-gcc)，或者安裝產品廠家提供的相關交叉編譯器。 第二步：配置開發主機 配置MINICOM，一般的參數為波特率115200 Baud/s，數據位8位，停止位為1，9，無奇偶校驗，軟件硬件流控設為無。在Windows下的超級終端的配置也是這樣。MINICOM軟件的作用是作為調試嵌入式開發板的信息輸出的監視器和鍵盤輸入的工具。配置網絡主要是配置NFS網絡文件系統，需要關閉防火墻，簡化嵌入式網絡調試環境設置過程。 第三步：建立引導裝載程序BOOTLOADER 從網絡上下載一些公開源代碼的BOOTLOADER，如U.BOOT、BLOB、VIVI、LILO、ARM-BOOT、RED-BOOT等，根據具體芯片進行移植修改。有些芯片沒有內置引導裝載程序，比如，三星的ARV17、ARM9系列芯片，這樣就需要編寫開發板上FLASH的燒寫程序，可以在網上下載相應的燒寫程序，也有Linux下的公開源代碼的J-FLASH程序。如果不能燒寫自己的開發板，就需要根據自己的具體電路進行源代碼修改。這是讓系統可以正常運行的第一步。如果用戶購買了廠家的仿真器比較容易燒寫FLASH，雖然無法了解其中的核心技術，但對于需要迅速開發自己的應用的人來說可以極大提高開發速度。 第四步：下載已經移植好的Linux操作系統 如MCLiunx、ARM-Linux、PPC-Linux等，如果有專門針對所使用的CPU移植好的Linux操作系統那是再好不過，下載后再添加特定硬件的驅動程序，然后進行調試修改，對于帶MMU的CPU可以使用模塊方式調試驅動，而對于MCLiunx這樣的系統只能編譯內核進行調試。 第五步：建立根文件系統 下載使用BUSYBOX軟件進行功能裁減，產生一個最基本的根文件系統，再根據自己的應用需要添加其他的程序。由于默認的啟動腳本一般都不會符合應用的需要，所以就要修改根文件系統中的啟動腳本，它的存放位置位于/etc目錄下，包括：/etc/init.d/rc.S、/etc/profile、/etc/.profile等，自動掛裝文件系統的配置文件/etc/fstab，具體情況會隨系統不同而不同。根文件系統在嵌入式系統中一般設為只讀，需要使用mkcramfs genromfs等工具產生燒寫映像文件。 第六步：建立應用程序的FLASH磁盤分區 一般使用JFFS2或YAFFS文件系統，這需要在內核中提供這些文件系統的驅動，有的系統使用一個線性FLASH(NOR型)512KB～32MB，有的系統使用非線性FLASH(NAND型)8MB～512MB，有的兩個同時使用，需要根據應用規劃FLASH的分區方案。 第七步：開發應用程序 可以放入根文件系統中，也可以放入YAFFS、JFFS2文件系統中，有的應用不使用根文件系統，直接將應用程序和內核設計在一起，這有點類似于μC/OS-II的方式。 第八步：燒寫內核 根文件系統和應用程序，發布產品。 提升可靠性的七大技巧 從規范完善的開發周期到嚴格執行和系統檢查，開發高可靠性嵌入式系統的技術有許多種。本文介紹了7個易操作且可以長久使用的技巧，它們對于確保系統更加可靠地運行并捕獲異常行為大有幫助。 技巧1——用已知值填充ROM 軟件開發人員往往都是非常樂觀的一群人，只要讓他們的代碼忠實地長時間地運行就可以了，僅此而已。微控制器跳出應用程序空間并在非預想的代碼空間中執行這種情況似乎是相當少有的。然而，這種情況發生的機會并不比緩存溢出或錯誤指針失去引用少。它確實會發生!發生這種情況后的系統行為將是不確定的，因為默認情況下內存空間都是0xFF，或者由于內存區通常沒有寫過，其中的值可能只有上帝才知道。 不過有相當完備的linker或IDE技巧可以用來幫助識別這樣的事件并從中恢復系統。技巧就是使用FILL命令對未用ROM填充已知的位模式。要填充未使用的內存，有很多不同的可能組合可以使用，但如果是想建立更加可靠的系統，最明顯的選擇是在這些位置放置ISR fault handler。如果系統出了某些差錯，處理器開始執行程序空間以外的代碼，就會觸發ISR，并在決定校正行動之前提供儲存處理器、寄存器和系統狀態的機會。 技巧2——檢查應用程序的CRC 對工程師來說一個很大的好處是，我們的IDE和工具鏈可以自動產生應用程序或內存空間校驗和(Checksum)，從而根據這個校驗和驗證應用程序是否完好。有趣的是，在許多這些案例中，只有在將程序代碼加載到設備時，才會用到校驗和。 然而，如果CRC或校驗和保持在內存中，那么驗證應用程序在啟動時(或甚至對長時間運行的系統定期驗證)是否仍然完好是確保意外之事不會發生的極好途徑。現在一個編程過的應用程序發生改變的概率是很小的，但考慮每年交付的數十億個微控制器以及可能惡劣的工作環境，應用程序崩潰的機會并不是零。更有可能的是，系統中的一個缺陷可能導致某一扇區發生閃存寫入或閃存擦除，從而破壞應用程序的完整性。 技巧3——在啟動時執行RAM檢查 為了建立一個更加可靠和扎實的系統，確保系統硬件正常工作非常重要。畢竟硬件會發生故障。(幸運的是軟件永遠不會發生故障，軟件只會做代碼要它做的事，不管是正確的還是錯誤的)。在啟動時驗證RAM的內部或外部沒有問題，是確保硬件可以如預期般運作的一個好方法。 有許多不同的方法可用于執行RAM檢查，但常用的方法是寫入一個已知的模式，然后等上一小段時間再回讀。結果應該是所讀就是所寫。真相是，在大多數情況下 RAM檢查是通過的，這也是我們想要的結果。但也有極小的可能性檢查不通過，這時就為系統標示出硬件問題提供了極好的機會。 技巧4——使用堆棧監視器 對許多的嵌入式開發者而言，堆棧似乎是一股相當神秘的力量。當奇怪的事情開始發生，工程師終于被難倒了，他們開始思考，也許堆棧中發生了什么事。結果是盲目地調整堆棧的大小和位置等等。但該錯誤往往是與堆棧無關的，但怎能如此確定?畢竟，有多少工程師真的實際執行過最壞情況下的堆棧大小分析? 堆棧大小是在編譯時就靜態分配好的，但堆棧是以動態的方式使用的。隨著代碼的執行，應用程序需要的變量、返回的地址和其它信息被不斷存儲在堆棧中。這種機制導致堆棧在其分配的內存中不斷增長。然而，這種增長有時會超出編譯時確定的容量極限，導致堆棧破壞相鄰內存區域的數據。 絕對確保堆棧正常工作的一種方法是實現堆棧監視器，將它作為系統“保健”代碼的一部分(有多少工程師會這樣做?)。堆棧監視器會在堆棧和“其它”內存區域之間創建一個緩沖區域，并填充已知的位模式。然后監視器會不斷的監視圖案是否有任何變化。如果該位模式發生了改變，那就意味著堆棧增長得太大了，即將要把系統推向黑暗地獄!此時監視器可以記錄事件的發生、系統狀態以及任何其它有用的數據，供日后用于問題的診斷。 大多數實時操作系統()或實現了內存保護單元(MPU)的微控制器系統中都提供有堆棧監視器。可怕的是，這些功能默認都是關閉狀態，或者經常被開發人員有意關閉。在網絡上快速搜尋一下可以發現，很多人建議關閉實時操作系統中的堆棧監視器以節省56字節的閃存空間等等，這可是得不償失的做法! 技巧5 - 使用MPU 在過去，是很難在一個小而廉價的微控制器中找到內存保護單元(MPU)的，但這種情況已經開始改變。現在從高端到低端的微控制器都已經有MPU，而這些 MPU為嵌入式軟件開發人員提供了一個可以大幅提高其固件(firmware)魯棒性(robustness)的機會。 MPU 已逐漸與操作系統耦合，以便建立內存空間，其中的處理都分開，或任務可執行其代碼，而不用擔心被stomped on。倘若真有事情發生，不受控制的處理會被取消，也會執行其他的保護措施。請留意帶有這種組件的微控制器，如果有，請多加利用它的這種特性。