作者：Jacob Beningo

在嵌入式系統行業的開發人員和經理中流傳著一個謠言，即所有RTOS都是平等的。開發團隊僅僅選擇RTOS的情況并不少見，因為他們的微控制器供應商支持RTOS，而不是仔細檢查RTOS提供的功能和特性。檢查RTOS的特性、API、功能和陷阱經常被忽視，甚至有時會損害應用程序的需求。您可能從未意識到的撓癢癢問題：“所有實時操作系統都是等效的嗎？

對等效的需求

基本上有三種方法可以了解如何構建嵌入式軟件。首先，開發人員在沒有RTOS或操作系統的情況下構建系統裸機。這些通常適用于沒有很多功能或不關心重用、可移植性或可擴展性的小型嵌入式系統。接下來，一些團隊有一個需要可伸縮性和可重用性的系統，但可能沒有可移植性。這些團隊將選擇一個實時操作系統來使用，并圍繞實時操作系統構建整個應用程序，使實時操作系統成為系統的基礎。

構建系統的最后一種方法，也是驅動對等效的需求或愿望的方法，是復雜的現代系統，并提供廣泛的功能。在許多情況下，應用程序需要擴展、可重用和可移植。在這些情況下，團隊不能只選擇一個RTOS并圍繞它構建他們的應用程序。相反，他們需要一個RTOS抽象層，將其應用程序代碼與RTOS分離，以選擇提供應用程序所需服務和功能的任何RTOS或操作系統。圖 1 顯示了具有 RTOS 抽象層的分層軟件架構示例。

圖 1 – 現代系統將嵌入式應用程序與 RTOS 分離，以提高重用、可移植性、可擴展性和測試。（圖片來源：嵌入式軟件設計［1］）

RTOS抽象層消除了對任何RTOS或操作系統的依賴，從而實現了更好的單元測試和超目標運行應用程序仿真的能力！當然，出現的問題是，當團隊創建RTOS抽象層時，他們拼命地試圖建議所有RTOS都提供等效的功能，當通用化時，就變成了“所有RTOS都是等效的”。

實時操作系統等效現實

不幸的是，或者幸運的是，對于嵌入式軟件架構師和團隊來說，并非所有RTOS都是平等的。每個RTOS都可以提供一組標準功能，但即使這些功能也已實現并提供廣泛的差異。例如，從當前可用的一百多個 RTOS 中選擇三個并檢查其 API 集。您會發現相似但差異很大的 API。

如果您花一些時間運行性能測量，您會發現每個RTOS都提供不同級別的實時性能和確定性。編譯每個，您會發現不同的內存要求。如果您深入研究實時操作系統，您甚至可能會發現可能破壞實時操作系統的錯誤或條件！有些在管理安全性方面寫得很好，而另一些則完全忽略了安全性是一個考慮因素。

當我第一次接觸實時操作系統時，我討厭它們。我的雇主當時提供給我的RTOS有缺陷，不一致，我花在與RTOS斗爭上的時間比編寫生產代碼的時間還要多。事實證明，“RTOS”并不是我們所認為的實時操作系統！相反，它是一個編寫不佳的協作調度程序，包括一些RTOS功能，如信號量和隊列。

結論

歸根結底，團隊可能希望所有實時操作系統都是等效的，但事實仍然是每個實時操作系統都是獨一無二的。每個都提供具有不同內存占用、響應時間、API、安全性和安全功能的操作系統。RTOS 抽象層可以幫助嵌入式應用與標準功能分離。不過，要充分利用 RTOS，可能需要直接調用 RTOS 或創建抽象擴展來管理應用程序依賴關系。因此，下次當您想只使用微控制器供應商提供的RTOS運行時，請花一些時間來評估和驗證RTOS是否滿足您的需求，因為每個RTOS都是不同的，盡管它們看起來可能是等效的。

編輯：黃飛