基于mbedOS的事件機制響應(yīng)調(diào)度的實時性分析

汪 恒 王宜懷 劉 肖 劉長勇,2

1(蘇州大學計算機科學與技術(shù)學院 江蘇 蘇州 215006) 2(武夷學院認知計算與智能信息處理福建省高校重點實驗室 福建 武夷山 354300)

0 引 言

mbedOS是由ARM公司針對ARM CortexM系列處理器專門打造用于物聯(lián)網(wǎng)(IoT)的一種開源嵌入式實時操作系統(tǒng)(RTOS)[1-2]。對于實時操作系統(tǒng)來說,其實時性是其最重要的特征,它必須對所接收到的某些信號做出“及時”或“實時”的反應(yīng),在規(guī)定的時間內(nèi)完成任務(wù)的處理[3-5]。而mbedOS提供了相當多的系統(tǒng)服務(wù)來實現(xiàn)任務(wù)的實時控制,如事件機制、線程信號機制、消息隊列機制、互斥鎖機制和信號量機制等[6-7],有著優(yōu)越的實時性,故通常被用于對響應(yīng)時間有較高實時性要求的嵌入式系統(tǒng),如智能終端和物聯(lián)網(wǎng)節(jié)點等。

目前有關(guān)RTOS的實時性分析大多是從整體的實時能力來考慮,通過上下文切換時間、中斷響應(yīng)速度等指標進行總體的實時性考量[8]。但實際應(yīng)用RTOS來進行任務(wù)的控制時,其實時性的高低通常會受到使用的控制機制影響,針對具體機制進行實時性分析,能為應(yīng)用該機制提供有效的參考。對此,提出一種基于printf函數(shù)的時序分析方法,對mbedOS中事件機制的實時性進行剖析。printf函數(shù)是嵌入式開發(fā)中被廣泛應(yīng)用于調(diào)試的重要手段,有專家甚至認為printf是嵌入式發(fā)展過程中的長期基石,通過重要數(shù)據(jù)、程序運行狀態(tài)等調(diào)試信息的輸出,能有效加強初學者在嵌入式端的學習和理解、提高開發(fā)人員排除BUG的效率[9-10]。本文利用STM32L431RC芯片結(jié)合mbedOS程序框架,通過中斷與線程的同步實驗,在簡要分析事件機制響應(yīng)調(diào)度的整個流程及其理論執(zhí)行時間的基礎(chǔ)上,結(jié)合printf方法輸出測試了實際響應(yīng)時間并進行分段解析,最后對影響事件機制響應(yīng)時間的主要因素進行探究。通過printf對mbedOS事件機制實時性的深入剖析,能有效了解事件機制的實際響應(yīng)時間,提供對任務(wù)的更精確控制[11],減少因超出任務(wù)截止時間導致某些難以預(yù)測結(jié)果的可能性,同時也為其他RTOS的實時性分析及有關(guān)應(yīng)用提供技術(shù)基礎(chǔ)。

1 事件的含義與作用

同步是一種協(xié)調(diào)任務(wù)執(zhí)行順序避免發(fā)生時間相關(guān)差錯的機制,RTOS通常利用同步機制實現(xiàn)任務(wù)的有序調(diào)度來進行實時控制[12-13]。而事件是RTOS中同步機制中的一種重要手段,相比控制條件單一的信號量、互斥量等機制而言,事件機制可以通過事件的“與”和“或”多種邏輯組合來擁有更加豐富的控制功能。但事件本身只是用作一種控制信號,故無法類似消息隊列機制一樣傳輸數(shù)據(jù),因此事件一般用于不需要傳送數(shù)據(jù)的場合。事件機制在早期出現(xiàn)的RTOS中就一直存在,無論是在1989年出現(xiàn)的MQX,還是之后陸續(xù)出現(xiàn)的諸如μC/OS、FreeRTOS及2014年Arm公司出品的mbedOS等RTOS中,事件機制始終被保留并不斷完善。不同RTOS對事件的稱呼不太一樣,例如MQX中事件被稱為事件組,μC/OS和FreeRTOS中稱為事件標志組,mbdeOS中稱為事件字或事件標志字等,但其原理和作用基本一致。

事件通常用一個32位的字來表示,字中的每一位都可表示一個事件,相互獨立且互不干擾?？梢哉J為事件字是一個公共資源,與全局變量形式上很類似,但更方便RTOS對任務(wù)的控制和管理。使用事件機制進行同步時,一定會有一個任務(wù)在等待事件,然后由其他任務(wù)或中斷來設(shè)置事件位通知事件完成[14-17]。

對事件進行操作的常用函數(shù)一般有三種:等待函數(shù)、設(shè)置函數(shù)和清除函數(shù)。等待函數(shù)一般由被控制的任務(wù)使用,任務(wù)通過該函數(shù)進入等待事件狀態(tài)并進入阻塞;設(shè)置函數(shù)通常由其他任務(wù)或中斷使用,通過設(shè)置事件字的指定事件位(即事件字對應(yīng)位進行置1)讓等待事件的線程退出阻塞狀態(tài)接受調(diào)度;清除函數(shù)則是清除指定的事件位(事件位清0)。在mbedOS中,常用wait_any()等待事件、set()設(shè)置事件、clear()清除事件,與其他RTOS中的事件函數(shù)相比,mbedOS中事件函數(shù)在功能上并未發(fā)生太大的變化,但基于ARM的OS體系,使得事件函數(shù)每次被調(diào)用時都會觸發(fā)相應(yīng)的系統(tǒng)服務(wù)調(diào)用SVC(Supervisor Call)中斷或可掛起系統(tǒng)調(diào)用PendSV(Pendable Supervisor)中斷,從而進行對應(yīng)的調(diào)度過程。這種保護機制能有效提高系統(tǒng)的穩(wěn)定性,但在某種程度上也加大了進行時序分析的難度,如何在這些干擾因素下進行有效而精確的時序分析是很重要的。

2 基于printf函數(shù)的時序分析方法

本文對mbedOS中事件機制響應(yīng)調(diào)度的實時性分析主要通過printf函數(shù)來實現(xiàn)。在嵌入式領(lǐng)域中,通常利用printf進行打樁調(diào)試來定位BUG,或是輸出有效的提示信息來輔助理解程序執(zhí)行的動態(tài)過程。但是printf的問題在于輸出速度較慢,直接用于時序分析時會對系統(tǒng)的實時性能有較大的影響。經(jīng)測試,在48 MHz的內(nèi)核時鐘頻率下,輸出一個字符平均大約需要80 μs,可見輸出字符的操作本身會占用較多時間。這點在周期較長、粗糙的時序分析時或許不明顯,但對于實時性較高的RTOS,幾秒甚至是毫秒、微秒級的誤差就有可能導致較為嚴重的后果。故利用printf來進行精確的時序分析時,有必要通過主觀的編程手段來排除這部分誤差。

測試時通常根據(jù)一段代碼開始和結(jié)束這兩端的時間差來有效算出該段代碼的實際執(zhí)行時間,為了避免在測試代碼兩端直接加printf帶來的較大時間誤差,可以利用全局變量保存代碼兩端時間的方式,將printf輸出放到測試代碼外執(zhí)行,而全局變量賦值花費的時間是在納秒級,基本可以忽略其影響,這樣能保證得到較為精確的結(jié)果。

測試時間一般會基于一個統(tǒng)一的定時器,在mbedOS中,存在一個利用時間嘀嗒中斷來進行整體任務(wù)調(diào)度的定時器SysTick。該定時器是一個24位的遞減計數(shù)器,其中斷周期默認為1 ms,對應(yīng)SysTick中的計數(shù)器需要計數(shù)48 000次。由于每次嘀嗒中斷會讓內(nèi)核中嘀嗒計數(shù)結(jié)構(gòu)體變量osRtxInfo.kernel.tick加1來保存嘀嗒次數(shù),故根據(jù)嘀嗒計數(shù)和SysTick自身計數(shù)器的計數(shù)值便能夠有效計算出具體當前時間[18]。基于SysTick定時器的時間具體計算方式為[osRtxInfo.kernel.tick×1 000+(48 000-SysTick->VAL)/48 000×1 000],其中SysTick->VAL為計數(shù)器對應(yīng)值,時間單位為微秒。但要注意的是,在執(zhí)行某些諸如SVC和PendSV等過程時,Systick中斷會被推遲執(zhí)行,此時嘀嗒計數(shù)值osRtxInfo.kernel.tick不會發(fā)生變化,故只能根據(jù)SysTick計數(shù)器的值來算出1 ms之內(nèi)的有效執(zhí)行時間。

3 mbedOS的事件機制實時性分析與實踐

本文實驗選用的開發(fā)板型號為STM32L431RC,對應(yīng)的集成開發(fā)環(huán)境為意法半導體(ST)公司推出的STM32CubeIDE 1.3.0開發(fā)工具,移植的工程框架基于5.15.1版本的mbedOS。該開發(fā)板是Cortex-M4內(nèi)核,其RAM大小為64 KB,一般用來存放堆棧、靜態(tài)變量與全局變量等;另外,主要用于存放程序代碼、中斷向量表、常數(shù)等內(nèi)容的Flash區(qū)大小為256 KB[19]。

3.1 測試工程功能設(shè)計

測試工程的功能主要依靠串口中斷服務(wù)程序以及mbedOS啟動后依次創(chuàng)建的優(yōu)先級為1的空閑線程、優(yōu)先級為24的藍燈線程來實現(xiàn)。藍燈線程調(diào)用wait_any()等待藍燈事件即等待藍燈事件位被設(shè)置,從而反轉(zhuǎn)藍燈亮暗,同時用于printf輸出測試過程中保存在全局變量中的時間信息;低優(yōu)先級的空閑線程保證在藍燈線程因等待藍燈事件進入阻塞后能占據(jù)CPU,確保MCU處于運行狀態(tài);串口中斷服務(wù)程序始終開放,等待接收字符并進行判斷,如果接收到的字符為“b”,就調(diào)用set()設(shè)置藍燈事件位。測試工程的執(zhí)行流程如圖1所示。

圖1 測試工程執(zhí)行流程

3.2 事件響應(yīng)調(diào)度的實時性分析

事件響應(yīng)調(diào)度的方式一般有兩種:一種是線程等待中斷設(shè)置事件位來響應(yīng)PendSV調(diào)度;另一種是線程等待其他線程設(shè)置事件位來響應(yīng)SVC調(diào)度。本文主要通過中斷與線程的同步實驗來具體剖析線程響應(yīng)PendSV調(diào)度的實時性。

藍燈線程優(yōu)先級最高,首先被SysTick中斷調(diào)度開始運行,調(diào)用wait_any()等待事件位被設(shè)置。在wait_any()過程中,藍燈線程被設(shè)置為等待事件位狀態(tài)且進入等待隊列(osRtxInfo.thread.wait_list)和事件阻塞隊列(osRtxEventFlags_t.thread_list),并從就緒隊列(osRtxInfo.thread.ready)中取出空閑線程開始運行。此時藍燈線程阻塞,等待系統(tǒng)發(fā)出信號(中斷設(shè)置事件位)來響應(yīng)調(diào)度。

3.2.1理論響應(yīng)時間分析

響應(yīng)PendSV調(diào)度的整段過程是從串口中斷調(diào)用set()設(shè)置事件位開始,到等待事件位的藍燈線程被正式切換運行結(jié)束。根據(jù)編譯后的.lst文件,找到這段過程對應(yīng)的代碼,其機器指令為1 680條。測試芯片的系統(tǒng)時鐘頻率為48 MHz,即一條機器指令執(zhí)行時間為1/48 μs,故該過程對應(yīng)的理論執(zhí)行時間即響應(yīng)時間約為35 μs。

3.2.2實際響應(yīng)時間分析

實際響應(yīng)時間會根據(jù)硬件因素有所不同,但不會偏離理論響應(yīng)時間太多,可以基本確定實際響應(yīng)時間是在1 ms之內(nèi),故可以利用系統(tǒng)內(nèi)的SysTick時鐘有效測出響應(yīng)PendSV調(diào)度的實際響應(yīng)時間。

1) 總響應(yīng)時間分析。分別在測試工程中串口中斷的set()前一句和藍燈線程的wait_any()后一句插入時間賦值語句,即將[osRtxInfo.kernel.tick×1 000+(48 000-SysTick->VAL)/48 000×1 000]賦值給對應(yīng)的全局變量,并在藍燈線程中利用printf輸出兩次時間值及對應(yīng)差值。進行百次輸出實驗,去除對應(yīng)osRtxInfo.kernel.tick值不一樣的測試結(jié)果,這是因為在進行printf輸出時,藍燈線程已經(jīng)被調(diào)度完成,osRtxInfo.kernel.tick可以正常增長,雖然printf輸出這段過程極為短暫,但依舊會產(chǎn)生極少數(shù)的osRtxInfo.kernel.tick值不同的結(jié)果,為使結(jié)果更加精確,排除這部分異常數(shù)據(jù),得到時間差值的均值為41 μs,即該過程總執(zhí)行時間約為41 μs。

2) 分段過程執(zhí)行時間分析。

(1) 事件響應(yīng)調(diào)度的過程說明。事件響應(yīng)調(diào)度的整個過程為:調(diào)用set()設(shè)置事件位,藍燈線程接收到事件位被設(shè)置的信號,解除阻塞開始運行。調(diào)用set()是藍燈線程響應(yīng)調(diào)度的開始,串口中斷調(diào)用set()設(shè)置事件位并掛起了PendSV中斷。set()調(diào)用結(jié)束后,繼續(xù)執(zhí)行中斷的后續(xù)代碼,串口中斷結(jié)束后立即觸發(fā)PendSV中斷,跳轉(zhuǎn)執(zhí)行PendSV中斷實際服務(wù)程序osRtxPendSV_Handler()開始調(diào)度處理。主要處理過程是調(diào)用事件處理函數(shù)osRtxEventFlagsPostProcess()和線程調(diào)度函數(shù)osRtxThreadDispatch()來改變線程狀態(tài)和隊列狀況,osRtxEventFlagsPostProcess()將已設(shè)置事件位的藍燈線程移出阻塞隊列和等待隊列并設(shè)置為就緒態(tài)放入就緒隊列,此時就緒隊列藍燈線程優(yōu)先級最高,于是又通過osRtxThreadDispatch()從就緒隊列取出藍燈線程設(shè)置為激活態(tài)。處理結(jié)束后,等待到事件位被設(shè)置的藍燈線程已經(jīng)解除阻塞準備運行,從osRtxPendSV_Handler()返回PendSV中斷,執(zhí)行后續(xù)的上下文處理程序SVC_Context進行上下文保護和線程切換,PendSV中斷結(jié)束后,藍燈線程被正式切換運行。至此,藍燈線程響應(yīng)調(diào)度結(jié)束。

(2) 時序分析。對于響應(yīng)調(diào)度的藍燈線程來說,最關(guān)鍵的三個要素為:系統(tǒng)何時發(fā)出了使其調(diào)度的信號(設(shè)置事件位);系統(tǒng)是怎樣調(diào)度的,需要花費多長時間來進行調(diào)度處理;處理結(jié)束到正式被切換運行又需要耗費多長時間。除此之外,調(diào)度過程中通常還有一些參數(shù)驗證、類型轉(zhuǎn)換和條件判斷等操作,但這些一般不作考慮,不是關(guān)心的重點。

因此,設(shè)置事件位的set(),調(diào)度處理時調(diào)用的osRtxThreadListRemove()、osRtxThreadWaitExit()和osRtxThreadDispatch(),切換上下文的SVC_Context,這幾個過程無疑是測試的重點。對此,根據(jù)調(diào)度過程中系統(tǒng)的主要操作,將整段過程的運行時間分成7個時間段。過程分段結(jié)果如圖2所示。

圖2 事件響應(yīng)調(diào)度過程分段

測試時依舊通過全局變量保存每段過程對應(yīng)位置的時間點,最后通過藍燈線程輸出時間值及時間差大小。例如求取T0-T1段即set()執(zhí)行的時間,可以定義全局變量T0、T1,在調(diào)用set()這句代碼的前后分別插入T0、T1的時間賦值語句,在藍燈線程中利用printf輸出T0、T1及兩者的差值。另外為了減小誤差,每次測試時只測時間段對應(yīng)的兩個時間點,即只使用兩個全局變量保存Ti-T(i+1)兩點所在時間值,不同時進行多個時間段的測試處理。

對事件響應(yīng)調(diào)度這段過程中不同時間段分別進行百次printf輸出實驗,排除異常數(shù)據(jù)后計算每段時間對應(yīng)的平均值,結(jié)果如表1所示。7個時間段加起來的時間為11+8+1+7+3+8+3=41 μs,與測出的總執(zhí)行時間一致,基本可以認為測出的時間數(shù)據(jù)是可信和正確的。T0-T1是觸發(fā)調(diào)度的開始,設(shè)置事件位,將PendSV掛起推遲執(zhí)行;T2-T3、T3-T4、T5-T6三段為調(diào)度時主要的處理過程,主要為隊列的變化和線程狀態(tài)的改變;T6-T7即為調(diào)度處理結(jié)束,返回SVC_Context切換藍燈線程正式運行的時間。

表1 事件響應(yīng)調(diào)度分段過程執(zhí)行時間

以T0為時間基點,藍燈線程響應(yīng)調(diào)度的整個時序過程如圖3所示,粗線條長度代表對應(yīng)過程執(zhí)行時間?？梢钥吹?在PendSV調(diào)度未開始時,調(diào)用set()已耗費了較多時間,約有11 μs,這是由于se()的執(zhí)行經(jīng)歷了好幾層的嵌套調(diào)用,其調(diào)用順序為set()→osEventFlagsSet()→isrRtxEventFlagsSet(),在isrRtxEventFlagsSet()中才會調(diào)用子函數(shù)EventFlagsSet()設(shè)置事件位和osRtxPostProcess()掛起PendSV中斷。PendSV開始后,進行一些調(diào)度相關(guān)的處理,主要調(diào)整了隊列和線程狀態(tài),并在最后進行上下文切換工作,這段過程共耗費了30 μs。其中,在T3-T4和T5-T6階段隊列的進出操作花費了較多時間,這里藍燈線程在T3-T4階段先進入了就緒隊列,由于優(yōu)先級最高在T5-T6階段又被調(diào)出了就緒隊列并激活運行,是否可以考慮直接通過優(yōu)先級的比較判斷其優(yōu)先級最大時直接激活運行,避免無意義的進出隊列操作,從而減少整個調(diào)度過程的執(zhí)行時間,這一點值得思考并有待進一步研究。

圖3 事件響應(yīng)PendSV調(diào)度時序圖

3.3 影響事件機制響應(yīng)時間的要素分析

事件機制的響應(yīng)時間主要受兩方面影響,客觀角度上可以通過編譯優(yōu)化來大幅度提高代碼執(zhí)行效率以減少響應(yīng)時間來增強實時性,主觀角度上根據(jù)程序功能的不同需求會在某些方面影響響應(yīng)速度。

3.3.1編譯優(yōu)化的影響

編譯優(yōu)化可以通過不同優(yōu)化等級對編譯器的影響,在編譯時對代碼進行不同程度的優(yōu)化。使用編譯優(yōu)化選項會影響編譯耗費的時間、程序占用的Flash和RAM大小、代碼的運行效率等,甚至有可能會導致代碼運行異常,故通常需要根據(jù)實際情況來設(shè)置。本文只分析不同優(yōu)化等級對代碼執(zhí)行效率的影響,分別測試不同優(yōu)化等級下事件機制的響應(yīng)時間,即調(diào)用set()設(shè)置事件到等待事件的線程結(jié)束等待被調(diào)度運行這段過程的總時間。在STM32CubeIDE中,提供了7種優(yōu)化等級(optimization level),從低到高分別為:-O0、-Og、-O1、-O2、-O3、-Os、-Ofast。-O0為默認不優(yōu)化,不優(yōu)化情況下已經(jīng)求出響應(yīng)時間約為41 μs,按照同等方式分別求出其他優(yōu)化等級下對應(yīng)響應(yīng)時間,同樣進行百次輸出實驗并取平均值,結(jié)果如表2所示。

表2 不同優(yōu)化等級下的事件機制響應(yīng)時間

不同等級的優(yōu)化選項效果不同:-O1主要對代碼的分支、常量、表達式等進行優(yōu)化;-Og可以看作是O0.5,是在O1的基礎(chǔ)上,去掉了影響調(diào)試的優(yōu)化;-O2會嘗試更多的寄存器級的優(yōu)化以及指令級的優(yōu)化;-Os啟用了所有-O2優(yōu)化選項但排除了增加目標文件大小的選項,主要用于縮減代碼尺寸;-O3在-O2的基礎(chǔ)上進行更多的優(yōu)化,例如使用偽寄存器網(wǎng)絡(luò)、普通函數(shù)的內(nèi)聯(lián)等;-Ofast是在-O3的基礎(chǔ)上,添加了一些非常規(guī)優(yōu)化,無視嚴格的標準合規(guī)性,一般不推薦使用。

可以看到隨著優(yōu)化等級越高,代碼的執(zhí)行效率越高,即事件機制的響應(yīng)時間越小。通過編譯優(yōu)化,響應(yīng)時間最高減少到15 μs,相比不優(yōu)化時的41 μs,響應(yīng)速度提高了一倍多,基于事件機制的mbedOS實時性得到了有效提高。但要注意的是,代碼的優(yōu)化通常是以程序的可調(diào)試性為代價的,優(yōu)化度越高,可調(diào)試性越低,故通常要根據(jù)需求來進行合理設(shè)置。

3.3.2程序功能的影響

前面已經(jīng)說明,中斷中調(diào)用set()結(jié)束后會執(zhí)行中斷后續(xù)未執(zhí)行的語句,PendSV被掛起直到中斷結(jié)束才會觸發(fā)。從set()到PendSV開始這段過程,執(zhí)行時間主要受set()之后的代碼數(shù)量影響,本文測試工程中set()為中斷處理函數(shù)中的最后一個操作,基本可以看作set()結(jié)束后中斷就已經(jīng)結(jié)束,PendSV立即被觸發(fā),但實際應(yīng)用時中斷里可能會根據(jù)需要進行一些其他操作比如添加printf輸出提示,因此這部分執(zhí)行時間受主觀需求影響是不確定的。

另一方面,由圖3可以看到,在執(zhí)行PendSV調(diào)度處理時,執(zhí)行時間主要耗費在進隊列或出隊列等操作上,T2-T3、T3-T4和T5-T6的時間和為16 μs,超過了PendSV總執(zhí)行時間30 μs的一半。本文測試工程只進行了藍燈線程與空閑線程間的調(diào)度示例,不同隊列中存在的線程數(shù)不會超過兩個,這是為了排除其他線程的干擾,這樣在最簡單的條件下才能測出最準確的響應(yīng)時間。但實際應(yīng)用時往往會有多個任務(wù)線程,隊列中線程的位置會根據(jù)不同場合發(fā)生變化,例如同時有多個線程等待事件,事件阻塞隊列會有多個線程,而出隊列的只會是已經(jīng)設(shè)置事件位的對應(yīng)線程,不同位置進出隊列所耗費的時間自然會有所變化,從而影響整體的響應(yīng)時間。特別要注意的是T5-T6階段就緒隊列的改變,線程調(diào)度函數(shù)osRtxThreadDispatch()是根據(jù)就緒隊列中線程優(yōu)先級的比較來激活確定下一運行線程的。只有就緒隊列最高優(yōu)先級線程的優(yōu)先級高于正在運行的線程優(yōu)先級,才會進行線程的切換,將優(yōu)先級更高的線程調(diào)度運行。因此,基于事件機制等待響應(yīng)調(diào)度的線程,優(yōu)先級通常要設(shè)置為比其他線程高一點,這樣才能在等待到事件位被設(shè)置后,立即接受調(diào)度運行;反之優(yōu)先級比其他線程低的話,在接收到事件位已設(shè)置的信號后,可能被其他等待運行的高優(yōu)先級線程搶占,響應(yīng)時間無法估測,不再有實時的特點。

4 結(jié) 語

本文對mbedOS中事件機制響應(yīng)調(diào)度的實時性進行了剖析。首先提出基于printf函數(shù)的時序測試方法,然后分析得到事件響應(yīng)調(diào)度的理論時間為35 μs,滿足提出的時序測試條件,在簡要說明了響應(yīng)調(diào)度過程的基礎(chǔ)上,對實際響應(yīng)時間進行了測試,研究表明線程等待中斷設(shè)置事件位來響應(yīng)PendSV調(diào)度所需的時間約為41 μs,其中隊列操作花費時間占據(jù)比例最大,最后進一步說明了影響事件機制響應(yīng)時間的主要因素有編譯優(yōu)化和程序功能兩方面,其中編譯優(yōu)化最高可將實際響應(yīng)時間減少到15 μs。通過printf對事件響應(yīng)調(diào)度實時性的深入剖析,不僅為mbedOS中事件機制的精確使用提供參考,也為剖析其他RTOS的實時性提供一定的借鑒。