基于μC/OS-II的時間片調度法設計方法

基于μC/OS-II的時間片調度法設計方法

多任務的調度算法多種多樣，各種調度算法也各有千秋。在某些應用場合，時間片調度法就比純粹的優(yōu)先級調度法更具優(yōu)勢。本文提出了基于μC/OS-II的時間片調度法的設計原理，給出實現該調度法的關鍵部分源代碼，并且通過一個簡單的應用實例將該時間片調度法與優(yōu)先級調度法進行比較。

關鍵詞? 多任務? 時間片調度法? 優(yōu)先級調度法? μC/OS-II

引言

　　μC/OS-II嵌入式實時操作系統(tǒng)采用的是基于優(yōu)先級的可剝奪調度法[1]?；趦?yōu)先級的可剝奪調度法是指，CPU總是讓處于就緒態(tài)的、優(yōu)先級最高的任務運行；最高優(yōu)先級的任務一旦就緒，總能得到CPU的使用權，當一個運行著的任務使一個比它優(yōu)先級高的任務進入了就緒態(tài)時，當前任務的CPU使用權就被剝奪了，更高優(yōu)先級的任務立刻得到了CPU的使用權。除非最高優(yōu)先級的任務主動放棄CPU的使用權（通過調用OSTimeDly()、OSSemPend()等函數），否則低優(yōu)先級的任務是沒機會獲得CPU使用權的。對于一個實際應用系統(tǒng)中耗時比較長的任務，為了讓其他任務能夠得到實時調度，可以用兩種方法來處理。第一種方法是把該任務的優(yōu)先級設為最低（當然還是比空閑任務要高）；第二種方法就是讓該耗時任務運行一段時間后延時一下再繼續(xù)運行，即把整個任務劃分為若干步驟來執(zhí)行，如以下的示例代碼：

void Task_Timeconsuming(void *pdata) {
　　……
　　while(1) {
　　　　ExecuteStep1();
　　　　OSTimeDly(n);/*延時若干時間以讓其他低優(yōu)先級任務獲得CPU的使用權*/
　　　　ExecuteStep2();
　　　　OSTimeDly(n);
　　　　……
　　}
}

　　很多情況下，耗時長的任務并不能設置為最低優(yōu)先級任務，而劃分步驟來執(zhí)行的方法不但繁瑣而且每一步執(zhí)行的時間也是不確定的（其他低優(yōu)先級任務獲得CPU使用權的時間也會是不確定的）。筆者在用μC/OSII開發(fā)一款車載信息娛樂系統(tǒng)的時候就碰到了這樣的問題，因此設計了一種優(yōu)先級和時間片相結合的調度法（也就是基于μC/OSII的時間片調度法）。

1? 調度原理

　　這種調度法給處于就緒態(tài)的每一個任務都分配一個時間片（優(yōu)先級越高分配的時間片越長，空閑任務得不到時間片的分配），內核按照任務的優(yōu)先級依次調度處于就緒態(tài)的任務，即當就緒態(tài)中最高優(yōu)先級的任務用完自己的時間片后，CPU控制權轉讓給就緒態(tài)中優(yōu)先級第二高的任務。該任務用完自己的時間片后，CPU控制權又轉讓給下一優(yōu)先級的就緒態(tài)任務……當就緒態(tài)的每一個任務都被調度一次之后將重新為它們分配時間片，然后又開始新一輪的調度……[2]

　　其中要注意的是，在調度過程中如果有一個比當前任務優(yōu)先級更高的任務由其他態(tài)變成了就緒態(tài)（被創(chuàng)建或獲取了一個信號量等），當前任務的CPU控制權將被剝奪；空閑任務仍然是等到其他任務都退出就緒態(tài)才獲得CPU的使用權。

　　圖1解釋了該調度法的調度過程（其中任務1優(yōu)先級最高，任務2次之，任務3最低）。

圖1? 基于μC/OSII時間片調度過程

　?、?任務2和任務3都處于就緒態(tài)，任務1在等待一個信號量，優(yōu)先級中的任務2獲得CPU使用權。
　　② 任務2的時間片用完，優(yōu)先級低的任務3獲得CPU使用權。
　　③ 任務3的時間片用完，任務2重新獲得CPU的使用權。
　?、?任務2的時間片還沒用完時中斷來臨，中斷服務程序獲得CPU使用權。
　?、?中斷服務程序發(fā)送了一個任務1等待的信號量，中斷服務完成后優(yōu)先級高的任務1獲得CPU使用權。
　?、?任務1的時間片用完，任務2繼續(xù)運行。
　?、?任務2的時間片用完，任務3獲得CPU使用權。
　　⑧ 任務3的時間片用完，重新分配時間片，新一輪調度開始。

2? 實現方法

　　在調度算法的實現過程中，力求做到3點：

　　① 盡可能少地改動μC/OSII原有的代碼；
　?、?增加的代碼在風格上保持與原有的相一致；
　?、?兼容原有的優(yōu)先級調度法（可以很方便地選擇優(yōu)先級調度法或是時間片調度法）。

　　注：對于該小節(jié)中出現的代碼，如果是筆者增加的部分都用黑體表示。

2.1? 數據結構中增加的變量

　　在進程控制塊中增加兩項：

　　Typedef struct os_tcb{
　　　　……
　　#if OS_TASK_TIME_SLICE_EN>0
　　　　/*條件編譯，OS_TASK_TIME_SLICE_EN在os_cfg.h中定義，凡是涉及與時間片調度相關的代碼都用條件編譯。這樣，可以通過更改配置文件很方便地選擇任務調度法
　　*/INT16UOSTCBTimeSlice;
　　　　/*任務的時間片大小，在任務創(chuàng)建時被初始化，運行過程中保持不變*/
　　INT16UOSTCBCounter;
　　　　/*任務運行剩余時間計數器，每一輪調度開始時該變量被賦值（等于OSTCBTimeSlice），運行過程中不斷遞減。當其等于0時任務被剝奪CPU使用權*/
　　#endif
}

　　由于當前任務的時間片使用完時，該任務將被從就緒表OSRdyGrp以及OSRdyTbl[OS_RDY_TBL_SIZE]中清除；新一輪調度開始時它又必須被恢復，因此筆者在uCOS_II.h文件中增加以下變量（不妨把它們稱為“時間片調度表”）分別用于保存OSRdyGrp和OSRdyTbl[OS_RDY_TBL_SIZE]。

　　OS_EXT INT8UOSTSSGrp;
　　OS_EXT? INT8UOSTSSTbl[OS_RDY_TBL_SIZE];

　　另外，在uCOS_II.h文件中增加宏定義，用于表示任務時間片被用完這種狀態(tài)：

　　#defineOS_STAT_TS_USEUP0x40

2.2? 相關函數的修改

　　對OS_TCBInit()、OSTimeTick()、OSTimeDly()、OS_EventTaskWait()、OS_EventTaskRdy()這5個函數的修改，是在μC/OSII基礎上實現時間片調度法的關鍵。下面將一一對這幾個函數的修改部分進行說明。

　　在初始化任務控制塊的函數OS_TCBInit()中，筆者添加以下代碼讓新創(chuàng)建的任務處于時間片就緒表中，并根據任務優(yōu)先級對任務的時間片大小進行初始化。

if(prio < OS_STAT_PRIO) {
　　/*統(tǒng)計任務和空閑任務不加入時間片調度表*/
　　　　OSTSSGrp |= ptcb>OSTCBBitY;
　　　　OSTSSTbl[ptcb>OSTCBY] |= ptcb>OSTCBBitX;
　　　　ptcb>OSTCBTimeSlice = 64prio;
　　/*這里可以根據實際需要來計算時間片的大小*/
　　　　ptcb>OSTCBCounter = 64prio;
}
else {
　　　　ptcb>OSTCBTimeSlice = 0;
　　　　ptcb>OSTCBCounter = 0;
}

　　OSTimeTick()函數在每個時鐘滴答被調用，在時間片調度過程中起到了遞減時間片計數器的作用。當計數器為0時，進行任務切換或是重新給各個任務分配時間片并開始新一輪調度。

　　OSTimeDly()函數的作用是將任務延時一定的時間。這種情況下，應該把該任務從時間片調度表中清除。

　　當某個任務須等待一個事件的發(fā)生時，信號量、互斥型信號量、郵箱及消息隊列會通過相應的PEND函數調用函數OS_EventTaskWait()，使當前任務從就緒任務表中脫離就緒態(tài)，此時還需把當前任務從時間片調度表中清除。筆者在OS_EventTaskWait()函數中添加了以下代碼：

　　if((OSTSSTbl[OSTCBCur>OSTCBY] &= (~OSTCBCur>OSTCBBitX)) == 0x00) {
　　　　OSTSSGrp &= (~OSTCBCur>OSTCBBitY);
　　}
　　OSTCBCur>OSTCBCounter = OSTCBCur>OSTCBTimeSlice;/*重新給該任務分配時間片*/

　　相應地，當某個事件發(fā)生了，信號量、互斥型信號量、郵箱及消息隊列會通過相應的POST函數調用OS_EventTaskRdy()，從等待任務隊列中使最高優(yōu)先級任務脫離等待狀態(tài)，此時還需要把該任務添加到時間片調度表中。筆者在OS_EventTaskRdy()函數中添加了以下代碼：

　　OSTSSGrp |= bity;
　　OSTSSTbl[y] |= bitx;

3? 應用實例

　　筆者首先把μC/OSII移植到開發(fā)板上（MCU是意法半導體生產的基于ARM7TDMI核的STR730[3]），然后如2小節(jié)所述對相關部分的源代碼進行修改，接下來將優(yōu)先級調度法和基于μC/OSII的時間片調度法進行比較。為此分別建立了2個任務Task_TimeConsuming()、Task_Audio()，任務的優(yōu)先級分別是5、6。

　　voidTask_TimeConsuming(void *pdata) {
　　　　……
　　　　while(1) {
　　　　　　_ _asm {nop};
　　　　}
　　}

　　voidTask_Audio(void *pdata) {
　　　　……
　　　　while(1) {
　　　　　　AudioProcess();
　　　　}
　　}

　　由于模擬的耗時任務Task_TimeConsuming()是個死循環(huán)且沒有調用OSTimeDly()函數，其優(yōu)先級又比Task_Audio()高，如果完全按照優(yōu)先級調度，系統(tǒng)不會有聲音輸出，因為負責聲音控制的任務Task_Audio一直得不到運行。而如果按照時間片調度（在os_cfg.h中增加#define OS_TASK_TIME_SLICE_EN 1），則聲音輸出正常，通過仿真器在Task_Audio()中設置斷點，程序會很快停止在斷點處。進一步地，依次在Task_TimeConsuming()和Task_Audio()函數體中設置斷點，分別記錄兩次PC指針停止在斷點處時看門狗計數器的值WDG_Counter1和WDG_Counter2，可以利用WDG_Counter1和WDG_Counter2的差值估算出任務Task_Audio前后兩次被調度的時間間隔（忽略任務在切換過程中的耗時）。經過多次計算，這個時間間隔值的范圍在58～59 ms，而任務Task_TimeConsuming的時間片理論值＝64－Prio=64－5=59 ms，實驗值與理論值是非常吻合的。

　　當然，這只是簡單的驗證實驗。嚴格的測試還需要兼顧信號量、互斥型信號量、郵箱及消息隊列相應的PEND、POST函數以及OSTimeDly()函數調用。鑒于篇幅關系，這里就不再贅述了。

結語

　　筆者已經成功地把這種基于μC/OSII的時間片調度法運用到車載信息娛樂系統(tǒng)的開發(fā)中。實踐證明，對于含有耗時任務的系統(tǒng)，尤其是在需要嚴格控制耗時任務運行時間長度的場合，該調度算法會有一定的便捷性，也能保證系統(tǒng)的實時響應，而且整個算法只改動了μC/OSII中的少量代碼；還可以根據實際需要調整各個任務的時間片大小，體現出了算法的實用性與靈活性。