與嵌入式MCU一起使用的RTOS的名單很長，其中大多數都有自己的專有功能以及獨特的API。有些API很好，有些則不太好。實際上，好的和不太好的RTOS API之間的差異相當小——大多數RTOS API都有其專用的功能。回顧過去30多年，我開始意識到私有的RTOS API已經并將繼續對嵌入式開發和我們的整個行業產生負面的影響。

首先，私有的RTOS API代表了應用程序固件的鎖定，使用私有的RTOS API編寫的代碼必須修改才能移植到不同的RTOS。更糟糕的是，移植到另一個RTOS所需的修改可能令人生畏。一些RTOS供應商添加了一個適應層，試圖支持其他API。然而，這個解決方案并不理想，因為它就像在圓孔中安裝一個方形釘子。更不用說額外適配層大大增加了RTOS的開銷和復雜性，它還可能導致錯誤。

無論如何，無法輕松遷移應用程序代碼可能會嚴重限制產品的演變。例如，如果一個應用程序依賴于RTOS XYZ，并且它不支持最新和最高性能的處理器，應用程序要么需要修改其代碼庫以移植到另一個RTOS，要么等到RTOS XYZ添加支持，要么就放棄。同樣，將基于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處理器，通常具有不同的功能和價格特點，他們基于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級設備之間的代碼共享和遷移——所有這些都將推動嵌入式行業向前邁出的重要一步。

作者：Bill Lamie

在商業RTOS領域工作了30多年——他先是創建了Accelerated Technology（被西門子收購），然后是Express Logic（被微軟收購）。Bill是Nucleus和ThreadX的唯一作者。Bill的最新努力是PX5，在那里你可以找到他的最新產品——PX5 RTOS！

審核編輯：湯梓紅