首頁　＞　消息與活動 ＞　是不是該是時候使用一個標準的RTOS API 了？(ISN’T IT ABOUT TIME FOR A STANDARD RTOS API?)

是不是該是時候使用一個標準的RTOS API 了？(ISN’T IT ABOUT ... 2023-05-24

May 24, 2023 | 5 min read

 

By Bill Lamie

President/CEO, PX5

嵌入式微控制器(MCUs)使用了似乎無窮盡的實時操作系統(RTOSes)，其中大多數擁有自己的專有功能和獨特的API。其中一些API很好，而其他一些則不太好。事實上，好的RTOS API和不太好的RTOS API之間的差異非常小- 大多數RTOS API都能達到目的。回顧我過去30多年的經驗，我逐漸意識到專有RTOS API對嵌入式開發和整個行業都產生了深遠的負面影響。

首先，專有RTOS API代表了應用韌體的鎖定。使用專有RTOS API編寫的代碼必須進行修改，以遷移到不同的RTOS。更糟糕的是，遷移到另一個RTOS所需的修改可能會令人生畏。一些RTOS供應商添加了適配層，試圖支持其他API。然而，這種解決方案並不理想，因為它通常試圖將方形物體塞入圓孔中。更不用說額外的層次會大大增加RTOS的開銷和複雜性，這反過來可能導致錯誤。

在任何情況下，無法輕易遷移應用代碼會嚴重限制產品的演進。例如，如果一個應用依賴於RTOS XYZ，而該RTOS不支持最新和最強大的處理器，該應用要麼需要修改其代碼庫以遷移到另一個RTOS，要麼等到RTOS XYX添加支持，要麼放棄。同樣地，將基於RTOS XYZ的應用遷移到嵌入式Linux（另一個非常常見的情況）很困難，因為嵌入式Linux中的多線程是基於POSIX pthreads API的。標準的RTOS API將有助於消除鎖定，從而使嵌入式應用更具可移植性，並增強其未來的演進。

專有RTOS API還需要廣泛的培訓。大多數首次使用RTOS的開發人員需要花費大量時間學習專有RTOS API。即使是使用FreeRTOS或Microsoft的Azure RTOS ThreadX - 這兩個流行的嵌入式RTOS，每個都有自己的專有API的嵌入式開發人員，也只佔總開發人數的一小部分。這裡的重點是專有RTOS API需要學習，這對公司來說是時間和金錢的成本。業界標準的RTOS API將減少培訓成本，從而節省金錢，並提高設備製造商的上市時間。

另一個問題是，一些設備製造商的產品系列既包含MCU處理器，又包含MPU處理器，通常具有不同的功能和價格點。他們基於MPU的產品通常使用一種嵌入式Linux的變體。對於這些公司來說，由於專有RTOS API，必須維護獨立的開發團隊（和代碼庫）既困難又昂貴。使用標準的RTOS API，應用代碼可以在MPU和MCU項目之間即時共享，從編碼和測試到產品發布，改進整個開發過程。

 

標準的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 API已在UNIX/Linux系統上進行了30多年的測試。將硬實時能力與這種工業標準API結合在一起，將為嵌入式開發人員提供最佳的解決方案。我們的行業只需要各種RTOS提供商原生地採用它。在POSIX pthread API標準上統一嵌入式行業將消除鎖定，加速嵌入式產品的演進，減少培訓成本，並立即實現代碼共享和MCU和MPU設備之間的遷移- 這對嵌入式行業來說是一個重大的進步。