使用微控制器的電子產(chǎn)品如今變得如此復(fù)雜，以至于它們通常使用實時操作系統(tǒng)（RTOS）。RTOS可以管理低級資源和時間，從而提高系統(tǒng)的實時性能并簡化應(yīng)用程序。
嵌入式開發(fā)團隊可能會遇到的一個問題是有100多種不同的RTOS可供選擇！對于一個團隊來說，開始使用一個產(chǎn)品，但6個月后決定使用另一個產(chǎn)品的情況并不罕見。當這種情況發(fā)生時，如果開發(fā)人員在他們的應(yīng)用程序中直接使用了RTOS，他們必須返回并更改大量代碼。
另一種方法是使用操作系統(tǒng)抽象層（OSAL）。OSAL創(chuàng)建一組對應(yīng)于每個RTOS中的公共特征的API。OSAL允許應(yīng)用程序通過將依賴關(guān)系轉(zhuǎn)移到抽象層來打破對RTOS的依賴。應(yīng)用程序不再關(guān)心你使用的RTOS，只關(guān)心抽象層。
在今天的帖子中，我們將探討為嵌入式應(yīng)用創(chuàng)建RTOS抽象層的五個技巧。
技巧1：跨操作系統(tǒng)標準化操作系統(tǒng)抽象層（OSAL）API
OSAL的目標不是將RTOS縮小到最小公分母。相反，我們的目標是通過一個單一的標準API提供通用部分，以消除對RTOS的依賴，并改善測試和可移植性。你將需要研究流行的RTOS并確定共同的特性。
例如，如果你查看像FreeRTOS、Azure RTOS和Zephyr這樣的流行RTOS，你可能會發(fā)現(xiàn)它們具有以下標準功能：
線程創(chuàng)建
信號量的創(chuàng)建、獲取和放置
互斥體的創(chuàng)建、鎖定和解鎖
等等。
你希望識別這些標準特性，然后創(chuàng)建一個接口來封裝你可能使用的任何RTOS的創(chuàng)建細節(jié)，同時將應(yīng)用程序與RTOS分離。
技巧2：選擇正確的抽象層次
當你開始為你的應(yīng)用程序開發(fā)OSAL時，創(chuàng)建最終的抽象是很有誘惑力的。不要陷入這個陷阱！每個RTOS都有你想要利用的獨特功能，如果你把它們隔離開來，你會帶來更多的問題而不是好處。你必須選擇正確的抽象層次。
正確的抽象水平將是一個基本的標準特性。一個很好的例子是檢查CMSIS RTOSv2 OSAL。你會注意到他們抽象出的唯一特性是標準特性。你看不到他們實現(xiàn)定制的低功耗設(shè)置或類似的東西。相反，他們正在尋找每個RTOS提供的抽象標準功能。
技巧3：對特定于操作系統(tǒng)的特性使用包裝器
一旦你有了通用的API，你可能會認為你已經(jīng)將RTOS簡化為通用的特性，并且你將只使用這些特性。這不是準確的想法，會有一些不常見的特性可能對你的應(yīng)用程序有用。問題是，如果你直接調(diào)用這些特性，你將把你的應(yīng)用程序緊密耦合到RTOS，這正是我們需要避免的！
使用RTOS特有特性的解決方案是包裝這些特性。你可能有一個覆蓋通用特性的OSAL，但是你最終會得到覆蓋RTOS特有特性的包裝器。包裝器將為應(yīng)用程序提供對定制特性的訪問，同時維護允許脫離目標測試和模擬的依賴樹。
你不能忽略RTOS的競爭優(yōu)勢，但你也不能抽象它們。這就是為什么使用包裝器是一個很好的選擇。如果你更改了RTOS，如果新的RTOS沒有這個特性，你可以移除包裝器并編寫任何需要的gap代碼來覆蓋缺失的功能。
技巧4：優(yōu)雅地處理特定于操作系統(tǒng)的限制
當你開發(fā)一個OSAL時，你需要意識到你必須管理的局限性。例如，一個RTOS的最大線程數(shù)可能與另一個不同。不同RTOS的優(yōu)先級排序可能會有所不同。(隨著數(shù)值越來越遠離0，FreeRTOS任務(wù)具有更高的優(yōu)先級。ThreadX設(shè)置0優(yōu)先級最高，數(shù)字越高優(yōu)先級越低！)
你需要確保你的抽象層能夠成功地管理這些差異，而不會影響應(yīng)用程序的性能。你還需要確保不會因為RTOS實現(xiàn)中的這些微小差異而導(dǎo)致系統(tǒng)崩潰或錯誤。
技巧5：利用單元測試工具來驗證實現(xiàn)
編寫自己的OSAL時，你可以采用的最佳實踐之一是使用測試驅(qū)動開發(fā)(TDD)。TDD的一部分將是你寫你的測試用例，讓它失敗，然后讓它通過。這和OSAL有什么關(guān)系？如果你編寫測試用例來驗證你的OSAL，那么當你將一個RTOS連接到你的OSAL時，你可以驗證它是否正確和成功地完成了！
如果你犯了一個實現(xiàn)錯誤，單元測試應(yīng)該會發(fā)現(xiàn)它！你會立刻知道你有問題，并在它變成bug之前著手解決它。這樣做當然需要更多的工作，但是最終你會發(fā)現(xiàn)你會得到一個更加健壯的OSAL。
結(jié)論
并非所有應(yīng)用程序的RTOS都需要OSAL。但是，如果你正在開發(fā)一個將使用五年或更長時間的應(yīng)用程序框架或平臺，那么擁有一個OSAL是個好主意。嵌入式技術(shù)變化很快，你希望確保你不是在圍繞五年后可能會改變或不存在的軟件設(shè)計框架。返工軟件可能很耗時，而且會引入錯誤。使用OSAL可以確保打破這種依賴性，并且可以在抽象之后加入任何RTOS。