嵌入式MCU使用的RTOS數量似乎無窮無盡，其中大多數都有自己專有的功能和獨特的API。有些RTOS的API很好，有些就不那么好了。事實上，好的和不太好的RTOS API之間的差異很小——大多數RTOS API都可以。回顧過去的30多年，專有的RTOS API已經并將繼續對嵌入式軟件開發和整個嵌入式行業產生深遠的負面影響。

首先，專有的RTOS API代表了應用固件的鎖定。使用專有的RTOS API編寫的代碼必須進行更改，以便遷移到不同的RTOS。更糟糕的是，轉向另一個RTOS所需的改變可能令人望而生畏。一些RTOS供應商已經添加了一個適配層，試圖支持其他RTOS API。然而，這種解決方案并不理想，因為它經常試圖將一個方釘安裝在一個圓孔中。更不用說額外的層大大增加了RTOS的開銷和復雜性，這又會導致錯誤。

在任何情況下，不能輕松地移植嵌入式應用程序代碼都會嚴重限制產品的發展。例如，如果一個應用程序依賴于RTOS XYZ公司，并且它不支持最新和最好的處理器，應用程序開發人員要么需要修改代碼庫以轉移到另一個RTOS，要么等到RTOS XYX公司增加支持，要么干脆放棄。類似地，將基于RTOS·XYZ的應用程序移植到嵌入式Linux(另一種非常常見的情況)也很困難，因為嵌入式Linux中的多線程是基于POSIX pthreads API的。一個標準的RTOS API將有助于消除鎖定，從而使嵌入式應用程序更加可移植，并促進其未來的發展。

專有的RTOS API也需要大量的培訓。大多數第一次使用RTOS的開發者不得不花費大量的時間學習專有的RTOS API。即使是使用FreeRTOS或微軟Azure RTOS、ThreadX的嵌入式軟件開發人員——兩者都是流行的嵌入式RTOS，都有自己專有的API——也只占軟件開發人員總數的很小一部分。這里的要點是，專有的RTOS API需要學習，這耗費了公司的時間和金錢。行業標準的RTOS API將減少培訓，從而節省資金并加快設備制造商的上市時間。

另一個問題是，一些設備制造商的產品系列跨越MCU和MPU處理器，通常具有不同的功能和價位。他們基于微處理器的產品經常使用一些嵌入式Linux。對于這些公司來說，因為專有的RTOS API而不得不維護獨立的開發團隊(和代碼庫)既困難又昂貴。有了標準的RTOS API，應用代碼可以在基于微處理器和基于微控制器的項目之間即時共享，從而改進整個開發過程，從編碼和測試到產品發布。

標準的RTOS API應該是什么？

在我們進一步討論之前，應該感謝Arm，因為他們在很多年前就發現了嵌入式行業的這個問題，甚至試圖用CMSIS-RTOS API來解決這個問題。不幸的是，CMSIS RTOS API最終還是另一個專有的RTOS API。

回到標準的RTOS API應該是什么樣子。有趣的是，答案多年來一直就在我們面前:標準的RTOS API應該是相同的行業標準POSIX pthread API，它已經是每個嵌入式Linux發行版以及每個大學計算機科學課程的一部分。由于嵌入式Linux代表了70%的嵌入式設計，因此很容易認為POSIX pthread API已經是嵌入式軟件領域的RTOS API標準，也是大多數嵌入式開發人員已經熟悉的標準。

此外，POSIX pthread APIs已經在UNIX/Linux系統上測試了30多年。將硬實時RTOS功能與此行業標準API相結合，使嵌入式開發人員能夠兩全其美。我們的行業只需要各種RTOS提供商在本地采用它。將嵌入式軟件行業統一在POSIX pthread API標準上，將消除供應商鎖定，加速嵌入式產品發展，減少培訓，并立即實現MCU類和MPU類設備之間的代碼共享和遷移——所有這些都代表著嵌入式行業向前邁進了一大步。