遵循一些簡單的步驟，您將做出正確的 RTOS 選擇

　　RTOS 由內核和中間件組成。需要中間件來高效可靠地執行某些功能。如果它滿足這些要求，它就沒有什么進一步的后果了。然而，內核是嵌入式設計的核心。它極大地影響了設計的完成方式，并且是嵌入式程序員與之交互最多的內容。因此，將“內核”稱為“RTOS”已成為行業慣例。我在這里堅持這種做法。

　　選擇 RTOS 的一個問題是它通常在項目開始時完成，在系統設計完成甚至開始之前。那時，人們對需要哪些 RTOS 功能知之甚少。鑒于沒有理由不這樣做，許多程序員傾向于選擇簡單、低成本或免費的 RTOS，然后接受其局限性。這顯然是一種非最佳方法，它可能會浪費人月的努力和最終系統的延遲交付。

　　我提供了一種不同的方法來選擇 RTOS，我的方法具有許多您認為不需要的功能。這需要了解這些功能是如何工作的，然后確定它們是否對您的應用程序有用。除非您實際嘗試，否則您如何決定哪些功能對您有用？讓我們首先消除一些關于簡單 RTOS 的常見誤解。然后我們可以討論如何同時創建系統設計并為其選擇 RTOS，而不會過早地鎖定到錯誤的 RTOS。

　　內存使用

　　通常，用于 RTOS 的主要 RAM 用于任務使用的堆棧。如果 RTOS 沒有為中斷提供系統堆棧，那么每個任務的堆棧必須足夠大以處理總 ISR 堆棧要求。如果允許中斷嵌套，最壞情況下的 ISR 堆棧加載可能會向每個任務的堆棧添加數百個字節。如果有大約 20 個任務，這很容易增加 5 到 10 KB 的 RAM。簡單的 RTOS 通常有這個問題。一些 RTOS 甚至允許在任務之間共享堆棧。

　　ROM使用

　　現代鏈接器忽略了未使用的 RTOS 功能。因此，它們不會增加 ROM 占用空間。缺少（即，需要但不存在）RTOS 功能怎么辦？它們必須在應用程序代碼中創建。這不僅需要時間和金錢，而且由于進度壓力，這些功能的實現效率可能低于 RTOS，甚至可能由不同的程序員多次實現，或者可能是不可靠的緊急工作。因此，一個簡單的 RTOS 實際上可能比高級 RTOS 需要更多的 RAM 和 ROM，這可能會給項目帶來更多問題。

　　表現

　　毫無疑問，更少的代碼運行得更快。因此，執行錯誤檢查并提供多種功能的 RTOS 服務將比簡單 RTOS 的精簡等效服務慢。但是，您的 RTOS 需要多少性能？與嵌入式系統中執行的其他處理相比，RTOS 調用和任務切換并不常見。編寫良好的 RTOS（不是 GPOS）可以在“低端”50 MHz Cortex-M3 處理器上實現每秒 50，000 次任務切換。你需要多少？隨著過去十年處理器性能的巨大進步，重要的衡量標準已經從原始 RTOS 性能轉變為它提供的服務的實用性以及它為快速開發可靠系統提供了多少幫助。

　　調試功能和錯誤管理

　　每個人都知道調試代碼比創建代碼花費的時間更多，而且項目通常由于頑固的錯誤而延遲。然而，我們應該做些什么來限制這種未來的痛苦？簡單的 RTOS 通常不會提供比 C 庫 - zilch 更多的幫助。如果你想要理智和美好的家庭生活，這是你應該注意的事情。

　　三維問題

　　選擇 RTOS 是一個三個維度的問題：大小、性能和特性。這些特性共同定義了您的系統所在的嵌入式空間。除此之外，還有許可證和價格維度，但我們將把這些留給業務類型。在這里，我們將專注于我們都感覺更舒服的技術空間。

　　單個 RTOS 無法很好地覆蓋所有嵌入式空間。因此，您必須確定您的應用程序所在的位置才能很好地適應。最好的方法是從上到下開始設計您的應用程序。在另一篇文章圣誕樹 RTOS中，我將這個過程比作裝飾圣誕樹。

　　挑選候選人

　　要開始選擇過程，請查看 RTOS 供應商文獻以找到具有大量有趣功能的候選者。然后，如果它為您喜歡的處理器提供評估套件，您就可以開始了。下載評估套件并讓它在您的處理器的評估板上運行。希望這將是一個快速的過程。如果沒有，請嘗試另一個 RTOS 候選者。

　　入門

　　最好的開始方法是創建擬議系統的框圖。接下來，將塊與線程相關聯（線程是 ISR、任務或其他執行路徑）。這涉及對塊進行分組或拆分。總體目標是將異步操作放入單獨的線程中，將中斷驅動的操作放入 ISR，并將高級操作放入任務中。中間操作可以放入回調函數或鏈接服務例程（LSR）中，這是一種更結構化的回調函數形式。

　　隨著您的進步，框圖將很快變得笨拙。當這種情況發生時，就是編寫代碼的好時機。這里的目標是創建骨架 ISR、任務和 LSR。這可以通過任何 RTOS 完成。只需使用 RTOS 服務來創建和控制 RTOS 對象。當您深入了解您需要哪些 RTOS 服務時，您可能希望比較每位 RTOS 候選人如何完成特定工作，并繼續選擇您最喜歡的工作。

　　放入延遲存根以模擬實際代碼及其估計的延遲。還要放入最少的代碼來模擬將數據加載到消息中并將它們發送到其他任務，以及模擬系統需要執行的其他操作。使用信號量、互斥量等，實現順序。延遲和模擬不需要準確開始。

　　隨著你的進步，經常構建你的系統并使用調試器來了解它是如何工作的。你會經常感到驚訝！注意：單步執行很有用，但您需要在許多戰略性位置設置斷點以查看實際發生的情況。否則，在一個步驟期間，可能會發生中斷，可能會運行多個任務，您會想知道這個或那個是如何神奇地發生的。多任務系統往往具有自己的生命，這可能不是您所期望的。意外可能會讓您深入了解候選 RTOS，以更好地了解其工作原理或發現其實施中的缺陷。您可能需要考慮不同 RTOS 提供的替代方法。最好早點面對系統設計的驚喜，而不是在編寫了大量代碼并痛苦地調試之后。

　　這也是開始測量應用程序的關鍵時間的好時機，例如中斷延遲、任務切換時間和開銷，以及電源使用情況，以及對這個系統很重要的任何其他事情。當然，要獲得準確的數字，您需要開始改進延遲和模擬。一個很好的副產品是估計的延遲和 RTOS 引起的結構為尚未編寫的代碼設置了界限。延遲可用于在實現之前確定需要優化代碼的位置。如果最終代碼在其邊界內，它將適合系統。這為項目中的每個人提供了安全保障。

　　這有什么好？

　　這種方法的美妙之處在于，在早期你有一些實際運行的東西，其他人可以看到它運行，他們也可以運行它。此外，您還會收到反饋，以確定哪些結構最適合您需要做的事情，并在進行測量以確認您的決定時。然而，您實際上只在代碼中投入了少量工作——如果有必要，大部分的思考和研究可以轉移到不同的 RTOS 或不同的系統設計中。重點更多的是結構而不是功能。

　　許多項目把自己畫到了一個角落，改變 RTOS 或系統設計不再是可行的選擇；編寫了太多代碼以允許改變方向。無論好壞，該項目都被它選擇的任何東西所困擾。這對豆類柜臺和其他所有人來說都是個壞消息。

　　同時，沿著黃磚路繼續前進，您將了解所選 RTOS 的工作原理、哪些功能對您有用、如何使用它們，以及它的調試和內核感知功能如何幫助您解決問題。然而，如果您需要，您也可以在離岸不遠的地方涉水回到旱地并選擇不同的 RTOS 或系統設計。

　　審核編輯：郭婷