在本文中，我們研究了選擇嵌入式操作系統的各種方案，并且針對嵌入式和實時操作系統，討論一些選擇標準，并強調由可編程邏輯解決方案引入的設計折衷。闡述了一個典型實例，這里我們以在萊迪思半導體公司的FPGA 上運行的LatticeMico32軟處理器設計為例提供一個典型方案的討論。
　
　　引言

　　操作系統能夠提高可移植性，并提供多種經過測試的抽象層，服務層和應用模塊層以供選擇，從而加快產品上市時間并減少應用程序出錯的可能性。然而，選擇一個嵌入式操作系統( OS )從來就不是一個簡單的過程，因為集成嵌入式軟件的方式選擇余地很大，你可以完全都由自己來編寫，或通過商業定制專門實時操作系統，也可以直接購買通用操作系統不作任何修改，現成的通用操作系統。FPGA性能的提高和軟處理器核的出現，直接導致了可編程邏輯SoC解決方案的產生，隨著這一變化，關于選擇標準，設計方案以及折中考慮等傳統經驗也需要與時俱進以適應這些新的開發方式。

　　在本文中，我們研究了選擇嵌入式操作系統的各種方案，并且針對嵌入式和實時操作系統，討論一些選擇標準，并強調由可編程邏輯解決方案引入的設計折衷。闡述了一個典型實例，這里我們以在萊迪思半導體公司的FPGA 上運行的LatticeMico32軟處理器設計為例提供一個典型方案的討論。

　　傳統經驗

　　根據傳統經驗，一個操作系統的選擇有四個主要方式。

　　無操作系統

　　許多簡單的嵌入式系統不需要操作系統。該代碼通常始于設立堆棧指針和初始化幾個時鐘和外設寄存器。然后，該代碼進入主循環(也稱為超級循環) ，以執行產品的功能。編寫中斷服務程序( ISR)用以處理異步事件，以提供一些響應而不是輪詢設備方式來進行服務。 ISR的響應通常是在0到10微秒的范圍。如果 處理器速度 足夠 快，以及超級循環是小而緊湊的，這是一個完全可行的選擇。然而，如果進行更復雜的操作，如執行控制循環，提供圖形顯示服務，使用文件系統或網絡堆棧( TCP / IP協議或其他)，超級循環將無法正常工作。如果考慮一個 快速和 功能強大的 處理器， 如開放源 代碼LatticeMico32軟處理器， 應該選擇一個操作系統。

　　自己編寫操作系統

　　對于一些特定需求，現有的解決方案無法滿足需要，或者現有的解決方案成本太高，通常就需要考慮自己編寫操作系統。自己編寫RTOS (實時操作系統)通常不是一個好的選擇，因為總是嚴重低估所需付出的努力。一個簡單的“tasker”要寫幾天或幾周，但更艱巨的挑戰是需要對實現魯棒性商業產品的努力。例如，一個商業的RTOS ，如μC/OS-II可能包含超過10000行的代碼，已經在各種各樣的產品中得到了現場驗證，并可能已被認證應用于，如電子和醫療產品等。如果選擇你自己編寫，誰將確保長期維護，并且完成詳細的文檔?

　　從商業的觀點來看，自己編寫的RTOS不是一個好的選擇。

　　商業RTOS

　　實時操作系統是一個管理微控制器，微處理器或DSP時間的軟件。最重要的一個特點是它對實時事件的響應，通常不到25微秒。這種響應通常是確定性，在某些情況下，甚至相當穩定。一個實時操作系統以應用編程接口( API )的形式為應用程序員提供了許多“服務”。當選擇一個實時操作系統時，從技術和業務問題方面考慮會有數十種選擇。

　　技術問題可以大致分類為：

　　* RTOS對應用作出的響應夠嗎?

　　* 實時操作系統提供了所需的功能嗎?大多數實時操作系統提供相同的基本功能：任務管理，時間管理，信號量，消息隊列，事件標志等。

　　* RTOS可以實時用于不同的CPU (即代碼可以移植嗎)嗎 ?一個 實時操作系統，如μC/OS-II已移植到超過45種不同CPU 架構， 所以在這種 情況下，可移植性不會成為問題，產品和其一部分的長壽性是得到保證的。如果使用一個新的架構，移植 到一個 CPU通常需要一兩個星期。

　　* 使用RTOS是否有足夠的ROM和RAM?根據所需的特性RTOS的空間可以減少嗎?例如，μC/OS-II是可以升級的，代碼 空間的要求在6千字節到24 千字節的之間，最低只需要500字節的RAM 。

　　從商業角度，事情并非那么容易解決。具體來說，嵌入式開發者需要從操作系統供應商那里得到滿意答復，了解價格結構，支持結構和供應商的聲譽和穩定性。尋找一個ROTS操作系統或RTOS的供應商時，調查通常是一個好的開端。

　　當系統響應速度是最重要時，如控制和監測應用程序，就會選擇商業的RTOS，因為它們很依賴于軟件的執行功能。如果你可以選擇用硬件實現時間至關重要的功能，通常就不需要由RTOS提供嚴格的時間保證。

　　UNIX操作系統

　　在過去幾年中，嵌入式應用中采用的32位處理器平臺的性能和功能得到了極大增強。今天，即使軟處理器，如LatticeMico32提供達到50至100 DMIPS的計算能力。隨著可用資源的性能和功能的增強，提供豐富的功能集和抽象層的操作系統已成為一種可行的可選嵌入式解決方案。UNIX提供了非常豐富的編程環境，對多處理器的應用有相當的規模，以及在網絡的應用方面擁有豐富的歷史。通過文件操作，它提供了一個統一的設備抽象層，使平臺之間的應用可以快速移植。一些UNIX版本也可獲取開放源代碼授權：Linux是最著名的變種，有非常龐大的用戶群體和許多嵌入式應用(如WLAN路由器，打印機，VoIP電話)。Linux系統甚至對不包括MMU (內存管理單元)的處理器提供了有限的支持。各種BSD (伯克利軟件分發)版本可能不太為人所知，但它們在許可證上限制較少。

　　一些實時擴展為Linux提供了在Linux執行層的頂部(或者說，下面)的最佳的軟實時層。RT/ Linux、 RTAI和Xenomai是實時擴展的例子。通過多種已知的API從其他的RTOS (在Xenomai，此功能被稱為“skins”)，一些實時層輸出其功能 。

　　Linux系統提供了豐富的應用，可以很容易地集成到一個嵌入式應用程序，如Web服務器，協議棧，數據庫引擎，圖形庫和網絡管理。這些功能可以添加到任何嵌入式應用，而不需要“從草圖”開發。隨著Linux的先進I/O子系統的出現，和全面支持的非易失存儲技術(從閃存到SATA硬盤) ，甚至可以集成“大”的應用(如在NAS應用中，跟蹤照片的數據庫應用)。

　　廣泛使用的操作系統技術，例如Linux，其中一個最大的好處是在互聯網上可獲取大量的可用信息，有許多專業設計公司可以提供專業服務。雖然源代碼的許可證是免費的，Linux的復雜性和大小會壓垮許多用戶。在這種情況下，專門設計公司，如Theobroma Systems可提供專業支持，培訓和總承包設計服務。重要的是要記住，“開放源代碼組織”并不能給你提供工業質量的支持，只有有經驗的工程人員才行。

　　使用FPGA解決方案時，有與大型操作系統如Linux相關的性能和響應時間方面的問題，可以用硬件實現。在這種情況下，操作系統功能作為一種資源監管，大部分關鍵時間工作用硬件來完成。這個方法的一個例子是在UART內利用一個大的FIFO，以減少至操作系統 的中斷次數。當然，此方法有一定的局限性和復雜性，但與一個專用的CPU芯片相比，有更多的靈活性。

　　另一方案：使用可編程邏輯

　　FPGA為系統設計者提供了一系列的權衡選擇，這是現有的ASIC/ASSP解決方案無法提供的。正如圖1所示 ，當一個處理器集成至FPGA時，設計者可以各種方式實現功能例如：

　　* 軟件控制硬件

　　* 僅軟件

　　* 軟件功能，控制或數據流，通過硬件加速(SW/HW）

* 僅硬件，與CPU沒有直接的互動，但是硬件可與任何功能進行交互。
?

?

　　圖1 FPGA中的多種選擇

　　使用提供這些權衡的可編程邏輯解決方案，SoC設計者有控制結構的多種選擇。相反，控制結構的選擇涉及到如何實現所需的功能。

　　一個簡單的便攜式媒體播放器示范了操作系統如何控制硬件，以及如何使用一個FPGA提供一系列改善硬件/軟件的權衡選擇。圖2從硬件的角度展示了播放器的功能。所需硬件的數量在很大程度上取決于所期望的系統響應。有了RTOS，許多硬件模塊可以比在Linux應用中簡單得多?？偠灾現PGA的可編程邏輯為任何操作系統提供硬件權衡選擇。

?

　　圖2 從硬件角度觀察便攜式媒體播放器

　　設計者在系統中用什么附加硬件，和如何用附加硬件有更多的靈活性，這可以從軟件的角度來觀察，如圖3所示。

　　一個鍵盤掃描器或許可以作為RTOS任務來執行，也作為硬件通過Linux任務來訪問。事實上，用硬件實現的鍵盤掃描器在系統中是隱藏的，因為它被包裝在一個任務中。其優點是大大減少了對操作系統的中斷。輕松地權衡添加硬件或者使用軟件為系統設計師帶來了一種新的靈活性。

?

　　圖3 從軟件角度觀察相同的便攜式媒體播放器

　　與FPGA相關的操作系統選擇

　　基于FPGA的應用引入了一個將時間緊迫任務用硬件實現的重要方法，使選擇操作系統在時間約束方面得到緩解，參見圖4。這張圖顯示了本文中討論過的各種選擇的響應范圍。因為它是可編程邏輯，FPGA為設計者提供了精細的增量控制執行。因為它是硬件，它對實時事件的響應極快。如圖所示，該響應可用于擴大服務范圍，甚至更大的操作系統。

?

　　圖4 響應范圍

　　結論

　　用可編程邏輯的SoC平臺的設計，如FPGA芯片里的LatticeMico32，給系統設計師提供了難得的機會，因為他們可以選擇自己喜歡的硬件支持和輕載功能。這使得系統設計師通過轉移軟件到FPGA中執行數據路徑，來滿足時間上的限制。這一做法改變了對操作系統的標準選擇判據，使得在實時操作系統和通用操作系統解決方案之間有更靈活的選擇。雖然商業實時操作系統在確定中斷響應方面仍然有其優勢，但通過使用FPGA中實現的減負引擎后，通用操作系統的解決方案(如Linux )可能成為適合于較大的應用領域?！败泴崟r”的解決方案，如RT Linux或Xenomai，這時就顯得不那么理想了，因為使用減負引擎可以提供更好的響應而沒有額外的工程費用。

?

?