嵌入式系統

維基百科，自由的百科全書
Soekris net4801, 適用於網路應用程式
嵌入式系統（Embedded system），是一種「完全嵌入受控器件內部，為特定應用而設計的專用電腦系統」，根據英國電器工程師協會（ U.K. Institution of Electrical Engineer）的定義，嵌入式系統為控制、監視或輔助設備、機器或用於工廠運作的裝置。與個人電腦這樣的通用電腦系統不同，嵌入式系統通常執行的是帶有特定要求的預先定義的任務。由於嵌入式系統只針對一項特殊的任務，設計人員能夠對它進行最佳化，減小尺寸降低成本。由於嵌入式系統通常進行大量生產。所以單個的成本節約，能夠隨著產量進行成百上千的放大。
由於個人數位助理（PDA,Personal Digital Assistant）及手持裝置在硬體上設計的特性，即使在軟體上的擴充性比其他裝置來得好，但普遍被認為是嵌入式裝置。但是這個定義也逐漸模糊。舉例來說，Intel 公司的凌動（ATOM）微處理器原本是為了移動網際網路裝置（MID，Mobile Internet Device）這一類的嵌入式系統設計的，但是現在更多的被應用於小筆電（Netbook），而小筆電屬於使用Windows或者Linux的個人電腦，因此嵌入式系統的定義又更模糊了。
嵌入式系統的核心是由一個或幾個預先編程好以用來執行少數幾項任務的微處理器或者微控制器組成。與通用電腦能夠執行使用者選擇的軟體不同，嵌入式系統上的軟體通常是暫時不變的；所以經常稱為「韌體」。

目錄

嵌入式系統例項

歷史

第一個被大家認可的現代嵌入式系統是麻省理工學院儀器研究室的查爾斯•斯塔克•德雷珀開發的阿波羅導航電腦。在兩次月球飛行中他們在太空駕駛艙和月球登陸艙都是用了這種慣性導航系統。
在計劃剛開始的時候，阿波羅導航電腦被認為是阿波羅計劃風險最大的部分。為了減小尺寸和重量而使用的當時最新的單片積體電路加大了阿波羅計劃的風險。
第一款大批次生產的嵌入式系統是1961年發行的民兵I飛彈上的D-17自動導航控制電腦。它是由獨立的電晶體邏輯電路建造的，它帶有一個作為主記憶體的硬碟。當民兵II飛彈在1966年開始生產的時候，D-17由第一次使用大量積體電路的更新電腦所替代。僅僅這個項目就將與非門積體電路模組的價格從每個1000美元降到低了每個3美元，使積體電路的商用成為可能。
民兵飛彈的嵌入式電腦有一個重要的設計特性：它能夠在項目後期對制導演算法重新編程以獲得更高的飛彈精度，並且能夠使用電腦測試飛彈，從而減少測試用電纜和接頭的重量。
這些二十世紀六十年代的早期應用，使嵌入式系統得到長足發展，它的價格開始下降，同時處理能力和功能也獲得了巨大的提高。英特爾4004是第一款微處理器，它在計算機和其他小型系統中找到了用武之地。但是，它仍然需要外部儲存裝置和外部支援晶片。1978年，國家工程製造商協會發行了可編程微控制器的「標準」，包括幾乎所有以電腦為基礎的控制器，如微控制器，數控裝置，以及基於事件的控制器。
隨著微控制器和微處理器的價格下降，一些消費性產品用使用微控制器的數位電路取代如分壓計和可變電容這樣的昂貴類比元件成為可能。
到了二十世紀八十年代中期，許多以前是外部系統的元件被整合到了處理器晶片中，這種結構的微處理器得到了更廣泛的應用。到了八十年代末期，微處理器已經出現在幾乎所有的電子裝置中。
整合化的微處理器使得嵌入式系統的應用擴充功能到傳統電腦無法涉足的領域。對多用途和相對低成本的微控制器進行編程，往往可成為各種不同功能的元件。雖然要做到這一點，嵌入式系統比傳統的解決方案要複雜，最複雜的是在微控制器本身。但是嵌入式系統很少有額外的元件，大部分設計工作是軟體部分。而非物質性的軟體不管是建立原型還是測試新修改相對於硬體來說，都要容易很多的，並且設計和建造一個新的電路不會修改嵌入式處理器。

特性

  1. 嵌入式系統在廣義上說就是電腦系統，它包括除了以通用為目的電腦之外的所有電腦。從行動式音樂播放器到太空梭的即時控制子系統都能見到嵌入式系統的應用。與通用電腦系統可以滿足多種任務不同，嵌入式系統只能完成某些特定目的的任務。但有些也有即時效能的制約因素必須得到滿足的原因，如安全性和可用性。除此之外其他功能可能要求較低或沒有要求，使系統的硬體得以簡化，以降低成本。對於大批次生產的系統來說，降低成本通常是設計的首要考慮。嵌入式系統通常需要簡化去除不需要的功能以降低成本，設計師通常選擇剛剛滿足所需功能的硬體使標的最小化低成本的實作。
  2. 嵌入式系統並非總是獨立的裝置。許多嵌入式系統是以一個部件存在於一個較大的裝置，它為裝置提供更多的功能，使裝置能完成更廣泛的任務。例如，吉布森吉他機器人採用了嵌入式系統來調弦，但總的來說吉布森吉他機器人設計的目的絕不是調弦而是演奏音樂。同樣的，車載電腦作為汽車的一個子系統，為它提供了導航，控制，車況反饋等功能。
  3. 部分為嵌入式系統編寫的程式被稱為韌體，他們儲存在唯讀記憶體或快閃記憶體晶片。他們執行在資源有限的電腦硬體：小記憶體，沒有鍵盤，甚至沒有螢幕。

使用者介面

嵌入式系統使用者介面包括了從沒有使用者介面，專註於單一任務到現在的類似於現代桌面作業系統的複雜圖形化使用者介面的各類介面。

簡單的嵌入式系統

簡單的嵌入式裝置往往由按鈕，發光二極體（LEDs）和僅僅能顯示小字元或數位的顯示器，以及簡單的選單系統組成。

較為複雜的嵌入式系統

較為複雜的嵌入式系統擁有的完整的圖形螢幕、觸摸感應或螢幕邊緣按鈕在最大限度地使用空間的同時，提供了足夠的靈活性：指點控制是很自然的非常理想的操控方式，這樣的方式可以改變螢幕的意義。
手持系統通常都有一個螢幕和作為定位裝置的控制按鍵。
大部分嵌入式系統透過「維護」或者「測試」介面來提供一個選單，或者由一個RS-232（序列資料通訊的介面標準）介面提供的命令列介面。這樣就可以在很少的顯示花費的基礎上提供大量的控制手段。然而，這也會讓大部分消費者無法安裝必要的電纜。

CPU平台

在嵌入式系統設計中有許多不同的CPU架構，如ARM、MIPS、Coldfire/68k、PowerPC、X86、PIC、Intel 8051、Atmel AVR、Renesas H8、SH、V850、FR-V、M32R、DMCU等。
這與桌面電腦市場有所不同，至2003年為止在那個領域只有少數幾家競爭的架構，其中主要是英特爾/AMDx86和用於Apple Macintosh的Apple/Motorola/IBM PowerPC。在桌面電腦領域，隨著對於Java接受程度的增長，軟體對於特定執行環境的依賴越來越少。
PC/104標準是小型、小批次嵌入式和ruggedized系統設計的基礎。這些系統通常使用DOS、Linux、NetBSD或者如QNX、Inferno這樣的即時嵌入式作業系統。
大批次生產的嵌入式系統的通常配置是片上系統（en:System On Chip），它是一個專用積體電路，CPU是外購的智慧財產權並且添加到積體電路設計中。一個類似的常用機制是使用可編程門陣列，所有的邏輯包括CPU部分都可以編程實作。許多時髦的FPGA都是為這個目的設計的。

工具

同典型的電腦程式設計師一樣，嵌入式系統設計人員也使用編譯器、連結器和偵錯程式開發嵌入式系統軟體。然而，他們也使用一些大多數程式設計師不熟悉的工具。
軟體工具的來源有如下幾種：
  • 專註於嵌入式系統市場的軟體公司
  • 從GNU軟體開發工具移植（參見交叉平台編譯）
  • 有些情況下，如果嵌入式處理器與普通個人電腦處理器很近似的話也可以使用個人電腦開發工具
嵌入式系統設計人員也使用一些不為普通電腦程式設計師所熟悉的軟體工具：
  • 一個常用工具是「電路內部模擬器」（ICE，in-circuit emulator）或者是最新設計中的嵌入式偵錯程式。這個偵錯工具是開發嵌入式程式的基本技巧。它代替微處理器或者嵌入微處理器內部，提供了在系統中快速呼叫和偵錯試驗代碼的便捷工具。一個焊點通常就是一個插入系統的特殊電路，通常使用一台連結到這些焊點的個人電腦作為偵錯介面。
  • 連結器通常是各種各樣（exotic）。對於大多數商業編程來說，連結器幾乎總是最後才想起的（afterthough）部分，預設設定也從來不變。與此相反，嵌入式連結器有完整、複雜的命令列語言是很普通的。經常有不同型別的記憶體，分別保存特殊的代碼和資料。單獨的資料結構能夠放在特殊的位址，這樣軟體能夠很方便地存取對映到記憶體的控制暫存器。嵌入式連結器經常有用於減小代碼大小和執行時間的外部（exotic）最佳化工具。例如，他們可能移動子程式的位置以使用較小的呼叫和跳轉指令。它們經常帶有管理data overlays和band switch技術的特性，這些技術是在嵌入式軟體經常使用的擴充功能廉價CPU的方法。
  • 另外一個常用的工具是一個在程式中添加代碼和或者CRC的工具程式（經常是自己寫的），使用這個工具嵌入式系統能夠在執行程式之前先進行程式資料檢查。
  • 為數位訊號處理開發軟體的嵌入式程式設計師經常使用MathCad或者Mathematica這樣的數學工具進行數學模擬。
  • 一些較少使用的工具有將資料檔案轉換成代碼的工具，使用這種工具就可以在程式中包含任意型別的資料。
  • 少數一些項目為了特殊的可靠性或者數位訊號處理要求使用同步程式語言。
一些程式語言為嵌入式系統編程提供了一些特殊支援。

偵錯

偵錯通常使用內部電路模擬器或者其他一些能夠在微控制器微碼（microcode）內部產生中斷的偵錯程式。微碼中斷讓偵錯程式能夠在只有CPU工作的硬體中進行操作，基於CPU的偵錯程式能夠從CPU的角度來測試和偵錯電腦的電路。PDP-11開創了這種特性的先河。
開發人員能夠仍然使用斷點、單步執行以及高階語言進行偵錯，在許多的偵錯工具上都有這種能力。另外開發人員在偵錯即時事件順序的時候需要記錄、使用簡單的記錄工具。
首先遇到這種問題的個人電腦和大型電腦程式設計師經常在設計優先順序和可行方法的時候感到困惑。指導、代碼審查和非個人風格（egoless）的編程是值得推薦的。
隨著嵌入式系統變得越來越複雜，更高層次的工具和作業系統逐漸移植到可行的裝置上。例如，蜂窩電話、個人數位助理和其他的消費用電腦需要一些從個人或者這些電子裝置製造商之外的公司購買或者提供的一些重要軟體。在這些系統中，需要如Linux、OSGi或者Java這樣的開放編程環境，這樣第三方軟體提供上才能夠在大規模的市場上銷售軟體。
大多數這樣的開發環境都有一個執行在個人電腦上的參考設計，這種軟體的絕大部分都可以在傳統的個人電腦上開發。然而，從開放環境移植到專用的電子裝置和電子裝置的驅動程式開發通常仍然是傳統的嵌入式系統軟體工程師的工作。在有些情況下， the engineer works for the integrated circuit manufacturer, but there is still such a person somewhere.

作業系統

使用Windows XP的網際網路收費電話
嵌入式系統經常沒有作業系統、專用的嵌入式作業系統（經常是即時作業系統）或者指定程式設計師移植到這些新系統。

啟動

嵌入式系統帶有啟動代碼，通常它禁止中斷、設定電子裝置參數、測試電腦（RAM、CPU和軟體），然後開始應用程式執行。許多嵌入式系統從短暫的掉電狀態恢復，經常重起而不進行最近的自檢。在十分之一秒內重起是常見的現象。
許多設計人員發現LED在指示錯誤狀態上非常有用，它們可以幫助進行故障處理。一個常用的機制是在複位的時候點亮電子裝置所有的LED以表明供電和LED正常工作；然後在進行加電自檢時由軟體改變LED的狀態；在此之後，軟體用這些LED指示操作過程中的正常或者故障狀態。這可以讓技術人員、工程師和使用者了解系統的狀態。一個有趣的例外是電度表（electric power meters）和其他一些大街上的東西，閃爍的指示燈是為了吸引注意力或者表示損壞狀態。

內部自檢

許多嵌入式系統都有一定程度或者一定數量的內部加電自檢，自檢有幾種型別：
  1. 電腦檢查：檢查CPU、RAM和程式記憶體。通常一加電就開始這些檢查，在一些安全性非常重要的系統中，通常周期性地在安全時間間隔內進行自檢，或者經過一段時間就進行自檢。
  2. 外圍裝置檢查：模擬輸入和讀入資料或者測量輸出資料。有大量的通訊、類比和控制系統都有這些非常廉價的檢查。
  3. 電源檢查：通常測試每個供電電路，也可能檢查電池或者主電源輸入。通常供電部分的負載都很重，並且少有餘量，所以這項檢查很有意義。
  4. 通訊檢查：驗證從相連單元接收到的簡單訊息，例如在網際網路上使用ICMP訊息「ping」。
  5. 電纜檢查：將線連結到待檢查的電纜上指示針進行檢查。如電話這樣的同步通訊系統經常使用「同步」測試。電纜檢查成本很低，當單元部分有插頭的時候這項檢查尤其重要。
  6. 裝備檢查：一個系統在安裝時經常需要進行調整，這項檢查就向安裝人員做出狀態指示。
  7. 消耗檢查：檢查系統所消耗的東西、在預量太低時發出警告。最常見的例子是汽車的油量表，最複雜的例子可能是維持化學反應物詳細狀態的自動醫學分析系統。
  8. 執行檢查：檢查使用者關心的系統執行狀態。顯然，在系統執行時必須進行這項檢查，這方面的檢查包括飛機上的導航儀器、汽車的速度表和磁碟的指示燈等。
  9. 安全檢查：在'安全時限'內進行檢查確保系統仍然可靠。安全時限通常小於能夠產生損害的最小時間。

可靠性體系

根據人們需求的不同，可靠性也有不同的定義，有意思的事，可靠性的型別卻相對較少，相似可靠性型別的系統，使用相似型別的內在檢查和恢復方法：
  1. 系統非常不安全或者無法修理。這包括太空系統、水下電纜、導航燈塔、鑽孔系統，非常奇怪的是還包括汽車和大規模生產產品。總的來說，嵌入式系統檢測各個子系統、線上切換到冗餘部分或者工作在「limp 模式」提供部分的功能。大規模生產的消費產品如汽車、個人電腦或者印表機也屬於這個類別，這是因為與購買的費用相比維修費用高昂、維修人員又路途遙遠。
  2. 系統不能安全地停止執行。這包括飛機導航、反應控制系統、重要的化學工廠安全控制、鐵路訊號、單發動機飛機的發動機，如上所述，但是「limp 模式」較難容忍，通常需要操作員選擇備份系統。
  3. 系統停機時將會造成大量的金錢損失。這些包括電話交換機、工廠控制、橋樑和電梯控制、資金轉移、市場開發、自動銷售和服務等，這些系統通常有一些運轉/不運轉測試，它們通常帶有線上冗餘或者使用替換系統和人工過程的 limp 模式。
  4. 系統不安全的時候不能操作。同上面的情況類似，系統的執行將會造成大量的金錢損失。醫療裝置、帶有發動機這樣的熱備份的飛行器、化學工廠控制、自動股票交易、遊戲系統等。測試可能是五花八門，但是出錯時能夠做的就是停止整個系統。

嵌入式軟體架構的型別

常用的嵌入式軟體架構有幾種不同的基本型別。

控制迴圈

在這種設計中，軟體有一個簡單的循環，這個循環調用各個子程式，每個子程式管理硬體或者軟體的某一部分。中斷通常用來設置標記或者更新軟體其他部分能夠讀取的暫存器。
系統使用簡單的API來完成允許和禁止中斷設置。如果處理得當的話，它能夠在巢狀子程式中處理巢狀調用，在最外面的中斷允許巢狀中恢復前面的中斷狀態。這種方法是實作Exokernel的一個最簡單的方法。
通常在循環中有一些子程式使用周期性的即時中斷控制一組軟體定時器，當一個定時器時間到的時候就會執行相應的子程式或者設置相應的標誌。
任何可能發生的硬體事件都應該有軟體定時器的支援，硬體事件大概每萬億次出現一次錯誤，對於現代的硬體來說大概是一年發生一次，對於以百萬計大規模生產的設備來說，遺漏一個軟體軟體定時器在商業上可能是災難性的。
有時測試軟體執行一組基於軟體的安全定時器，它們周期性地複位硬體中的軟體看門狗。如果軟體錯過一個事件，安全定時器軟體將會捕捉到它。如果安全定時器出錯，看門狗硬體將會複位系統。
可以使用指向每個狀態機函式的指標實作狀態機，函式可以用C++、C或者組合語言等實作。變化的狀態將不同的函式放到指標中，每次循環執行時都會執行函式指標。
許多設計人員建議每個循環讀一次輸入輸出設備、並且保存得到的結果，這樣可以保證邏輯過程的在一致的參數上執行。
許多設計人員喜歡將狀態機設計成每個狀態僅僅檢查一到兩項內容，通常是檢查硬體事件和軟體定時器。
設計人員建議多級狀態機應該讓低層狀態機早於高層狀態機執行，這樣高層就能夠根據正確的訊息執行。
如內部燃燒控制這樣的複雜功能通常根據多維表格進行處理，代碼通常進行查表處理而不進行複雜的計算，為了減小表格的大小以及成本軟體可以在條目之間進行差值運算。
在最小的微控制器中，尤其是只有128位元組堆疊的8051中，控制環允許好的連接器使用靜態分配的數據覆蓋本地變數。在這種機制中，離子程式調用樹末端越近的變數得到的記憶體位址越高。當開始一個新的分支的時候，它的變數可以在以前分支遺棄的空間中進行重新分配。
簡單控制迴圈的一個主要缺點是它無法保證響應特定硬體事件的時間。
細心的設計可以很容易地保證中斷不會被長時間禁止，這樣中斷代碼就可以在非常精確的時間執行。
控制環的另外一個主要缺陷是增加新的特性的時候會變得複雜。需要花費很長時間的演算法必須小心地進行分解以使得每次只有一小部分在主循環中執行。
這種系統的優勢是它的簡單性，並且在很小的軟體上，循環執行地很快幾乎沒有人關心它是不可預測的。
它的另外一個優勢是這種系統保證執行軟體的質量，無法將不好的執行結果歸咎為其他的作業系統。

非搶先式任務

非搶先式任務系統非常類似於上面的系統，只是這個迴圈是隱藏在API中的。我們定義一系列的任務，每個任務獲得自己的子程式棧；然後，當一個任務空閒的時候，它呼叫一個空閒子程式（通常呼叫「暫停」、「等候」、「交出（yield）」等等）。
帶有類似屬性的架構都帶有一個事件佇列，有一個迴圈根據佇列列表中的一個域確定刪除時間和呼叫子程式。
這種架構的優點和缺點都非常類似於控制環，只是這種方法添加新的軟體更加簡單，只需要簡單地編寫新的任務或者將它添加到佇列直譯器中。

搶先式定時器

使用上面的任何一種系統，但是添加一個按照定時器中斷執行子程式的定時器系統，這樣就給系統添加了嶄新的能力，這樣定時器子程式第一次能在一個有保證的時間內執行。
另外，代碼第一次能夠在非預期的時間存取自己的資料結構。定時器子程式必須要象中斷子程式一樣進行處理。

搶先式任務

使用上面的非搶先式任務系統，從一個搶先式定時器或者其他中斷執行。
這樣系統就突然變得很不一樣了。任何一個任務的代碼都有可能損害其他任務的資料 &emdash; 所以它們必須進行切缺的切分。對於共享資料的存取必須使用一些同步策略進行控制，如訊息佇列、訊號燈或者非阻塞同步機制。
經常在這一步開發組織就會購買一套即時作業系統。如果一個組織缺少能夠編寫作業系統的人才或者作業系統將要在幾個產品之上，這可能是一個明智的選擇。這通常要將開發計劃增加六到八周，and forever after programmers can blame delays on it.

微核心與外核心

這種方法試圖將系統組織得比單核心更易於配置，而同時提供類似的特點。
微核心是即時作業系統的一個邏輯發展，通常的組織方式是作業系統核心分配記憶體並且將CPU在不同的執行緒之間進行切換。使用者模式的行程實作如檔案系統、使用者介面等主要的功能。
微核心在二十世紀五十年代開始首次嘗試，但是由於電腦在任務間切換以及在任務間交換資料速度非常緩慢，所以人們放棄了微核心而鍾情於MULTICS和UNIX風格的大核心。總體上來說，微核心在工作切換以及任務間通訊速度快的時候是比較成功的，在速度慢的時候是失敗的。
外核心透過使用普通的子程式呼叫獲得的通訊效率很高，硬體以及系統中的軟體都是程式設計師能用也能擴充功能的。資源核心（可能是庫的一部分）分配CPU時間、記憶體以及其他資源。如多工、網路以及檔案系統這樣的大核心特性透過代碼庫來提供。庫可以進行動態的連線、擴充功能或者共享。不同的應用甚至可以使用的不同的庫，但是所有的資源都來自於資源核心。

虛擬機器

一些航空電子系統使用幾個商用電腦。這樣更進一步，每個電腦都在類比它們自身的幾個副本，重要的程式同時在幾個電腦上執行並且進行投票控制（vote）。
類比環境的優點就是即使一個電腦出現故障，軟體的不同常式能夠遷移到正常工作的軟體分割，表決的票數並不受影響。
通常虛擬軟體執行在電腦的使用者模式下，它捕捉、類比硬體存取和不在使用者模式下執行的指令。

檢查點計算

另外一種常用的機制是兩個電腦計算 for a bit，然後將它們的計算結果報到那個點上。如果一個電腦的計算是 nut，它就會被關閉。

辦公用（單核心）作業系統

這種系統通常在沒有系統經費的嵌入式項目中流行，但是從這篇文章的多個作者來看，這通常是不正確的，它們的邏輯是：
  • 作業系統是經過特殊封裝的重用代碼庫。如果這些代碼有用，設計人員就會節省時間和金錢，否則它們就是無用的。
  • 商務系統的作業系統沒有嵌入式硬體的介面。例如，如果要用Linux寫一個馬達控制器或者電話交換機，絕大部分的實際控制操作都是IOCTL呼叫，同時，正常的讀、寫和查詢介面都是無用的。所以作業系統對於實際的開發妨礙很大。
  • 大多數的嵌入式系統不處理辦公事務，所以辦公作業系統的大部分代碼都被浪費了。例如，絕大多數的嵌入式系統從來都不使用檔案系統或者螢幕，所以檔案系統和圖形化使用者介面部分就是浪費的，這些不用的代碼只會影響系統的可靠性。
  • 辦公用作業系統保護硬體不讓使用者程式操作，這就嚴重地妨礙了嵌入式開發工作。
  • 作業系統必須移植到嵌入式系統上，也就是說，硬體驅動程式無論如何都必須重寫，這也是作業系統最難的部分，所以使用這樣的作業系統幾乎沒有功效。
  • 作業系統真正有用、可移植的特性是小段代碼。例如，一個基本的TCP/IP介面大約有3000行代碼，另外的一個例子是大約同樣大小的簡單檔案系統。如果設計需要這些代碼，能夠使用少於嵌入式系統開發10%的經費就能完成，不需要支付版權費用，只需要簡單地重寫就可以了。如果系統這些代碼有足夠的通用性，嵌入式系統雜誌封面的後面通常有公司銷售沒有版權費的C語言實作代碼。
然而許多工程師並不認同這一點，嵌入式Linux越來越受到人們的歡迎，尤其是在無線路由器和全球定位系統這樣的功能強大的嵌入式系統中。其中有下面一些原因：
  • 有現成的移植到普通嵌入式晶片的實作代碼。
  • 它們允許重用公開獲得的裝置驅動程式、網頁伺服器、防火牆或者其他代碼。
  • 開發系統能夠從許多特性組合開始，在發行的時候可以剔除不需要的功能，從而節約所消耗的記憶體。
  • 許多工程師認為在使用者模式執行應用程式更為可靠、更容易偵錯，所以開發過程更容易、代碼更易於移植。
  • 許多嵌入式系統沒有控制系統那樣對於即時性的嚴格要求，對於許多應用來說如嵌入式Linux這樣的系統的響應速度就已經足夠了。
  • 要求更快的響應速度，而不是可靠性的特性，通常放到了硬體上。
  • 許多即時作業系統都針對每件產品收取費用，當產品是消費品時，這項費用是巨大的。

Exotic custom 作業系統

一些系統需要安全、及時、可靠或者高效的特性，上面的架構卻無法達到，構建這樣的系統有一些廣為人知的技巧：
  • 僱傭一個真正的系統程式設計師。他們的花費很小，但是能夠節約數年的偵錯以及相關的收入損失。
  • RMA （rate monotonic analysis），可以用來評估一組任務能否在特定的硬體系統下執行，在最簡單的形式下，設計人員保證最快完成的任務有最高的優先順序，平均來說 CPU 至少有 30% 的空閒時間。
  • 和諧的任務能夠高效地最佳化CPU。基本上來說，設計人員保證每件工作都是從heartbeat timer開始工作的。在即時作業系統上很難這樣做，因為它們在等候輸入輸出裝置的時候通常就會切換任務。
  • 剛好有兩個優先順序（通常是執行和禁止中斷）的系統不能出現高優先順序任務等候低優先順序任務釋放訊號燈或者其他資源的優先順序倒置問題，
  • 有監視器（monitor）的系統不能出現死結。監視器鎖住一段代碼禁止中斷和其他搶先任務。如果這個監視器只用於一小段快速執行的代碼，系統可能工作正常。如果能夠證明監視器 API 在所有情況下都能夠完整執行，例如僅僅禁止中斷，那麼就不會產生系統掛起的情況。
這就意味著使用兩個優先順序和監視器的系統是安全、可靠的，因為它們沒有死結和優先順序倒置的問題。如果監視器能夠執行到結束，那麼就永遠不會掛起。如果使用和諧的任務，可能還會相當高效。然而，RMA 無法描述這些系統，優先順序最好也不要到處都有，其中包括作業系統和硬體。

外部連結

常見的嵌入式作業系統