已經有不少的文章介紹了有關μC/OS-II這個實時內核及其應用。在很多的處理器上,
μC/OS-II都得到了應用。μC/OS-II是一種源碼公開、可移植、可固化、可裁減、可剝奪的
實時多任務操作系統(tǒng)。特別適用于用戶任務較多,而對實時性要求較嚴格的場合。
μC/OS-II內核是一個占先式內核,用戶視任務的輕重緩急不同賦予任務不同的優(yōu)先
級。一般來說,用戶任務的實時性要求越高,則應賦予的優(yōu)先級也越高;對那些要求不甚嚴
格的任務,賦予的優(yōu)先級應低一些。對突發(fā)事件,像A/D采樣后的數(shù)據(jù)讀取等,則應采用中
斷,實時響應,因而,中斷享有最高的優(yōu)先級。優(yōu)先級高的任務在進行調度時,優(yōu)先得到資
源,因而能及時進入運行態(tài)運行;優(yōu)先級低的得不到資源而進入就緒態(tài),等待下一次任務調
度。由于任務優(yōu)先級的唯一性,μC/OS-II內核能在不同任務間井然有序地調度運行。
μC/OS-II內核的功能強大,提供了用于共享資源的信號燈,用于進程通信的消息隊列
和郵箱等,是一個比較全面的系統(tǒng)。但有些地方仍然值得改進,比如該系統(tǒng)不支持時間片的
任務調度,因而一旦任務進入了死循環(huán),調度程序無法調度,其它的任務也就得不到及時運
行處理。解決的方法也很簡單,只要在定時中斷服務程序中調用函數(shù)OSIntCtxSw()即可。
μC/OS-II內核的另外一個值得改進的地方是它的堆棧處理。為了確保運行的安全可
靠,μC/OS-II內核將每個任務的堆??臻g都按最大化處理,結果導致RAM的需求變大,往往
還需外擴RAM,而浪費過多。下面詳細討論如何改進μC/OS-II內核的堆棧結構設計。
1 μC/OS-II的堆棧結構
在堆棧的處理上,μC/OS-II為每個任務分配一個獨立的堆棧,堆??臻g按任務中最大
需求進行分配。這種方法可保證程序可靠運行,但卻是以浪費大量的空間為代價。對一些小
系統(tǒng)來說,沒有擴展外部RAM,內部RAM相當小,RAM的空間利用就非常重要了。下面就來探
討如何改進μC/OS內核,以達到減少任務棧的內存需求。
在μC/OS-II中,每個任務都定義了一個獨立的堆??臻g,這個堆棧空間用來存放任務
的相關信息,具體包括以下幾個部分(如圖1所示):
◆ 任務中定義的局部變量及被調用函數(shù)可能在棧上分配的局部變量;
◆ 任務中各個函數(shù)的返回地址;
◆ 發(fā)生中斷時需要保存的上下文;
◆ 中斷嵌套時需要保存的上下文。
在這4個部分中,前3個的內存需求是比較容易估算的,只要察看反匯編代碼,并計算各
個函數(shù)的棧需求,留有一定的裕量就可以了。但是第4部分的棧空間使用量是隨中斷嵌套的
深度而不斷增加的,是不確定的,一般方法是定義一個充分大的??臻g,使之不會溢出。但
為每個任務都定義一個充分大的棧空間,會導致??臻g的浪費。如果將第4部分獨立出來,
單獨為它定義一個較大的空間,在任務棧中去掉原來的第4部分,這樣,就可大大減少???br />
間的浪費,減少對內存的需求。實際上,這是可行的。在μC/OS-II中,內核為中斷嵌套的
層數(shù)定義了一個全局變量OSIntNesting。系統(tǒng)在進行任務調度時,先要判斷OSIntNesting是
否為0,如果OSIntNesting不為0,則不進行任務切換。也就是說:在OSIntNesting為1(當
前只有一個中斷,并且沒有嵌套中斷)時,如果發(fā)生了嵌套的中斷(不管嵌套的層數(shù)有多
深),那么所有嵌套的中斷一層一層地都返回,直到OSIntNesting再次為1時止,任務棧是
不會切換的,棧指針始終在同一個任務的??臻g中變化。因而,可以為中斷嵌套單獨定義一
個中斷嵌套棧。在發(fā)生第1次中斷時,中斷服務程序將??臻g切換到中斷嵌套棧,這樣,以
后發(fā)生的嵌套中斷就一直使用這個??臻g。在中斷返回到第1次中斷時,即OSIntNesting為1
時,中斷服務程序再從中斷嵌套棧切換回任務棧。這樣就實現(xiàn)了中斷任務的切換,減少了內
存需求。下面以此思路,來進一步討論堆棧處理的結構設計。
2 μC/OS-II的堆棧改進設計
按上述設計,可設置中斷嵌套棧OSInterruptStk,對中斷服務程序做如下修改。
① 保存全部CPU寄存器。
② 直接將OSIntNesting加1。
增加:判斷OSIntNesting是否等于1,如果不是則轉到3。
增加:將棧指針SP保存到OSTCBCur->OSTCBStkPtr。
增加:將SP指向OSInterruptStk的棧頂(注意棧增長的方向)。
③ 執(zhí)行用戶代碼做中斷服務。
④ 調用OSIntExit。
增加:判斷OSIntNesting是否等于0,如果不是則轉到5。
增加:從OSTCBCur->OSTCBStkPtr中恢復棧指針SP。
⑤ 恢復所有CPU寄存器。
⑥ 執(zhí)行中斷返回指令。
此時,任務的堆棧分布情況如圖2所示。
這樣,就實現(xiàn)了中斷嵌套棧和任務棧的雙向切換。此外,還需修改OSIntCtxSw()函數(shù),原始
的OSIntCtxSw()函數(shù)的寫法如下:
① 調整棧指針,去掉在調用OSIntExit()和OSIntCtxSw()過程中入棧的多余內容;
② 將當前棧指針保存到OSTCBCur中,即STCBCur->OSTCBStkPtr = SP;
③ 如果需要則調用OSTaskSwHook;
④OSTCBCur = OSTCBHighRdy;
⑤OSPrio = OSPrioHighRdy;
⑥ 從OSTCBCur中恢復棧指針,SP= OSTCBCur ->OSTCBStkPtr;
⑦ 恢復保存了的CPU寄存器;
⑧ 執(zhí)行中斷返回指令。
新的寫法只需將原寫法中的1、2去掉即可,因為1、2步只是保存舊任務的棧指針,而新
寫法中,這些步被移到了“中斷服務程序”中。作了上述修改后,原來在每個任務棧中都必
須的第4部分已被移到了中斷嵌套棧,實現(xiàn)了降低內存需求的目的。
結 語
μC/OS-II內核的堆棧處理適用于RAM存儲器充足,任務切換頻繁,對實時性要求嚴格的
場合,一般主要用在16位或32位微處理器較大的系統(tǒng)設計中。對于一般的小系統(tǒng),由于RAM
空間有限,任務不多,切換也不是太頻繁,因而,在堆棧處理上可以采用中斷嵌套棧。這大
大減少了對RAM存儲器的需求,不但簡化了硬件設計,而且還降低了成本。