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

1 調(diào)度原理
    這種調(diào)度法給處于就緒態(tài)的每一個任務(wù)都分配一個時間片(優(yōu)先級越高分配的時間片越長，空閑任務(wù)得不到時間片的分配)，內(nèi)核按照任務(wù)的優(yōu)先級依次調(diào)度處于就緒態(tài)的任務(wù)，即當(dāng)就緒態(tài)中最高優(yōu)先級的任務(wù)用完自己的時間片后，CPU控制權(quán)轉(zhuǎn)讓給就緒態(tài)中優(yōu)先級第二高的任務(wù)。該任務(wù)用完自己的時間片后，CPU控制權(quán)又轉(zhuǎn)讓給下一優(yōu)先級的就緒態(tài)任務(wù)……當(dāng)就緒態(tài)的每一個任務(wù)都被調(diào)度一次之后將重新為它們分配時間片，然后又開始新一輪的調(diào)度……
    其中要注意的是，在調(diào)度過程中如果有一個比當(dāng)前任務(wù)優(yōu)先級更高的任務(wù)由其他態(tài)變成了就緒態(tài)(被創(chuàng)建或獲取了一個信號量等)，當(dāng)前任務(wù)的CPU控制權(quán)將被剝奪；空閑任務(wù)仍然是等到其他任務(wù)都退出就緒態(tài)才獲得CPU的使用權(quán)。
    圖1解釋了該調(diào)度法的調(diào)度過程(其中任務(wù)1優(yōu)先級最高，任務(wù)2次之，任務(wù)3最低)。

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

2 實現(xiàn)方法
    在調(diào)度算法的實現(xiàn)過程中，力求做到3點：
    ①盡可能少地改動μC／0S—II原有的代碼；
    ②增加的代碼在風(fēng)格上保持與原有的相一致；
    ③兼容原有的優(yōu)先級調(diào)度法(可以很方便地選擇優(yōu)先級調(diào)度法或是時間片調(diào)度法)。
    注：對于該小節(jié)中出現(xiàn)的代碼，如果是筆者增加的部分都用黑體表示。
2．1 數(shù)據(jù)結(jié)構(gòu)中增加的變量
    在進(jìn)程控制塊中增加兩項：

Typedef struct os_tcb{

    ……

    #if OS_TASK_TIME_SLICE-EN>0

    /*條件編譯，OS_TASK_TIME_SLICE_EN在os_cfg.h中定義，凡是涉及與時間片調(diào)度相關(guān)的代碼都用條件編譯。這樣，可以通過更改配置文件很方便地選擇任務(wù)調(diào)度法*/

INT16U OSTCBTimeSlice；

    /*任務(wù)的時間片大小，在任務(wù)創(chuàng)建時被初始化，運行過程中保持不變*/

INT16U OSTCBCounter；

    /*任務(wù)運行剩余時間計數(shù)器，每一輪調(diào)度開始時該變量被賦值(等于OSTCBTimeSlice)，運行過程中不斷遞減。當(dāng)其等于0時任務(wù)被剝奪CPU使用權(quán)*/

    #endif

}
    由于當(dāng)前任務(wù)的時間片使用完時，該任務(wù)將被從就緒表OSRdyGrp以及OSRdyTbl[OS_RDY_TBL_SIZE]中清除；新一輪調(diào)度開始時它又必須被恢復(fù)，因此筆者在uC0S_II．h文件中增加以下變量(不妨把它們稱為“時間片調(diào)度表”)分別用于保存OSRdyGrp和OSRdyTbl[OS_RDY_TBL_SIZE]。
    OS_EXT INT8U OSTSSGrp；
    OS_EXT INT8U OSTSSTbl[OS_RDY_TBL_SIZE]；
    [!--empirenews.page--]另外，在uCOS_II．h文件中增加宏定義，用于表示任務(wù)時間片被用完這種狀態(tài)：
    #define OS_STAT_TS_USEUP 0x40
2．2 相關(guān)函數(shù)的修改
    對0S_TCBInit()、OSTimeTick()、OSTimeD1y()、OS_EventTaskWait()、OS_EventTaskRdy()這5個函數(shù)的修改，是在μC／OS—II基礎(chǔ)上實現(xiàn)時間片調(diào)度法的關(guān)鍵。下面將一一對這幾個函數(shù)的修改部分進(jìn)行說明。
    在初始化任務(wù)控制塊的函數(shù)0S_TCBInit()中，筆者添加以下代碼讓新創(chuàng)建的任務(wù)處于時間片就緒表中，并根據(jù)任務(wù)優(yōu)先級對任務(wù)的時間片大小進(jìn)行初始化。

    0STimeTick()函數(shù)在每個時鐘滴答被調(diào)用，在時間片調(diào)度過程中起到了遞減時間片計數(shù)器的作用。當(dāng)計數(shù)器為0時，進(jìn)行任務(wù)切換或是重新給各個任務(wù)分配時間片并開始新一輪調(diào)度。
    OSTimeDly()函數(shù)的作用是將任務(wù)延時一定的時間。這種情況下，應(yīng)該把該任務(wù)從時間片調(diào)度表中清除。
    當(dāng)某個任務(wù)須等待一個事件的發(fā)生時，信號量、互斥型信號量、郵箱及消息隊列會通過相應(yīng)的PEND函數(shù)調(diào)用函數(shù)OS_EventTaskwait()，使當(dāng)前任務(wù)從就緒任務(wù)表中脫離就緒態(tài)，此時還需把當(dāng)前任務(wù)從時問片調(diào)度表中清除。筆者在OS_EventTaskWait()函數(shù)中添加了以下代碼：

   
    相應(yīng)地，當(dāng)某個事件發(fā)生了，信號量、互斥型信號量、郵箱及消息隊列會通過相應(yīng)的POST函數(shù)調(diào)用OS_Even—tTaskRdy()，從等待任務(wù)隊列中使最高優(yōu)先級任務(wù)脫離等待狀態(tài)，此時還需要把該任務(wù)添加到時間片調(diào)度表中。筆者在0S_EventTaskRdy()函數(shù)中添加了以下代碼：
    OSTSSGrp |=bity；
    OSTSSTbl[y]|=bitx；

3 應(yīng)用實例
    筆者首先把μC／0S—II移植到開發(fā)板上(MCU是意法半導(dǎo)體生產(chǎn)的基于ARM7TDMI核的STR730)，然后如2小節(jié)所述對相關(guān)部分的源代碼進(jìn)行修改，接下來將優(yōu)先級調(diào)度法和基于μC／0S—II的時間片調(diào)度法進(jìn)行比較。為此分別建立了2個任務(wù)Task_TimeConsuming()、Task_Audio()，任務(wù)的優(yōu)先級分別是5、6。

    由于模擬的耗時任務(wù)Task_TimeConsuming()是個死循環(huán)且沒有調(diào)用OSTimeDly()函數(shù)，其優(yōu)先級又比Task_Audio()高，如果完全按照優(yōu)先級調(diào)度，系統(tǒng)不會有聲音輸出，因為負(fù)責(zé)聲音控制的任務(wù)Task_Audio一直得不到運行。而如果按照時間片調(diào)度(在os_cfg．h中增加#defineOS_TASK_TIME_SLICE_EN 1)，則聲音輸出正常，通過仿真器在Task_Audio()中設(shè)置斷點，程序會很快停止在斷點處。進(jìn)一步地，依次在Task_TimeConsuming()和Task_Audio()函數(shù)體中設(shè)置斷點，分別記錄兩次PC指針停止在斷點處時看門狗計數(shù)器的值WDG_Counterl和WDG_Counter2，可以利用WDG_Counter1和WDG_Counter2的差值估算出任務(wù)Task_Audio前后兩次被調(diào)度的時間間隔(忽略任務(wù)在切換過程中的耗時)。經(jīng)過多次計算，這個時間間隔值的范圍在58～59 ms，而任務(wù)Task_TimeConsuming的時間片理論值=64一Prio=64—5=59 ms，實驗值與理論值是非常吻合的。
    當(dāng)然，這只是簡單的驗證實驗。嚴(yán)格的測試還需要兼顧信號量、互斥型信號量、郵箱及消息隊列相應(yīng)的PEND、POST函數(shù)以及0STimeDly()函數(shù)調(diào)用。鑒于篇幅關(guān)系，這里就不再贅述了。

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