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

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

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

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

    函數(shù)OSTCBDlySet()的形參為需要任務(wù)延時的控制塊，函數(shù)的偽代碼如下所示：
[!--empirenews.page--]

2．2 從任務(wù)延時鏈表中刪除任務(wù)控制塊
    當任務(wù)延時完成、任務(wù)延時恢復、任務(wù)恢復、任務(wù)刪除時，需要把任務(wù)從任務(wù)延時鏈表中刪除。使用函數(shù)OSTCBDlyDel()，此函數(shù)無返回，形參有兩個：第一個為任務(wù)控制塊指針，第二個為操作類型opt，函數(shù)原型為void OSTCBDlyDel(OS_TCB*ptcb，INT8U opt)。opt的取值為：OS_Dly_OPT_NONE(正常執(zhí)行，從任務(wù)延時鏈表刪除，加入任務(wù)鏈表)，OS_Dly_OPT_DEL(把任務(wù)從任務(wù)延時鏈表刪除，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()中作適當修改，修改后的偽代碼如下：
[!--empirenews.page--]

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

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級流水線和哈佛結(jié)構(gòu)，帶獨立的本地指令和數(shù)據(jù)總線以及用于外設(shè)的稍微低性能的第三條總線，還包含一個支持隨機跳轉(zhuǎn)的內(nèi)部預取指單元。LPC1700系列微控制器主要用于處理要求高度集成和低功耗的嵌入式應(yīng)用，最高工作頻率可達100 MHz。內(nèi)部有高達512 KB的Flash存儲器、64KB的數(shù)據(jù)存儲器，片內(nèi)外設(shè)包括以太網(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個用戶任務(wù)，其中的10個任務(wù)延時一段時間(for循環(huán)延時)，并發(fā)送信號量，已激活等待此信號量的任務(wù)，而后調(diào)用函數(shù)OSTimeDly()，任務(wù)延時。而另外15個任務(wù)無限期等待另外幾個任務(wù)的信號量。Keil4的軟件仿真中，LPC1768的外部時鐘設(shè)定為22．1184 MHz。
3．2 實驗結(jié)果
    下面通過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)中延時任務(wù)的多少、系統(tǒng)的運行速度等因素有關(guān)，不可能降低這么多，至少從理論上與仿真測試中可以驗證此方法可以降低系統(tǒng)的額外開銷，提高系統(tǒng)的實時性。

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