現(xiàn)代嵌入式系統(tǒng)已經(jīng)成為復(fù)雜的計(jì)算設(shè)備，需要Linux或?qū)崟r(shí)操作系統(tǒng)(RTOS)來幫助嵌入式開發(fā)人員管理其實(shí)時(shí)約束。對(duì)于RTOS用戶來說，開發(fā)人員需要做出一個(gè)有趣的設(shè)計(jì)決策;你應(yīng)該將RTOS從應(yīng)用程序中抽象出來還是解耦?

不抽象RTOS的理由

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

首先，大多數(shù)抽象層都是為了滿足最低標(biāo)準(zhǔn)的特性而編寫的。這意味著如果你使用一個(gè)抽象層，并且只想遵循它所提供的特性，你可能會(huì)失去RTOS的一些功能。每臺(tái)RTOS都有獨(dú)特的功能，旨在應(yīng)對(duì)特定細(xì)分市場(chǎng)的挑戰(zhàn)。雖然你會(huì)發(fā)現(xiàn)創(chuàng)建任務(wù)、隊(duì)列等標(biāo)準(zhǔn)功能，但你可能不會(huì)發(fā)現(xiàn)內(nèi)存保護(hù)單元的抽象、與ArmTrustZone的集成或其他功能。

接下來，你可能會(huì)發(fā)現(xiàn)使用抽象層會(huì)降低系統(tǒng)性能。今天的編譯器一般足夠好，可以進(jìn)行適當(dāng)?shù)膬?yōu)化;但是，額外的調(diào)用和設(shè)置可能會(huì)占用額外的時(shí)鐘周期和內(nèi)存。

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

抽象你的RTOS的理由

今天開發(fā)的許多嵌入式應(yīng)用程序都是在這樣的期望下創(chuàng)建的，即在十年或更長的時(shí)間內(nèi)，核心代碼將會(huì)生成多種產(chǎn)品。產(chǎn)品在領(lǐng)域中活躍的時(shí)間也差不多，開發(fā)人員在設(shè)計(jì)和實(shí)現(xiàn)他們的系統(tǒng)時(shí)必須考慮到變化。RTOS解決方案來來去去。支持時(shí)好時(shí)壞。如果你想讓你的代碼經(jīng)受住時(shí)間的考驗(yàn)，你的應(yīng)用程序不能寫得對(duì)你的RTOS有很強(qiáng)的依賴性。RTOS必須被抽象化。抽象RTOS有很多好處。

首先，抽象層使得在短時(shí)間內(nèi)更改RTOS解決方案變得更加容易。你可能會(huì)問，“我為什么要改變我的RTOS?”，更好的解決方案可能會(huì)出現(xiàn)，或者RTOS在所需的應(yīng)用領(lǐng)域可能會(huì)出現(xiàn)問題。也許嵌入式開發(fā)開發(fā)人員的流失會(huì)導(dǎo)致團(tuán)隊(duì)不具備特定RTOS的經(jīng)驗(yàn)，所以改變是不可避免的。有了抽象層，你可以通過對(duì)單個(gè)文件進(jìn)行更改來更改RTOS，而不是更新代碼庫中的幾乎每個(gè)模塊。

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

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