所有的RTOS「生而平等」？
作者 : Jacob Beningo，嵌入式軟體顧問
開發團隊經常簡單地選擇RTOS，只是因為他們的微控制器(MCU)供應商提供了支援，而非仔細地檢查RTOS提供的功能和特性。開發人員經常忽略了要檢查RTOS的特性、API、功能和缺點，甚至有時還損害到應用的需求。您可能從未意識到的問題是：所有的RTOS都等效嗎？
嵌入式系統產業的開發人員和管理人員之間流傳著這樣的謠言：所有的即時作業系統(RTOS)「生而平等」(All RTOSes are created equal.)。開發團隊經常簡單地選擇RTOS，只是因為他們的微控制器(MCU)供應商提供了支援，而非仔細地檢查RTOS提供的功能和特性。開發人員經常忽略了要檢查RTOS的特性、API、功能和缺點，甚至有時還損害到應用的需求。您可能從未意識到的問題是：「所有的RTOS都等效嗎？」(Are all RTOSes equivalent?)
等效的需要
基本上有三種方法用於探討如何建構嵌入式軟體。首先，開發人員在沒有RTOS或作業系統(OS)的情況下建構系統裸機(bare-metal)。這些通常適用於那些沒有太多功能或不特別關注於可重用、可移植或可擴展的小型嵌入式系統。其次，有些團隊的系統需要可擴展性和可重用性，但也許並不需要可移植性。這些團隊就可以選擇一種RTOS使用，並圍繞著RTOS建構其整體應用，使該RTOS成為系統的基礎。
建構系統的最後一種方法，也是驅動對於等效需求或渴望的方法，它是一種複雜但提供廣泛功能的現代系統。在許多情況下，應用需要擴展、被重用且可移植。在這些情況下，開發團隊不能只選擇一種RTOS並以其為基礎來建構應用。相反地，他們需要一個RTOS抽象層，將其應用程式碼與RTOS分離，並選擇其他任何提供應用所需服務和功能的RTOS或作業系統。圖1顯示具有RTOS抽象層的分層軟體架構示例。
圖1：現代系統將嵌入式應用與RTOS分離，以提高重用性、可移植性、可擴展性和測試。（圖片來源：Embedded Software Design）
RTOS抽象層消除了對任何RTOS或作業系統的依賴，從而實現更好的單元測試以及脫靶(off-target)執行應用模擬的能力！當然，可能出現的問題是，當開發團隊創建一個RTOS抽象層時，可能拼命地試圖暗示所有RTOS提供等效功能，而當概括化來看時，卻變成了「所有RTOS都是等效的」。
RTOS的等效現實
遺憾的是(抑或者說是幸運？)，對於嵌入式軟體架構師和團隊來說，並非所有的RTOS「生而平等」。每個RTOS都可能提供一組標準功能，但即使是這些功能已建置也提供了廣泛差異。例如，從目前約百種可用的RTOS中挑選三種，並檢查其API組合。您會發現看來彼此相似的這些API其實差異很大。
如果您要花一些時間來執行效能測量，將會發現每個RTOS都提供不同程度的即時性能和確定性。為每一個進行編譯時，你會發現不同的記憶體需求。如果您深入研究RTOS，也許還會發現可能破壞RTOS的錯誤或情況！有些RTOS在安全性方面編寫得很好，而其他的則可能完全忽略了安全性是一項重要考慮因素。
當我第一次接觸即時作業系統時，真的感覺厭煩。當時公司提供給我的RTOS還有缺陷、而且也不一致，讓我花在對抗RTOS上的時間比編寫產生程式碼的時間還要多。原來，這個“RTOS”並不是我們原本認為的RTOS！相反地，它其實是一種編寫不佳的協作調度程式，只是其中包含了一些RTOS功能，如訊號量和序列等。
結論
總而言之，開發團隊可能希望所有的RTOS都是等效的，但事實上，每個RTOS都是獨一無二的。每個RTOS都提供了一個具有不同記憶體空間、響應時間、API、安全性和安全功能的作業系統。RTOS抽象層有助於將嵌入式應用與標準功能分離開來。儘管如此，為了充份利用RTOS，可能需要直接調用RTOS或創建抽象擴展來管理應用依賴關係。因此，下一次當您想直接使用MCU供應商提供的RTOS執行時，請花一些時間評估並驗證RTOS是否滿足您的需求，因為每個RTOS儘管看起來可能相似，但他們都不一樣。
編譯：Susan Hong
(參考原文：Are all RTOSes equivalent?，by Jacob Beningo)
加入LINE@，最新消息一手掌握！
