基于μC／0S―II的時問片調度法設計
加入技術交流群
#define OS_STAT_TS_USEUP 0x40
2．2 相關函數的修改
對0S_TCBInit()、OSTimeTick()、OSTimeD1y()、OS_EventTaskWait()、OS_EventTaskRdy()這5個函數的修改，是在μC／OS―II基礎上實現時間片調度法的關鍵。下面將一一對這幾個函數的修改部分進行說明。
在初始化任務控制塊的函數0S_TCBInit()中，筆者添加以下代碼讓新創建的任務處于時間片就緒表中，并根據任務優先級對任務的時間片大小進行初始化。本文引用地址：http://www.104case.com/article/188642.htm
0STimeTick()函數在每個時鐘滴答被調用，在時間片調度過程中起到了遞減時間片計數器的作用。當計數器為0時，進行任務切換或是重新給各個任務分配時間片并開始新一輪調度。
OSTimeDly()函數的作用是將任務延時一定的時間。這種情況下，應該把該任務從時間片調度表中清除。
當某個任務須等待一個事件的發生時，信號量、互斥型信號量、郵箱及消息隊列會通過相應的PEND函數調用函數OS_EventTaskwait()，使當前任務從就緒任務表中脫離就緒態，此時還需把當前任務從時問片調度表中清除。筆者在OS_EventTaskWait()函數中添加了以下代碼：
相應地，當某個事件發生了，信號量、互斥型信號量、郵箱及消息隊列會通過相應的POST函數調用OS_Even―tTaskRdy()，從等待任務隊列中使最高優先級任務脫離等待狀態，此時還需要把該任務添加到時間片調度表中。筆者在0S_EventTaskRdy()函數中添加了以下代碼：
OSTSSGrp |=bity；
OSTSSTbl[y]|=bitx；
3 應用實例
筆者首先把μC／0S―II移植到開發板上(MCU是意法半導體生產的基于ARM7TDMI核的STR730)，然后如2小節所述對相關部分的源代碼進行修改，接下來將優先級調度法和基于μC／0S―II的時間片調度法進行比較。為此分別建立了2個任務Task_TimeConsuming()、Task_Audio()，任務的優先級分別是5、6。
由于模擬的耗時任務Task_TimeConsuming()是個死循環且沒有調用OSTimeDly()函數，其優先級又比Task_Audio()高，如果完全按照優先級調度，系統不會有聲音輸出，因為負責聲音控制的任務Task_Audio一直得不到運行。而如果按照時間片調度(在os_cfg．h中增加#defineOS_TASK_TIME_SLICE_EN 1)，則聲音輸出正常，通過仿真器在Task_Audio()中設置斷點，程序會很快停止在斷點處。進一步地，依次在Task_TimeConsuming()和Task_Audio()函數體中設置斷點，分別記錄兩次PC指針停止在斷點處時看門狗計數器的值WDG_Counterl和WDG_Counter2，可以利用WDG_Counter1和WDG_Counter2的差值估算出任務Task_Audio前后兩次被調度的時間間隔(忽略任務在切換過程中的耗時)。經過多次計算，這個時間間隔值的范圍在58～59 ms，而任務Task_TimeConsuming的時間片理論值=64一Prio=64―5=59 ms，實驗值與理論值是非常吻合的。
當然，這只是簡單的驗證實驗。嚴格的測試還需要兼顧信號量、互斥型信號量、郵箱及消息隊列相應的PEND、POST函數以及0STimeDly()函數調用。鑒于篇幅關系，這里就不再贅述了。
結 語
筆者已經成功地把這種基于μC／0S―II的時間片調度法運用到車載信息娛樂系統的開發中。實踐證明，對于含有耗時任務的系統，尤其是在需要嚴格控制耗時任務運行時間長度的場合，該調度算法會有一定的便捷性，也能保證系統的實時響應，而且整個算法只改動了μC／OS―II中的少量代碼；還可以根據實際需要調整各個任務的時間片大小，體現出了算法的實用性與靈活性。
評論