嵌入式開發：你應該抽象化你的RTOS嗎?

現代嵌入式系統已經成為復雜的計算設備，需要Linux或實時操作系統(RTOS)來幫助嵌入式開發人員管理其實時約束。對于RTOS用戶來說，開發人員需要做出一個有趣的設計決策;你應該將RTOS從應用程序中抽象出來還是解耦?

不抽象RTOS的理由

對于上面的問題，一個流行的答案是團隊不要抽象他們的RTOS。相反，RTOS成為整個應用程序的核心組件。將應用程序與RTOS緊密耦合有很多好處。

首先，大多數抽象層都是為了滿足最低標準的特性而編寫的。這意味著如果你使用一個抽象層，并且只想遵循它所提供的特性，你可能會失去RTOS的一些功能。每臺RTOS都有獨特的功能，旨在應對特定細分市場的挑戰。雖然你會發現創建任務、隊列等標準功能，但你可能不會發現內存保護單元的抽象、與ArmTrustZone的集成或其他功能。

接下來，你可能會發現使用抽象層會降低系統性能。今天的編譯器一般足夠好，可以進行適當的優化;但是，額外的調用和設置可能會占用額外的時鐘周期和內存。

最后，調試和故障排除會變得更加復雜。如果你通過抽象層與RTOS進行交互，并且出現了問題，那么你將被從細節中抽象出來。直接使用RTOS可以為嵌入式開發人員提供更好的工具和更大的可見性來解決問題。

抽象你的RTOS的理由

今天開發的許多嵌入式應用程序都是在這樣的期望下創建的，即在十年或更長的時間內，核心代碼將會生成多種產品。產品在領域中活躍的時間也差不多，開發人員在設計和實現他們的系統時必須考慮到變化。RTOS解決方案來來去去。支持時好時壞。如果你想讓你的代碼經受住時間的考驗，你的應用程序不能寫得對你的RTOS有很強的依賴性。RTOS必須被抽象化。抽象RTOS有很多好處。

首先，抽象層使得在短時間內更改RTOS解決方案變得更加容易。你可能會問，“我為什么要改變我的RTOS?”，更好的解決方案可能會出現，或者RTOS在所需的應用領域可能會出現問題。也許嵌入式開發開發人員的流失會導致團隊不具備特定RTOS的經驗，所以改變是不可避免的。有了抽象層，你可以通過對單個文件進行更改來更改RTOS，而不是更新代碼庫中的幾乎每個模塊。

接下來，我們可以從另一個角度來看前面的原因。抽象層將你的應用程序從RTOS中分離出來。消除應用程序對RTOS的依賴使你的代碼更具可重用性和可移植性。我們都聽說過可靠的原則，其中之一就是利用依賴倒置原則。你應該希望依賴于接口，這樣你就可以打破耦合。

最后，RTOS的抽象層可以簡化與RTOS的交互。抽象層通常包含許多RTOSs支持的標準特性的子集。例如，CMSIS-RTOSsv2提供了一個抽象層，芯片供應商通常使用它來支持多個RTOS。如果你檢查CMSIS-RTOSv2中包含的子集，以及幾個常見RTOS(如FreeRTOS、AzureRTOS和澤法)的API集，你會發現它們的API包含一些共同的元素，但卻完全不同。簡化的抽象使得開發人員更容易以一種通用的方式與各種RTOS進行交互。