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

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

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

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

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

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

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

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

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

3 實驗測試
3．1 測試環境
本次實驗使用軟件開發環境Keil4，把μC／OS—II操作系統移植到基于Cortex—M3內核的LPC1768處理器上。對實時操作系統μC／OS—II 2．86進行改進，并對改進后的操作系統進行軟件仿真測試。
ARM Cortex—M3內核采用3級流水線和哈佛結構，帶獨立的本地指令和數據總線以及用于外設的稍微低性能的第三條總線，還包含一個支持隨機跳轉的內部預取指單元。LPC1700系列微控制器主要用于處理要求高度集成和低功耗的嵌入式應用，最高工作頻率可達100 MHz。內部有高達512 KB的Flash存儲器、64KB的數據存儲器，片內外設包括以太網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等眾多功能，方便系統的開發，節約成本。
本次測試為：在μC／OS—II中創建25個用戶任務，其中的10個任務延時一段時間(for循環延時)，并發送信號量，已激活等待此信號量的任務，而后調用函數OSTimeDly()，任務延時。而另外15個任務無限期等待另外幾個任務的信號量。Keil4的軟件仿真中，LPC1768的外部時鐘設定為22．1184 MHz。
3．2 實驗結果
下面通過Keil4軟件仿真中的Performance Analyzer功能，觀察μC／OS—II原操作系統與改進后的操作中函數OSTime Tick()的運行時間。性能測評圖如圖2、圖3所示。

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

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