所有的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抽象層的分層軟體架構示例。

Operating system layers

圖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@,最新消息一手掌握!

發表評論