μC/OS-II 是一個(gè)源代碼公開(kāi)、可移植、可裁剪的實(shí)時(shí)多任務(wù)操作系統(tǒng)，具有穩(wěn)定可靠、實(shí)時(shí)性好等優(yōu)點(diǎn)，是專門(mén)針對(duì)微處理器和微控制器設(shè)計(jì)的實(shí)時(shí)內(nèi)核，它的內(nèi)核可以做到很小，很適合在單片機(jī)系統(tǒng)上移植。移植了μC/OS-II 的嵌入式系統(tǒng)可以使各個(gè)任務(wù)獨(dú)立工作，互不干涉，很容易實(shí)現(xiàn)準(zhǔn)時(shí)而且無(wú)誤執(zhí)行，使實(shí)時(shí)應(yīng)用程序的設(shè)計(jì)和擴(kuò)展變得容易，使應(yīng)用程序的設(shè)計(jì)過(guò)程大為減化。在這個(gè)星期內(nèi)，我通過(guò)對(duì)禁用了郵箱、隊(duì)列、文件系統(tǒng)的最簡(jiǎn)單的μCOS-ii操作系統(tǒng)進(jìn)行了學(xué)習(xí)，現(xiàn)將收獲分享如下。

μCOS-ii運(yùn)行過(guò)程

μCOS-ii的主函數(shù)不到十行代碼，但是因?yàn)槠涓叨鹊慕Y(jié)構(gòu)化以及良好的函數(shù)封裝，對(duì)其運(yùn)行過(guò)程的了解對(duì)于學(xué)習(xí)μCOS-ii的編程思想以及設(shè)計(jì)思路具有重大的意義。

我通過(guò)將μCOS-ii代碼移植到SST89V564RD單片機(jī)中，并且利用TI公司的溫度傳感器TMP124創(chuàng)建了兩個(gè)任務(wù)：讀TMP122數(shù)據(jù)、向串口發(fā)送讀取的溫度值。要求兩個(gè)任務(wù)輪流執(zhí)行，讀TMP122的優(yōu)先級(jí)高于向串口發(fā)送數(shù)據(jù)的優(yōu)先級(jí)。

1 系統(tǒng)初始化

在μCOS-ii中，系統(tǒng)初始化可以分為全局變量初始化、創(chuàng)建空閑任務(wù)任務(wù)、堆棧初始化、任務(wù)控制塊初始化等部分內(nèi)容。

全局變量初始化。由于μCOS-ii操作系統(tǒng)中定義了眾多與系統(tǒng)參數(shù)有關(guān)的全局變量，因此全局變量的初始化包含眾多內(nèi)容。這些系統(tǒng)參數(shù)的初始化大都被封裝 在OSInit()函數(shù)中。尤其要注意的是，在OSInit函數(shù)中，OSRunning變量一定要被定義成FALSE，否則在OSStart函數(shù)中，系統(tǒng) 無(wú)法啟動(dòng)創(chuàng)建的任務(wù)，系統(tǒng)因此變成了一個(gè)有始有終的函數(shù)，創(chuàng)建的任務(wù)永遠(yuǎn)得不到執(zhí)行。在實(shí)際運(yùn)行過(guò)程中表現(xiàn)為主函數(shù)運(yùn)行一次之后，系統(tǒng)不再運(yùn)行。另外需要 注意的是OSTCBCur、OSTCBList等這幾個(gè)變量需要定義為(OS_TCB DT_XDATA *)0的類型。因?yàn)檫@些變量是指向結(jié)構(gòu)體TCB(Task Control Block)的指針，并不是數(shù)字〇。

創(chuàng)建空閑任務(wù)。創(chuàng)建空閑任務(wù)包括進(jìn)入臨界區(qū)、任務(wù)堆棧初始化、TCB初始化、退出臨界區(qū)等內(nèi)容，大部分是一些簡(jiǎn)單的賦值操作，比較簡(jiǎn)單，不再贅述。其中OSRdyGrp |= ptcb->OSTCBBitY; OSRdyTbl[ptcb->OSTCBY] |= ptcb->OSTCBBitX;這兩句話要盡量看懂。因?yàn)檫@兩句話牽扯到后面OSUnMapTbl這個(gè)矩陣的理解。其含義為一旦任務(wù)就緒隊(duì)列中有"1"(即對(duì)應(yīng)的任務(wù)就緒)，則相應(yīng)的任務(wù)組OSRdyGrp 相應(yīng)的位變成1，OSRdyTbl中的相應(yīng)的位也變成1.

堆棧初始化以及任務(wù)控制塊初始化。比較容易理解，簡(jiǎn)單的賦值操作。不過(guò)在堆棧初始化中的ppdata = ppdata;opt = opt; 以及任務(wù)控制塊初始化中的pext= pext; stk_size= stk_size;pbos=pbos;opt=opt; id= id;這些語(yǔ)句剛開(kāi)始的時(shí)候很令人費(fèi)解。其實(shí)這些是防止編譯器不斷的報(bào)warning，以免影響正常的調(diào)試的。

2 任務(wù)創(chuàng)建

同上述創(chuàng)建空任務(wù)大體雷同。需要注意的是此時(shí)操作系統(tǒng)的OSRunning變量還是處于FALSE狀態(tài)，因此創(chuàng)建任務(wù)的過(guò)程中，操作系統(tǒng)并沒(méi)有開(kāi)始運(yùn)行。 這就是為什么操作系統(tǒng)在開(kāi)始運(yùn)行的時(shí)候不是選擇第一個(gè)創(chuàng)建的任務(wù)開(kāi)始運(yùn)行，而是從所有的任務(wù)里面選擇優(yōu)先級(jí)最高的運(yùn)行的原因。

3 任務(wù)調(diào)度

任務(wù)調(diào)度是從OSStart函數(shù)開(kāi)始的。具體包括OSStart、OsStartHighRdy、Task1~n、OSTimeDlyHMSM、OSSched等函數(shù)，其中任務(wù)交換是在匯編語(yǔ)言文件的OS_TASK_SW函數(shù)中運(yùn)行的。

OsStart在整個(gè)系統(tǒng)運(yùn)行的過(guò)程中只會(huì)運(yùn)行一次。在系統(tǒng)創(chuàng)建任務(wù)之后運(yùn)行。主要目的是從任務(wù)就緒表中挑選出優(yōu)先級(jí)最高的任務(wù)，并開(kāi)始運(yùn)行優(yōu)先級(jí)最高的任務(wù)。

OsStartHighRdy為asm文件中的一部分。主要是堆棧的操作。目的是要把高優(yōu)先級(jí)任務(wù)的任務(wù)堆棧復(fù)制到寄存器中，為即將開(kāi)始的運(yùn)行最高優(yōu)先級(jí)的任務(wù)做好準(zhǔn)備。

Task1~n。Task為一個(gè)無(wú)限循環(huán)函數(shù)。雖然是無(wú)限循環(huán)函數(shù)，但是與平常前后臺(tái)系統(tǒng)中的無(wú)限循環(huán)具有區(qū)別。因?yàn)?mu;COS-ii操作系統(tǒng)并不是一個(gè)像 Linux那樣的時(shí)間片輪流處理的操作系統(tǒng)，它僅僅是一個(gè)處理完一部分內(nèi)容之后再去處理另一部分內(nèi)容的實(shí)時(shí)操作系統(tǒng)。這就要求在每一個(gè)任務(wù)的每一個(gè)無(wú)限循 環(huán)中都要加一個(gè)調(diào)用OSSched函數(shù)的函數(shù)。

OSTimeDlyHMSM主要是為用戶提供一個(gè)良好的借口，將用戶輸入的時(shí)、分、秒、毫秒這四個(gè)數(shù)據(jù)轉(zhuǎn)換成系統(tǒng)的滴答數(shù)，然后調(diào)用OSTimeDly實(shí) 現(xiàn)。在OSTimeDly中調(diào)用OSSched，確保系統(tǒng)的實(shí)時(shí)性。OSSched函數(shù)結(jié)構(gòu)也類似于OSStart，主要是計(jì)算出任務(wù)就緒表中最高優(yōu)先級(jí) 的任務(wù)，通過(guò)OS_TASK_SW中的堆棧的操作實(shí)現(xiàn)任務(wù)的交換。

μCOS-ii查找最高優(yōu)先級(jí)算法的實(shí)現(xiàn)

指導(dǎo)思想：以空間換時(shí)間。

在查看源代碼的過(guò)程中，最令人費(fèi)解的或許就是OSUnMapTbl這個(gè)矩陣了。現(xiàn)將此矩陣復(fù)制如下：

INT8U const DT_XDATA OSUnMapTbl[] = {

0, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

6, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

7, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

6, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,

4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0

};

在了解這個(gè)矩陣的工作原理之前，我們有必要了解一下幾個(gè)變量的含義：

OSRdyGrp 是一個(gè)8位的unsigned char型數(shù)。由于該μCOS-ii系統(tǒng)最多允許prio為63，也就是說(shuō)最多允許有64個(gè)優(yōu)先級(jí)。64個(gè)優(yōu)先級(jí)被分成了八組，每組有八個(gè)優(yōu)先級(jí)。如果有 任何一組中的任務(wù)進(jìn)入了就緒狀態(tài)，則該組所對(duì)應(yīng)的位變?yōu)?。比如優(yōu)先級(jí)為4，23，56的任務(wù)同時(shí)進(jìn)入了就緒態(tài)，則對(duì)應(yīng)第0，2，7組中有任務(wù)進(jìn)入了就緒 態(tài)，則此時(shí)OSRdyGrp 應(yīng)為 10000101。

OSRdyTbl為一個(gè)有8個(gè)元素的8位數(shù)的數(shù)組，分別為OSRdyTbl[0]...OSRdyTbl[7]。從OSRdyTbl[0]到 OSRdyTbl[7]的每一位數(shù)對(duì)應(yīng)相應(yīng)優(yōu)先級(jí)的任務(wù)是不是進(jìn)入了就緒態(tài)。還是上面的例子，假如優(yōu)先級(jí)為4，23，56的任務(wù)進(jìn)入了就緒態(tài)，則 OSRdyTbl[0]的第4位，OSRdyTbl[2]的第7位，OSRdyTbl[7]的第0位變成1，其他的位仍然保持零。

介紹完兩個(gè)變量之后，就可以很容易理解這個(gè)矩陣的作用了。矩陣的第i個(gè)數(shù)字表示用二進(jìn)制表示的i中1所出現(xiàn)的最小位數(shù)。比如對(duì)于矩陣的第48個(gè)數(shù)字，48用二進(jìn)制表示為00110000，在第4位以及第5位中出現(xiàn)了1，故去最小值，則OSUnMapTbl[48]=4 。也就是說(shuō)，通過(guò)查這個(gè)矩陣得到的是最小的出現(xiàn)1的位數(shù)。假如對(duì)于OSRdyGrp 來(lái)說(shuō)，在OSRdyGrp 等于48的情況下，意味著第四組與第五組中有任務(wù)處于就緒狀態(tài)，則通過(guò)此表可以得出最高優(yōu)先級(jí)的任務(wù)在第四組中。假如對(duì)于OSRdyTbl來(lái) 說(shuō)，OSRdyTbl[4]表示第四組中每一個(gè)元素是不是處于就緒態(tài)。還是拿48來(lái)打比方，假如OSRdyTbl[4]等于48，有48用二進(jìn)制表示為 00110000可得第四位與第五位中有兩個(gè)任務(wù)處于就緒態(tài)，此時(shí)查詢OSUnMapTbl[48]=4可得優(yōu)先級(jí)最高的任務(wù)處于第四位上。由此很容易理 解這兩行代碼：

y= OSUnMapTbl[OSRdyGrp];

x = OSUnMapTbl[OSRdyTbl[y]];

因此得到的y為最高優(yōu)先級(jí)所在的組號(hào)。X為最高優(yōu)先級(jí)所在的組中最高優(yōu)先級(jí)所在的組的組號(hào)。由于每組有8個(gè)成員，對(duì)于y組第x個(gè)來(lái)說(shuō)，優(yōu)先級(jí)自然是 8*y+x 。由此得到了最高優(yōu)先級(jí)。下面的代碼不難理解。

OSPrioHighRdy = (INT8U)((y << 3) + x);

此外，因?yàn)檫@個(gè)矩陣無(wú)論在何種情況下，都是不變的，因此個(gè)人認(rèn)為原μCOS-ii系統(tǒng)中定義為DT_XDATA完全沒(méi)有必要，只是增加了系統(tǒng)的開(kāi)銷。因此我嘗試將此變量類型改成DT_CODE ，經(jīng)過(guò)運(yùn)行TMP124的嘗試，系統(tǒng)運(yùn)行幾十分鐘后仍然正常。因此得出了此處可以改進(jìn)的建議。而且改進(jìn)之后系統(tǒng)的占用xdata從600多字節(jié)減少到400多字節(jié)，系統(tǒng)資源占用減少很明顯。

可能編寫(xiě)μCOS-ii的工程師為了提高可移植性，將OSUnMapTbl定義為DT_XDATA吧。僅僅猜測(cè)而已。