μC／OS—II實時操作系統(tǒng)中任務延時的研究與改進

摘要：通過介紹μC／0S—II實時操作系統(tǒng)中的任務延時功能，分析了系統(tǒng)中的任務延時的優(yōu)缺點。針對任務延時占用處理器時間與任務總數(shù)有關和掃描各個任務占用大量處理器時間的問題，對操作系統(tǒng)中的任務延時機制進行改進。改進后的操作系統(tǒng)在基于第二代Cortex—M3內(nèi)核的LPC1768處理器上測試，通過軟件仿真，得出此方法可以提高系統(tǒng)的實時性，降低系統(tǒng)的額外開銷。
關鍵詞：μC／OS—II；任務延時；Cortex—M3；軟件仿真

引言
μC／OS—II是一種源代碼公開、結構小巧、具有可剝奪實時內(nèi)核的實時操作系統(tǒng)。絕大部分代碼是用C語言編寫的，便于移植到各種內(nèi)核上。μC／OS—II使用時鐘節(jié)拍完成任務的延時功能，每個時鐘對所有的任務控制塊進行掃描。時鐘節(jié)拍率越高，系統(tǒng)的額外負荷就越重，而且會隨著任務總數(shù)的增加而增加。
本文詳細分析μC／OS—II中的任務延時功能，對任務延時作適當改進。新創(chuàng)建一個任務延時鏈表，把需要延時的任務鏈接到延時列表中，這樣每個時鐘節(jié)拍只對延時任務的控制塊進行掃描即可，由此降低了系統(tǒng)負荷，而且系統(tǒng)的開銷不會隨著任務總數(shù)的增加而增加，而僅僅與同時延時的任務數(shù)有關。

1 μC／OS—II任務延時
μC／OS—II系統(tǒng)中任務延時是時間管理功能的主要部分，而在μC／OS—II 2．81及以后的版本中，增加了軟件定時器功能。不管是任務延時還是軟件定時器，都需要一個硬件產(chǎn)生一個周期中斷，也就是時鐘節(jié)拍。
μC／OS—II系統(tǒng)的時鐘節(jié)拍的頻率一般在10～100 Hz之間，時鐘節(jié)拍率越高，系統(tǒng)的額外負荷就越重，影響系統(tǒng)的實時性。任務延時是在時鐘節(jié)拍中斷函數(shù)中實現(xiàn)的，時鐘節(jié)拍中斷函數(shù)調(diào)用時鐘節(jié)拍函數(shù)OSTimeTick()，此函數(shù)的工作主要是掃描每一個任務控制塊中的時間延時項OSTCBDly，完成任務的延時。由于OSTimeTick()要對每個任務都進行一遍同樣的工作，因此它的運行時間和任務數(shù)的多少成正比。如果任務數(shù)比較多的話(現(xiàn)在μC／OS—II可以支持256個任務，而基于Cortex-M3內(nèi)核可以支持1024個任務)，函數(shù)OSTimeTick()占用大量的系統(tǒng)時間。
本文使用的操作系統(tǒng)版本為μC／OS—II 2．86，此版本中與任務延時相關的函數(shù)包括：
①與任務延時設置相關的函數(shù)——任務延時函數(shù)OSTimeDly()與OSTimeDlyHMSM()，位于time．c文件中，用于任務自身調(diào)用，無條件的掛起自己延時一段時間；請求資源函數(shù)OS_FlagBlock()(請求事件標志)、OSMboxPend()(請求郵箱)、OSMutexPend()(請求互斥量)、OSQPend()(請求消息隊列)、OSSemPend()(請求信號量)等，當資源請求不成功時，任務延時掛起；還有一個掛起其他任務的函數(shù)OSTaskResume()，但沒有掛起其他函數(shù)一段時間的函數(shù)。
②與任務恢復有關的函數(shù)——恢復任務延時函數(shù)OSTimeDlyResume()，恢復因資源不滿足而掛起任務的函數(shù)OS_EventTaskRdy()、OS_Fla-gTaskRdy()，把等待列表中的占用位清除，清任務延時值；任務刪除函數(shù)OSTaskDel()、任務恢復函數(shù)OSTaskResume()等。
③時鐘節(jié)拍處理函數(shù)OSTimeTick()，用于處理任務延時。

2 任務延時的改進
首先在uCOS_II．H頭文件中定義任務延時鏈表OSTCBDlyList，延時任務總數(shù)變量OSTCBDlyNum，由于記錄延時任務數(shù)。設置任務延時，首先把任務從任務鏈表中刪除，然后加入都任務延時鏈表OSTCBDlyList中，最后OSTCBDlyNum加1；延時結束或任務恢復時，任務控制塊從任務延時鏈表中刪除，加入任務鏈表；刪除任務時，首先判斷任務是否處于延時中，再決定從哪個鏈表中刪除。
2．1 修改與任務延時設置相關的函數(shù)
與任務延時設置相關函數(shù)中，在其代碼OSTCBCur->OSTCBDly=ticks(或timeout)后面加入延時設定函數(shù)函數(shù)OSTCBDlySet()，如OSTimeDly()函數(shù)修改成如下形式：

函數(shù)OSTCBDlySet()的形參為需要任務延時的控制塊，函數(shù)的偽代碼如下所示：

2．2 從任務延時鏈表中刪除任務控制塊
當任務延時完成、任務延時恢復、任務恢復、任務刪除時，需要把任務從任務延時鏈表中刪除。使用函數(shù)OSTCBDlyDel()，此函數(shù)無返回，形參有兩個：第一個為任務控制塊指針，第二個為操作類型opt，函數(shù)原型為void OSTCBDlyDel(OS_TCB*ptcb，INT8U opt)。opt的取值為：OS_Dly_OPT_NONE(正常執(zhí)行，從任務延時鏈表刪除，加入任務鏈表)，OS_Dly_OPT_DEL(把任務從任務延時鏈表刪除，OSTaskDel()函數(shù)使用)。函數(shù)OSTCBDlyDel的流程如圖1所示。

在函數(shù)OSTimeDlyResume()、OS_EventTaskRdy()、OS_FlagTaskRdy()以及OSTaskResume()中，在其代碼ptcb->OSTCBDly=0后面(下一行)加入0STCBDlyDel(ptcb，OS_Dly_OPT_NONE)。然后在時鐘節(jié)拍處理函數(shù)OSTime Tick()中作適當修改，修改后的偽代碼如下：

對于任務刪除函數(shù)OSTCBDlyDel()，首先判斷任務控制塊中的任務延時值是否為0，如果不等于0，調(diào)用函數(shù)OSTCBDlyDel(ptcb，OS_Dly_ OPT_DEL)，把任務從任務延時鏈表中刪除；如果等于0，把任務從任務鏈表中刪除。最后，把任務控制塊回收到空閑任務鏈表中。

3 實驗測試
3．1 測試環(huán)境
本次實驗使用軟件開發(fā)環(huán)境Keil4，把μC／OS—II操作系統(tǒng)移植到基于Cortex—M3內(nèi)核的LPC1768處理器上。對實時操作系統(tǒng)μC／OS—II 2．86進行改進，并對改進后的操作系統(tǒng)進行軟件仿真測試。
ARM Cortex—M3內(nèi)核采用3級流水線和哈佛結構，帶獨立的本地指令和數(shù)據(jù)總線以及用于外設的稍微低性能的第三條總線，還包含一個支持隨機跳轉的內(nèi)部預取指單元。LPC1700系列微控制器主要用于處理要求高度集成和低功耗的嵌入式應用，最高工作頻率可達100 MHz。內(nèi)部有高達512 KB的Flash存儲器、64KB的數(shù)據(jù)存儲器，片內(nèi)外設包括以太網(wǎng)MAC、USB主機／從機／OTG接口、8通道的通用DMA控制器、4個UART、2條CAN通道、2個SSP控制器、SPI接口、3個I2C接口、2輸入和2輸出的I2S接口、8通道的12位ADC、10位DAC、電機控制PWM、正交編碼器接口、4個通用定時器、6輸出的通用PWM、帶獨立電池供電的超低功耗RTC等眾多功能，方便系統(tǒng)的開發(fā)，節(jié)約成本。
本次測試為：在μC／OS—II中創(chuàng)建25個用戶任務，其中的10個任務延時一段時間(for循環(huán)延時)，并發(fā)送信號量，已激活等待此信號量的任務，而后調(diào)用函數(shù)OSTimeDly()，任務延時。而另外15個任務無限期等待另外幾個任務的信號量。Keil4的軟件仿真中，LPC1768的外部時鐘設定為22．1184 MHz。
3．2 實驗結果
下面通過Keil4軟件仿真中的Performance Analyzer功能，觀察μC／OS—II原操作系統(tǒng)與改進后的操作中函數(shù)OSTime Tick()的運行時間。性能測評圖如圖2、圖3所示。

可以看出，改進后OSTimeTick()函數(shù)的系統(tǒng)占用率只有原先的50％，當然在實際使用環(huán)境中，改進后OSTimeTick()函數(shù)的系統(tǒng)占用率與系統(tǒng)中延時任務的多少、系統(tǒng)的運行速度等因素有關，不可能降低這么多，至少從理論上與仿真測試中可以驗證此方法可以降低系統(tǒng)的額外開銷，提高系統(tǒng)的實時性。

結語
隨著技術的進步，處理器芯片的內(nèi)存不斷增大，運行速度不斷提高，而且應用系統(tǒng)設計越來越復雜，系統(tǒng)需要運行越來越多的任務，時鐘節(jié)拍處理函數(shù)將占用大量的處理器時間，影響系統(tǒng)的實時性。通過本文對原操作系統(tǒng)中任務延時機制的改進與優(yōu)化，使時鐘節(jié)拍處理函數(shù)的運行時間僅與同時延時的任務數(shù)有關。通過Keil4開發(fā)環(huán)境下的軟件仿真可以看出，改進后系統(tǒng)開銷大大降低。