RIOT OS

　 目錄

    1 工作原理                6 存在問題
    2 任務管理                7 解決方法
    3 通信同步                8 相關建議
    4 任務調(diào)度                9 優(yōu)先級
    5 中斷機理                10 開發(fā)筆記　

工作原理

　　uC/OS-II是一種基于優(yōu)先級的可搶先的硬實時內(nèi)核。

　　要實現(xiàn)多任務機制,那么目標CPU必須具備一種在運行期更改PC的途徑,否則無法做到切換。不幸的是,直接設置PC指針,還沒有哪個CPU支持這樣的指令。但是一般CPU都允許通過類似JMP,CALL這樣的指令來間接的修改PC。我們的多任務機制的實現(xiàn)也正是基于這個出發(fā)點。事實上,我們使用CALL指令或者軟中斷指令來修改PC,主要是軟中斷。但在一些CPU上,并不存在軟中斷這樣的概念,所以,我們在那些CPU上,使用幾條PUSH指令加上一條CALL指令來模擬一次軟中斷的發(fā)生。

　　在uC/OS-II里,每個任務都有一個任務控制塊(Task Control Block),這是一個比較復雜的數(shù)據(jù)結構。在任務控制塊的偏移為0的地方,存儲著一個指針,它記錄了所屬任務的專用堆棧地址。事實上,在uC/OS-II內(nèi),每個任務都有自己的專用堆棧,彼此之間不能侵犯。這點要求程序員在他們的程序中保證。一般的做法是把他們申明成靜態(tài)數(shù)組。而且要申明成OS_STK類型。當任務有了自己的堆棧,那么就可以將每一個任務堆棧在那里記錄到前面談到的任務控制快偏移為0的地方。以后每當發(fā)生任務切換,系統(tǒng)必然會先進入一個中斷,這一般是通過軟中斷或者時鐘中斷實現(xiàn)。然后系統(tǒng)會先把當前任務的堆棧地址保存起來,緊接著恢復要切換的任務的堆棧地址。由于哪個任務的堆棧里一定也存的是地址（還記得我們前面說過的,每當發(fā)生任務切換,系統(tǒng)必然會先進入一個中斷,而一旦中斷CPU就會把地址壓入堆棧）,這樣,就達到了修改PC為下一個任務的地址的目的。

　　任務管理

　　uC/OS-II 中最多可以支持64 個任務，分別對應優(yōu)先級0～63，其中0 為最高優(yōu)先級。63為最低級，系統(tǒng)保留了4個最高優(yōu)先級的任務和4個最低優(yōu)先級的任務，所有用戶可以使用的任務數(shù)有56個。

　　uC/OS-II提供了任務管理的各種函數(shù)調(diào)用，包括創(chuàng)建任務，刪除任務，改變?nèi)蝿盏膬?yōu)先級，任務掛起和恢復等。

　　系統(tǒng)初始化時會自動產(chǎn)生兩個任務：一個是空閑任務，它的優(yōu)先級最低，該任務僅給一個整型變量做累加運算；另一個是系統(tǒng)任務，它的優(yōu)先級為次低，該任務負責統(tǒng)計當前cpu的利用率。

　　時間管理

　　uC/OS-II的時間管理是通過定時中斷來實現(xiàn)的，該定時中斷一般為10毫秒或100毫秒發(fā)生一次，時間頻率取決于用戶對硬件系統(tǒng)的定時器編程來實現(xiàn)。中斷發(fā)生的時間間隔是固定不變的，該中斷也成為一個時鐘節(jié)拍。

　　uC/OS-II要求用戶在定時中斷的服務程序中，調(diào)用系統(tǒng)提供的與時鐘節(jié)拍相關的系統(tǒng)函數(shù)，例如中斷級的任務切換函數(shù)，系統(tǒng)時間函數(shù)。

　　內(nèi)存管理

　　在ANSI C中是使用malloc和free兩個函數(shù)來動態(tài)分配和釋放內(nèi)存。但在嵌入式實時系統(tǒng)中，多次這樣的操作會導致內(nèi)存碎片，且由于內(nèi)存管理算法的原因，malloc和free的執(zhí)行時間也是不確定。

　　uC/OS-II中把連續(xù)的大塊內(nèi)存按分區(qū)管理。每個分區(qū)中包含整數(shù)個大小相同的內(nèi)存塊，但不同分區(qū)之間的內(nèi)存塊大小可以不同。用戶需要動態(tài)分配內(nèi)存時，系統(tǒng)選擇一個適當?shù)姆謪^(qū)，按塊來分配內(nèi)存。釋放內(nèi)存時將該塊放回它以前所屬的分區(qū)，這樣能有效解決碎片問題，同時執(zhí)行時間也是固定的。

　　通信同步

　　對一個多任務的操作系統(tǒng)來說，任務間的通信和同步是必不可少的。uC/OS-II中提供了4種同步對象，分別是信號量，郵箱，消息隊列和事件。所有這些同步對象都有創(chuàng)建，等待，發(fā)送，查詢的接口用于實現(xiàn)進程間的通信和同步。

　　任務調(diào)度

　　uC/OS-II 采用的是可剝奪型實時多任務內(nèi)核?？蓜儕Z型的實時內(nèi)核在任何時候都運行就緒了的最高優(yōu)先級的任務。

　　uC/os-II的任務調(diào)度是完全基于任務優(yōu)先級的搶占式調(diào)度，也就是最高優(yōu)先級的任務一旦處于就緒狀態(tài)，則立即搶占正在運行的低優(yōu)先級任務的處理器資源。為了簡化系統(tǒng)設計，uC/OS-II規(guī)定所有任務的優(yōu)先級不同，因為任務的優(yōu)先級也同時唯一標志了該任務本身。

　　1） 高優(yōu)先級的任務因為需要某種臨界資源，主動請求掛起，讓出處理器，此時將調(diào)度就緒狀態(tài)的低優(yōu)先級任務獲得執(zhí)行，這種調(diào)度也稱為任務級的上下文切換。

　　2） 高優(yōu)先級的任務因為時鐘節(jié)拍到來，在時鐘中斷的處理程序中，內(nèi)核發(fā)現(xiàn)高優(yōu)先級任務獲得了執(zhí)行條件(如休眠的時鐘到時)，則在中斷態(tài)直接切換到高優(yōu)先級任務執(zhí)行。這種調(diào)度也稱為中斷級的上下文切換。

　　這兩種調(diào)度方式在uC/OS-II的執(zhí)行過程中非常普遍，一般來說前者發(fā)生在系統(tǒng)服務中，后者發(fā)生在時鐘中斷的服務程序中。

　　調(diào)度工作的內(nèi)容可以分為兩部分：最高優(yōu)先級任務的尋找和任務切換。其最高優(yōu)先級任務的尋找是通過建立就緒任務表來實現(xiàn)的。u C / O S 中的每一個任務都有獨立的堆棧空間，并有一個稱為任務控制塊TCB(Task Control Block)的數(shù)據(jù)結構，其中第一個成員變量就是保存的任務堆棧指針。任務調(diào)度模塊首先用變量OSTCBHighRdy 記錄當前最高級就緒任務的TCB 地址，然后調(diào)用OS_TASK_SW()函數(shù)來進行任務切換。

　　中斷機理

　　引 言

　　在嵌入式操作系統(tǒng)領域，由Jean J. Labrosse開發(fā)的μC/OS，由于開放源代碼和強大而穩(wěn)定的功能，曾經(jīng)一度在嵌入式系統(tǒng)領域引起強烈反響。而其本人也早已成為了嵌入式系統(tǒng)會議（美國）的顧問委員會的成員。

　　不管是對于初學者，還是有經(jīng)驗的工程師，μC/OS開放源代碼的方式使其不但知其然，還知其所以然。通過對于系統(tǒng)內(nèi)部結構的深入了解，能更加方便地進行開發(fā)和調(diào)試；并且在這種條件下，完全可以按照設計要求進行合理的裁減、擴充、配置和移植。通常，購買RTOS往往需要一大筆資金，使得一般的學習者望而卻步；而μC/OS對于學校研究完全免費，只有在應用于盈利項目時才需要支付少量的版權費，特別適合一般使用者的學習、研究和開發(fā)。自1992第1版問世以來，已有成千上萬的開發(fā)者把它成功地應用于各種系統(tǒng)，安全性和穩(wěn)定性已經(jīng)得到認證，現(xiàn)已經(jīng)通過美國FAA認證。

　　組成部分

　　μC/OS-II可以大致分成核心、任務處理、時間處理、任務同步與通信，CPU的移植等5個部分。

　　核心部分(OSCore.c) 是操作系統(tǒng)的處理核心，包括操作系統(tǒng)初始化、操作系統(tǒng)運行、中斷進出的前導、時鐘節(jié)拍、任務調(diào)度、事件處理等多部分。能夠維持系統(tǒng)基本工作的部分都在這里。

　　任務處理部分(OSTask.c) 任務處理部分中的內(nèi)容都是與任務的操作密切相關的。包括任務的建立、刪除、掛起、恢復等等。因為μC/OS-II是以任務為基本單位調(diào)度的，所以這部分內(nèi)容也相當重要。

　　時鐘部分(OSTime.c) μC/OS-II中的最小時鐘單位是timetick（時鐘節(jié)拍）。任務延時等操作是在這里完成的。

　　任務同步和通信部分 為事件處理部分，包括信號量、郵箱、郵箱隊列、事件標志等部分；主要用于任務間的互相聯(lián)系和對臨界資源的訪問。

　　與CPU的接口部分 是指μC/OS-II針對所使用的CPU的移植部分。由于μC/OS-II是一個通用性的操作系統(tǒng)，所以對于關鍵問題上的實現(xiàn)，還是需要根據(jù)具體CPU的具體內(nèi)容和要求作相應的移植。這部分內(nèi)容由于牽涉到SP等系統(tǒng)指針，所以通常用匯編語言編寫。主要包括中斷級任務切換的底層實現(xiàn)、任務級任務切換的底層實現(xiàn)、時鐘節(jié)拍的產(chǎn)生和處理、中斷的相關處理部分等內(nèi)容。

　　中斷處理

　　2.1 函數(shù)調(diào)用和中斷調(diào)用的操作

　　MSP430最常使用的C編譯器應該就是IAR Embedd-ed WorkBench。對于這一編譯器來說，通過分析和研究，發(fā)現(xiàn)它有以下規(guī)律。

　　函數(shù)調(diào)用

　　如果是函數(shù)級調(diào)用，編譯器會在函數(shù)調(diào)用時先把當前函數(shù)PC壓棧，然后調(diào)用函數(shù)，PC值改變。

　　如果被調(diào)用的函數(shù)帶有參數(shù)，那么，編譯器按照以下的規(guī)則進行。

　　最左邊的兩個參數(shù)如果不是struct（結構體）或者union（聯(lián)合體），將被賦值到寄存器，否則將被壓棧。函數(shù)剩下的參數(shù)都將被壓棧。根據(jù)最左邊的那兩個參數(shù)的類型，分別賦值給R12（對于32位類型賦值給R12:R13）和R14(對于32位類型賦值給R14:R15)。

　　中斷調(diào)用

　　如果是在中斷中調(diào)用中斷服務子程序的話，編譯器將把當前執(zhí)行語句的PC壓棧，同時再把SR壓棧。接著，根據(jù)中斷服務子程序的復雜程度，選擇把R12~R15中的寄存器壓棧。然后，執(zhí)行中斷服務子程序。中斷處理結束后再把Rx寄存器出棧，SR出棧，PC出棧。把系統(tǒng)恢復到中斷前的狀態(tài)，使程序接著被中斷的部分繼續(xù)運行。

　　圖3 中斷發(fā)生時的任務棧壓棧操作

　　2.2 任務級和中斷級的任務切換步驟和原理

　　(1)任務級的任務切換原理

　　μC/OS-II是一個多任務的操作系統(tǒng)，在沒有用戶自己定義的中斷情況下，任務間的切換步驟是這樣的：任務間的切換一般會調(diào)用OSSched()函數(shù)。函數(shù)的結構如下：

　　void OSSched(void){

　　關中斷

　　如果（不是中斷嵌套并且系統(tǒng)可以被調(diào)度）{

　　確定優(yōu)先級最高的任務

　　如果（最高級的任務不是當前的任務）{

　　調(diào)用OSCtxSw();

　　}

　　}

　　開中斷

　　}

　　我們把這個函數(shù)稱作任務調(diào)度的前導函數(shù)。它先判斷要進行任務切換的條件，如果條件允許進行任務調(diào)度，則調(diào)用OSCtxSw()。這個函數(shù)是真正實現(xiàn)任務調(diào)度的函數(shù)。由于期間要對堆棧進行操作，所以OSCtxSw()一般用匯編語言寫成。它將正在運行的任務的CPU的SR寄存器推入堆棧，然后把R4~R15壓棧。接著把當前的SP保存在TCB->OSTCBStkPtr中，然后把最高優(yōu)先級的TCB->OSTCBStkPtr的值賦值給SP。這時候，SP就已經(jīng)指到最高優(yōu)先級任務的任務堆棧了。然后進行出棧工作，把R15~R4出棧。接著使用RETI返回，這樣就把SR和PC出棧了。簡單地說，μC/OS-II切換到最高優(yōu)先級的任務，只是恢復最高優(yōu)先級任務所有的寄存器并運行中斷返回指令（RETI），實際上，所作的只是人為地模仿了一次中斷。

　　(2)中斷級的任務切換原理

　　μC/OS-II的中斷服務子程序和一般前后臺的操作有少許不同，往往需要這樣操作：

　　保存全部CPU寄存器

　　調(diào)用OSIntEnter()或OSIntNesting++

　　開放中斷

　　執(zhí)行用戶代碼

　　關閉中斷

　　調(diào)用OSIntExit();

　　恢復所有CPU寄存器

　　RETI

　　OSIntEnter()就是將全局變量OSIntNesting加1。OSIntNesting是中斷嵌套層數(shù)的變量。μC/OS-II通過它確保在中斷嵌套的時候，不進行任務調(diào)度。執(zhí)行完用戶的代碼后，μC/OS-II調(diào)用OSIntExit()，一個與OSSched()很像的函數(shù)。在這個函數(shù)中，系統(tǒng)首先把OSIntNesting減1，然后判斷是否中斷嵌套。如果不是的話，并且當前任務不是最高優(yōu)先級的任務，那么找到優(yōu)先級最高的任務，執(zhí)行OSIntCtxSw()這一出中斷任務切換函數(shù)。因為，在這之前已經(jīng)做好了壓棧工作；在這個函數(shù)中，要進行R15~R4的出棧工作。而且，由于在之前調(diào)用函數(shù)的時候，可能已經(jīng)有一些寄存器被壓入了堆棧。所以要進行堆棧指針的調(diào)整，使得能夠從正確的位置出棧。

　　存在問題

　　由于μC/OS-II在應用的時候會占用單片機上的一些資源，如系統(tǒng)時鐘、RAM、Flash或者ROM，從而減少了用戶程序?qū)Y源的利用。對于MSP430來說，RAM的占用是特別突出的問題。對于8、16位的單片機來說，片內(nèi)的RAM容量都很小，MSP430也是如此（最大的片內(nèi)RAM也只有2KB，例如MSP430F149）。如果使用擴展內(nèi)存，會大大增加設計難度。

　　通過對μC/OS-II的分析可以得知，μC/OS-II占用的RAM主要是用在每個任務的TCB、每個任務的堆棧等方面。通過進一步分析，發(fā)現(xiàn)任務堆棧大的原因是因為MSP430的硬件設計中沒有把中斷堆棧和任務堆棧分開。這樣就造成了在應用μC/OS-II的時候，考慮每個任務的任務堆棧大小時，不單單需要計算任務中局部變量和函數(shù)嵌套層數(shù)，還需要考慮中斷的最大嵌套層數(shù)。因為，對于μC/OS-II原始的中斷處理的設計、中斷處理過程中的中斷嵌套中所需要壓棧的寄存器大小和局部變量的內(nèi)存大小，都需要算在每個任務的任務堆棧中，則對于每一個任務都需要預留這一部分內(nèi)存，所以大量的RAM被浪費。從這里可以看出，解決這一問題的直接方法就是把中斷堆棧和每個任務自己的堆棧分開。這樣，在計算每個任務堆棧的時候，就不需要把中斷處理中（包括中斷嵌套過程中）的內(nèi)存的占用計算到每個任務的任務堆棧中，只需要計算每個任務本身需要的內(nèi)存大小，從而提高了RAM的利用率，可以緩解內(nèi)存緊張的問題。

　　在這種設計方案中，中斷堆棧區(qū)也就是利用原有的MSP430中的系統(tǒng)堆棧區(qū)。在前后臺的設計形式中，中斷中的壓棧和出棧的操作都是在系統(tǒng)的堆棧區(qū)完成的?；?mu;C/OS-II的任務切換的原理，我們對于任務堆棧的功能和系統(tǒng)堆棧的功能做了以下劃分：任務在運行過程中產(chǎn)生中斷和任務切換的時候，PC和SR以及寄存器Rx都保存在各個任務自己的任務堆棧中；而中斷嵌套產(chǎn)生的壓棧和出棧的操作都是放在系統(tǒng)堆棧中進行的。這種劃分方式是基于盡量將中斷任務與普通任務分開的思想設計的。

　　從前面對于IAR EW的默認操作分析來看，堆棧的結構可以有兩種。一種是把μC/OS-II的任務堆棧設計成圖1所示的形式。這種方法是把編譯器默認的壓棧操作放在前面，然后再把剩下的寄存器進棧。但是，由于編譯器在處理復雜程度不同的中斷服務程序的時候，壓入棧的寄存器的數(shù)量不定，所以會對以后其余寄存器的壓棧和出棧操作增加復雜度。這里，我們采用了圖2所示的方式生成堆棧。在這種堆棧中，PC和SR壓棧后，通過調(diào)整SP指針，使得R4~R15寄存器覆蓋編譯器默認壓棧的寄存器。這樣，處理的難度會小一點。

　　解決方法

　　對于這樣的設計方式，CPU必須能夠：

　　◆ 有相應的CPU寄存器能夠模仿SP的一些功能，能使用相應的指令來完成類似SP的一些操作；

　　◆ 作為SP使用的寄存器在編譯過程中最好不被編譯器默認使用。在IAR的編譯器中，有一個選項可以避免在編譯過程中使用到R4、R5。

　　這兩點MSP430都可以做到。

　　下面對一個正在運行的優(yōu)先級為6的任務中斷后，會發(fā)生的幾種情況進行分析。

　　1）在中斷的處理過程中沒有更高優(yōu)先級的中斷產(chǎn)生，即不會產(chǎn)生中斷嵌套。

　　圖3所示為中斷發(fā)生后對于任務優(yōu)先級為6的任務堆棧所進行的操作。中斷發(fā)生后，PC和SR被系統(tǒng)壓棧②，對于IAR C編譯器來說，會按照復雜度不同的中斷服務程序的要求，默認地進行一些寄存器的壓棧操作③。因為我們要求的堆棧格式是如圖2所示的，我們要把SP調(diào)整到SR后面④，然后進行R4~R15的壓棧操作，形成我們所要求的堆棧格式⑤。

　　進行任務堆棧的壓棧工作以后，就可以調(diào)整SP的指針到系統(tǒng)堆棧了，如圖4所示。壓棧后的SP指向最后一個壓棧內(nèi)容①。我們把SP的值賦值給優(yōu)先級6任務的TCB->OSTCBStkPtr，以便進行任務調(diào)度的時候出棧使用②。接著，就把SP調(diào)整到系統(tǒng)堆棧處③。在中斷處理過程中，可能會出現(xiàn)壓棧的操作，那么這種情況下SP的指針會隨之移動。由于是中斷堆棧中，所以不會破壞任務堆棧的格式。

　　由于沒有中斷嵌套，在中斷處理中沒有別的中斷發(fā)生，那么返回的步驟和上述的進棧操作正好相反。在中斷處理完了以后，SP會自動回到圖4中③的SP位置。接著，系統(tǒng)會查詢到優(yōu)先級最高的任務，然后把SP的指針移到優(yōu)先級最高的任務的任務堆棧，進行R15~R4的出棧工作，最后用RETI中斷返回指令返回到新的任務。因為我們把所有的任務堆棧都規(guī)定成相同的格式，所以它們之間不會產(chǎn)生問題。這里需要注意的是，因為系統(tǒng)在C編譯器的中斷處理中會對中斷進入時默認壓棧的寄存器出棧，所以在設計出棧的程序時，要先把這些內(nèi)容壓棧，這樣才能正確出棧。

　　2）在中斷的處理過程中，有別的中斷產(chǎn)生，產(chǎn)生中斷嵌套。

　　如圖5所示，由于在處理中斷的時候，SP已經(jīng)被移到系統(tǒng)堆棧去了，只有當中斷退出的時候才可能把SP移到別的任務的任務堆棧中。所以在中斷的時候進行中斷嵌套，那么對于中斷的處理和第一次是一樣的，所不同的是，這次保存在堆棧中的不是任務運行中的寄存器，而是中斷處理中的寄存器，而且是保存在系統(tǒng)堆棧中而不是任務堆棧中。從這里就可以看出優(yōu)化內(nèi)存的效果。所有的中斷嵌套中的寄存器壓棧都壓在系統(tǒng)堆棧中，這樣對于任務堆棧內(nèi)存大小的要求大大降低。

　　因為μC/OS-II在進入中斷中，會把全局變量OSIntNesting++；在退出中斷的時候，又會把OSIntNesting--。在退出中斷進行任務切換之前，μC/OS-II會先判斷OSIntNesting是否為0，是0才會進行任務調(diào)度。當?shù)诙袛噙\行結束以后，退出中斷嵌套的時候，OSIntNesting不為0，也就不會進行任務調(diào)度。因此，仍舊在系統(tǒng)堆棧出棧，那么系統(tǒng)會繼續(xù)前面沒有完成的中斷服務程序。

　　接著退出中斷的順序和非中斷嵌套的順序是一樣的。在中斷處理完以后，SP會自動回到圖4中③的SP位置。接著，系統(tǒng)會查詢到優(yōu)先級最高的任務，然后把SP的指針移到優(yōu)先級最高的任務的任務堆棧。進行R15~R4的出棧工作，最后用RETI中斷返回指令返回到新的任務。

　　中斷的情況基本上就是上述兩種。對于有些文獻中提到的在中斷中會調(diào)度到更高優(yōu)先級的任務的情況，筆者覺得是不應該發(fā)生的。因為從上面的分析可以看出，默認的（μC/OS-II的設計思路）中斷處理會同時對全局變量OSIntNesting進行增減處理，以給出是否需要任務調(diào)度的條件。那么即使在中斷服務程序中把更高優(yōu)先級的任務就緒，也會等到中斷退出以后再進行調(diào)度，除非是在中斷中直接調(diào)用更高優(yōu)先級的任務函數(shù)。但這種方法應該是和μC/OS-II的原則相違背的，沿用的是以前前后臺設計的思路。

　　對于這樣的設計方式，時鐘節(jié)拍的處理方式必須和一般的中斷處理方式是一樣的。一般來說，MSP430使用WATCHDOG時鐘中斷作為時鐘節(jié)拍的產(chǎn)生源。從本質(zhì)上來說，時鐘節(jié)拍本身也是中斷處理過程，所以對于時鐘節(jié)拍的處理應該和其它的中斷處理過程相同。實際上，在時鐘節(jié)拍的處理過程中也可能會存在中斷嵌套的問題。

　　中斷堆棧和任務堆棧分離設計的程序流程如圖6所示。

　　相關建議

　?、?編寫中斷程序的時候，有條件盡量使用匯編語言。因為這樣可以避免一些編譯器自己進行的操作，減少指針調(diào)整的次數(shù)。

　?、?在用C編寫中斷服務的時候，因為有些功能必須調(diào)用匯編的函數(shù)才能實現(xiàn)。調(diào)用函數(shù)時，有些時候壓棧的PC會破壞堆棧的結構。這個時候需要把堆棧進行適當?shù)恼{(diào)整，保證堆棧格式的正確。

　?、壑袛嗵幚磉^程中調(diào)用OSIntExit()的時候，由于 μC/OS-II的原始設計中SP指針有時是不調(diào)整的，所以在OSIntExit()返回了以后，還要判斷一下是否中斷嵌套。因為有的時候是需要切換任務的。

　　(綜合電子論壇)

　　優(yōu)先級

　　運行機制

　　在嵌入式系統(tǒng)的應用中，實時性是一個重要的指標，而優(yōu)先級翻轉是影響系統(tǒng)實時性的重要問題。本文著重分析優(yōu)先級翻轉問題的產(chǎn)生和影響，以及在uC/OS-II中的解決方案。[2]

　　uC/OS-II采用基于固定優(yōu)先級的占先式調(diào)度方式，是一個實時、多任務的操作系統(tǒng)。系統(tǒng)中的每個任務具有一個任務控制快OS_TCB，任務控制塊記錄任務執(zhí)行的環(huán)境，包括任務的優(yōu)先級，任務的堆棧指針，任務的相關事件控制塊指針等。內(nèi)核將系統(tǒng)中處于就緒態(tài)的任務在就緒表(ready list)進行標注，通過就緒表中的兩個變量OSRdyGrp和OSRdyTbl[]可快速查找系統(tǒng)中就緒的任務。在uC/OS-II中每個任務有唯一的優(yōu)先級，因此任務的優(yōu)先級也是任務的唯一編號(ID)，可以作為任務的唯一標識。內(nèi)核可用控制塊優(yōu)先級表OSTCBPrioTbl[]由任務的優(yōu)先級查到任務控制塊的地址。uC/OS-II主要就是利用任務控制快OS_TCB、就緒表(ready list)和控制塊優(yōu)先級表OSTCBPrioTbl[]來進行任務調(diào)度的。任務調(diào)度程序OSSched()首先由就緒表(ready list)中找到當前系統(tǒng)中處于就緒態(tài)的優(yōu)先級最高的任務，然后根據(jù)其優(yōu)先級由控制塊優(yōu)先級表OSTCBPrioTbl[]取得相應任務控制塊的地址，由OS_TASK_SW()程序進行運行環(huán)境的切換。將當前運行環(huán)境切換成該任務的運行環(huán)境，則該任務由就緒態(tài)轉為運行態(tài)。當這個任務運行完畢或因其它原因掛起時，任務調(diào)度程序OSSched()再次到就緒表(ready list)中尋找當前系統(tǒng)中處于就緒態(tài)中優(yōu)先級最高的任務，轉而執(zhí)行該任務，如此完成任務調(diào)度。若在任務運行時發(fā)生中斷，則轉向執(zhí)行中斷程序，執(zhí)行完畢后不是簡單的返回中斷調(diào)用處，而是由OSIntExit()程序進行任務調(diào)度，執(zhí)行當前系統(tǒng)中優(yōu)先級最高的就緒態(tài)任務。當系統(tǒng)中所有任務都執(zhí)行完畢時，任務調(diào)度程序OSSched()就不斷執(zhí)行優(yōu)先級最低的空閑任務OSTaskIdle()，等待用戶程序的運行。[2]

　　優(yōu)先翻轉

　　在uC/OS-II中，多個任務按照優(yōu)先級高低由內(nèi)核調(diào)度執(zhí)行，而且任務調(diào)度所花的時間是常數(shù)，與應用程序中建立的任務數(shù)無關。對于占先式內(nèi)核，任務的響應時間是確定的，而且是最優(yōu)化的，占先式內(nèi)核保證最高優(yōu)先級的任務最先執(zhí)行。[2]

　　任務的響應時間=尋找最高優(yōu)先級任務的時間+任務切換時間

　　在uC/OS-II中尋找進入就緒態(tài)的最高優(yōu)先級任務是通過查就緒表實現(xiàn)的，這減少了所需時間。

　　y=OSUnMapTbl[OSRdyGrp];

　　x= OSUnMapTbl [OSRdyTbl[y]];

　　prio=(y<<3)+x;

　　任務切換是通過調(diào)用匯編函數(shù)OS_TASK_SW()來實現(xiàn)的，主要完成兩個任務運行環(huán)境的保存和恢復。因此用戶可以通過安排任務的優(yōu)先級，保證系統(tǒng)的實時性。當涉及到共享資源的互斥訪問時，多任務實時操作系統(tǒng)常常會出現(xiàn)優(yōu)先級翻轉問題(priority inversion)，不能保證高優(yōu)先級任務的響應時間，影響系統(tǒng)的實時性，uC/OS-II中也存在同樣問題。所謂優(yōu)先級翻轉問題(priority inversion)即當一個高優(yōu)先級任務通過信號量機制訪問共享資源時，該信號量已被一低優(yōu)先級任務占有，而這個低優(yōu)先級任務在訪問共享資源時可能又被其它一些中等優(yōu)先級的任務搶先，因此造成高優(yōu)先級任務被許多具有較低優(yōu)先級的任務阻塞，實時性難以得到保證。例如：有優(yōu)先級為A、B和C的三個任務，優(yōu)先級A>B>C，任務A，B處于掛起狀態(tài)，等待某一事件的發(fā)生，任務C正在運行，此時任務C開始使用某一共享資源S。在使用中，任務A等待的事件到來，任務A轉為就緒態(tài)，因為它比任務C優(yōu)先級高，所以立即執(zhí)行。當任務A要使用共享資源S時，由于其正在被任務C使用，因此任務A被掛起，任務C開始運行。如果此時任務B等待的事件到來，則任務B轉為就緒態(tài)。由于任務B的優(yōu)先級比任務C高，因此任務B開始運行，直到其運行完畢，任務C才開始運行。直到任務C釋放共享資源S后，任務A才得以執(zhí)行。在這種情況下，優(yōu)先級發(fā)生了翻轉，任務B先于任務A運行。這樣便不能保證高優(yōu)先級任務的響應時間，解決優(yōu)先級翻轉問題有優(yōu)先級天花板(priority ceiling)和優(yōu)先級繼承(priority inheritance)兩種辦法。[2]

　　優(yōu)先級天花板是當任務申請某資源時，把該任務的優(yōu)先級提升到可訪問這個資源的所有任務中的最高優(yōu)先級，這個優(yōu)先級稱為該資源的優(yōu)先級天花板。這種方法簡單易行，不必進行復雜的判斷，不管任務是否阻塞了高優(yōu)先級任務的運行，只要任務訪問共享資源都會提升任務的優(yōu)先級。在uC/OS-II中，可以通過OSTaskChangePrio()改變?nèi)蝿盏膬?yōu)先級，但是改變?nèi)蝿盏膬?yōu)先級是很花時間的。如果不發(fā)生優(yōu)先級翻轉而提升了任務的優(yōu)先級，釋放資源后又改回原優(yōu)先級，則無形中浪費了許多CPU時間，也影響了系統(tǒng)的實時性。

　　優(yōu)先級繼承是當任務A申請共享資源S時，如果S正在被任務C使用，通過比較任務C與自身的優(yōu)先級，如發(fā)現(xiàn)任務C的優(yōu)先級小于自身的優(yōu)先級，則將任務C的優(yōu)先級提升到自身的優(yōu)先級，任務C釋放資源S后，再恢復任務C的原優(yōu)先級。這種方法只在占有資源的低優(yōu)先級任務阻塞了高優(yōu)先級任務時才動態(tài)的改變?nèi)蝿盏膬?yōu)先級，如果過程較復雜，則需要進行判斷。uC/OS-II不支持優(yōu)先級繼承，而且其以任務的優(yōu)先級作為任務標識，每個優(yōu)先級只能有一個任務，因此，不適宜在應用程序中使用優(yōu)先級繼承。[2]

　　翻轉解決

　　在uC/OS-II中，為解決優(yōu)先級翻轉影響任務實時性的問題，可以借鑒優(yōu)先級繼承的方法對優(yōu)先級天花板方法進行改進。對uC/OS-II的使用，共享資源任務的優(yōu)先級不是全部提升，而是先判斷再決定是否提升。即當有任務A申請共享資源S時，首先判斷是否有別的的任務正在占用資源S，若無，則任務A繼續(xù)執(zhí)行，若有，假設為任務B正在使用該資源，則判斷任務B的優(yōu)先級是否低于任務A，若高于任務A，則任務A掛起，等待任務B釋放該資源，如果任務B的優(yōu)先級低于任務A，則提升任務B的優(yōu)先級到該資源的優(yōu)先級天花板，當任務B釋放資源后，再恢復到原優(yōu)先級。在uC/OS-II中，每個共享資源都可看作一個事件，每個事件都有相應的事件控制塊ECB。在ECB中包含一個等待本事件的等待任務列表，該列表包括OSEventTbl[]和OSEventGrp兩個域，通過對等待任務列表的判斷可以很容易的確定是否有多個任務在等待該資源，同時也可判斷任務的優(yōu)先級與當前任務優(yōu)先級的高低，從而決定是否需要用OSTaskChangePio()來改變?nèi)蝿盏膬?yōu)先級。這樣，僅在優(yōu)先級有可能發(fā)生翻轉的情況下才改變?nèi)蝿盏膬?yōu)先級，而且利用事件的等待任務列表進行判斷，比用OSTaskChangePio()來改變?nèi)蝿盏膬?yōu)先級速度快，并占用較少的CPU時間，有利于系統(tǒng)實時性的提高。[2]

　　總之，優(yōu)先級翻轉問題是多任務實時操作系統(tǒng)普遍存在的問題，這個問題也存在于uC/OS-II中。通過在應用程序中進行簡單的判斷，在可能出現(xiàn)優(yōu)先級翻轉的情況下動態(tài)的改變?nèi)蝿盏膬?yōu)先級，可以有效地避免任務的優(yōu)先級翻轉，保證高優(yōu)先級任務的執(zhí)行，提高了系統(tǒng)的實時性。[2]

　　開發(fā)筆記

　　uC/OS-II是一個簡潔、易用的基于優(yōu)先級的嵌入式搶占式多任務實時內(nèi)核。盡管它非常簡單，但是它的確在很大程度上解放了我的嵌入式開發(fā)工作。既然是一個操作系統(tǒng)內(nèi)核，那么一旦使用它，就會涉及到如何基于操作系統(tǒng)設計應用軟件的問題。

　　任務框架

　　void task_xxx(void *pArg)

　　{

　　/* 該任務的初始化工作 */

　　……

　　/* 進入該任務的死循環(huán) */

　　while(1)

　　{

　　……

　　}

　　}

　　每個用戶的任務都必須符合事件驅(qū)動的編程模型，即uC/OS-II的應用程序都必須是“事件驅(qū)動的編程模型”。一個任務首先等待一個事件的發(fā)生，事件可以是系統(tǒng)中斷發(fā)出的，也可以是其它任務發(fā)出的，又可以是任務自身等待的時間片。當一個事件發(fā)生了，任務再作相應處理，處理結束后又開始等待下一個事件的發(fā)生。如此周而復始的任務處理模型就是“事件驅(qū)動的編程模型”。事件驅(qū)動模型也涵蓋了中斷驅(qū)動模型，uC/OS-II事件歸根結底來自三個方面：

　　(1)中斷服務函數(shù)發(fā)送的事件

　　(2)系統(tǒng)延時時間到所引起的

　　(3)其它任務發(fā)送的事件。

　　其中“中斷服務函數(shù)發(fā)送的事件”就是指每當有硬件中斷發(fā)生，那么中斷服務程序就會以事件的形式告訴任務，而等待該事件的最高優(yōu)先級任務就會馬上得以運行；“系統(tǒng)延時時間到所引起的”事件其實也是硬件中斷導致的，那就是系統(tǒng)定時器中斷。而“其它任務發(fā)送的事件”則是由任務代碼自身決定的，這是完全的“軟事件”。不管“軟事件”還是“硬事件”，反正引起uC/OS-II任務切換的原因就是“事件”，所以用戶編寫應用代碼的時候一定要體現(xiàn)出“事件驅(qū)動的編程模型”。

　　任務分配

　　uC/OS-II的任務優(yōu)先級分配需要按照不同的系統(tǒng)設計具體分析。比如，對實時性要求越高的任務，則優(yōu)先級要越高。

　　軟件層次

　　uC/OS-II會直接操縱硬件，比如：任務切換代碼必然要保存和恢復CPU及協(xié)處理器的寄存器；uC/OS-II的內(nèi)核時基時鐘就需要硬件定時器的中斷。

　　BSP就是“板極支持包”，它包括基于uC/OS-II而開發(fā)的事件驅(qū)動模型、支持多任務的驅(qū)動程序，這些驅(qū)動程序直接控制各個硬件模塊并利用uC/OS-II的系統(tǒng)函數(shù)來實現(xiàn)多任務功能，它們應該盡量避免應用程序直接操縱硬件和uC/OS-II內(nèi)核。BSP還應該為應用程序提供標準、統(tǒng)一的API，以達到軟件層次分明、應用軟件代碼可復用的目的。

　　應用程序就是用戶為具體應用需要而開發(fā)的軟件，它必須符合uC/OS-II的編程模型，即“事件驅(qū)動的編程模型”。應用程序還應該盡量避免直接控制硬件和直接調(diào)用uC/OS-II系統(tǒng)函數(shù)、變量，一個完善的uC/OS-II系統(tǒng)是不需要應用程序來針對具體硬件而設計的。也就是說，uC/OS-II必須擁有完備的設備驅(qū)動程序，而驅(qū)動程序和BSP共同提供完備、標準的API。

　　信號注意

　　互斥信號對象(Mutual Exclusion Semaphore)簡稱Mutex，是uC/OS-II的內(nèi)核對象之一，用于管理那些需要獨占訪問的資源，并使其適應多任務環(huán)境。

　　創(chuàng)建每一個Mutex，都需要指定一個空閑的優(yōu)先級號，這個優(yōu)先級號的優(yōu)先級必須比所有可能使用此Mutex的任務的優(yōu)先級都高！

　　uC/OS-II的Mutex實現(xiàn)原理大致如下：

　　當一個低優(yōu)先級的任務A申請并得到了Mutex，于是它獲得資源訪問權。如果此后有一個高優(yōu)先級的任務B開始運行(此時任務A已經(jīng)被剝奪)，而且也要求得到Mutex，系統(tǒng)就會把任務A的優(yōu)先級提高到Mutex所指定的優(yōu)先級。由于此優(yōu)先級高于任何可能使用此Mutex的任務的優(yōu)先級，所以任務A會馬上獲得CPU控制權。一直到任務A釋放Mutex，任務A才回到它原有的優(yōu)先級，這時任務B就可以擁有該Mutex了。

　　應該注意的是：當任務A得到Mutex后，就不要再等待其它內(nèi)核對象(諸如：信號量、郵箱、隊列、事件標志等等)了，而應該盡量快速的完成工作，釋放Mutex。否則，這樣的Mutex就失去了作用，而且效果比直接使用信號量(Sem)更糟糕！

　　雖然普通的信號量(Sem)也可以用于互斥訪問某獨占資源，但是它可能引起“優(yōu)先級反轉”的問題。假設上面的例子使用的是Sem，當任務A得到Sem后，那么任務C(假設任務C的優(yōu)先級比A高，但比B低)就緒的話將獲得CPU控制權，于是任務A和任務B都被剝奪CPU控制權。任務C的優(yōu)先級比B低，卻優(yōu)先得到了CPU！而如果任務A是優(yōu)先級最低的任務，那么它就要等到所有比它優(yōu)先級高的任務都掛起之后才會擁有CPU，那么任務B(優(yōu)先級最高的任務)跟著它一起倒霉！這就是優(yōu)先級反轉問題，這是違背“基于優(yōu)先級的搶占式多任務實時操作系統(tǒng)”原則的！

　　綜上所述，uC/OS-II中多個任務訪問獨占資源時，最好使用Mutex，但是Mutex是比較消耗CPU時間和內(nèi)存的。如果某高優(yōu)先級的任務要使用獨占資源，但是不在乎久等的情況下，就可以使用Sem，因為Sem是最高效最省內(nèi)存的內(nèi)核對象。

　　函數(shù)應注意

　　uC/OS-II的OSSchedLock()和OSSchedUnlock()函數(shù)允許應用程序鎖定當前任務不被其它任務搶占。使用時應當注意的是：當你調(diào)用了OSSchedLock()之后，而在調(diào)用OSSchedUnlock()之前，千萬不要再調(diào)用諸如OSFlagPend()、OSMboxPend()、OSMutexPend()、OSQPend()、OSSemPend()之類的事件等待函數(shù)！而且應當確保OSSchedLock()和OSSchedUnlock()函數(shù)成對出現(xiàn)，特別是在有些分支條件語句中，要考慮各種分支情況，不要有遺漏！

　　需要一并提醒用戶的是：當您調(diào)用開關中斷函數(shù)OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()時也要確保成對出現(xiàn)，否則系統(tǒng)將可能崩潰！不過，在OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()函數(shù)之間調(diào)用OSFlagPend()、OSMboxPend()、OSMutexPend()、OSQPend()、OSSemPend()之類的事件等待函數(shù)是允許的。

　　編寫規(guī)范

　　首先應該闡明的是，我們這里討論的是“驅(qū)動程序”，而不是“中斷服務程序”，這兩個詞語往往被用戶混淆。

　　(1)中斷服務程序指那種硬件中斷一旦發(fā)生，就會立即被硬件中斷控制器調(diào)用的一小段程序，它的操作追求簡單明了，越快速越精簡就越好。

　　(2)驅(qū)動程序是指封裝了某種硬件操作細節(jié)的函數(shù)集，它提供給應用程序的是統(tǒng)一、標準、清晰、易用的API。

　　對于中斷服務程序的編寫，往往與驅(qū)動程序的設計相關聯(lián)。比如驅(qū)動程序提供異步操作的功能，那么就需要中斷服務程序為它準備緩沖區(qū)和一個結構體，并且中斷服務程序會依照這個結構體的成員參數(shù)自動完成所要求的操作。又如，串口(UART)中斷服務程序的設計有兩種：基于數(shù)據(jù)包傳輸和基于單字節(jié)傳輸，前者適用于以數(shù)據(jù)包為單位的通信程序，而后者適用于如超級終端這樣的應用程序。

　　如果在一個系統(tǒng)中，要求使用同一個硬件設備完成幾種不同的操作方式，就需要設計一個通用的驅(qū)動程序，而該驅(qū)動程序可以根據(jù)需要安裝各種針對性很強的中斷服務程序。

　　在設計驅(qū)動程序時，特別需要注意的是，某些外設的操作往往以一個連續(xù)而嚴格的時序作為原子操作，比如用I/O端口來訪問DS1302、24C01、LM75A等等。在這類設備的操作過程中，不允許有其它任務來控制對應的I/O端口，否則會引起數(shù)據(jù)錯誤甚至器件損壞。所以，這種設備的驅(qū)動程序都應該仔細設計“原子操作”，把必須連貫操作的時序控制代碼用互斥對象封裝成一個“原子操作”，以適應多任務環(huán)境。其實，大部分設備都是這樣，需要確定“原子操作”，如LCD、RTL8019AS、Flash等等也是如此。

　　關于驅(qū)動程序的設計，還有很多很多的文章可作，需要具體問題具體分析。在這里我就不列出個條條目目了，希望有興趣的朋友多多討論。[1]

　　參考資料

　　1. uC/OS-II系統(tǒng)開發(fā)筆記 ．電子開發(fā)網(wǎng)[引用日期2013-06-14]

　　2. 優(yōu)先級 ．電子發(fā)燒友網(wǎng)[引用日期2013-06-4]