uC/OS-II

uC/OS-II是一種基於優先級的可搶佔的硬實時內核。

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

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

uC/OS-II 中最多可以支持64 個任務，分別對應優先級0～63，其中0 為最高優先級。63為最低級，系統保留了4個最高優先級的任務和4個最低優先級的任務，所有用户可以使用的任務數有56個。

uC/OS-II提供了任務管理的各種函數調用，包括創建任務，刪除任務，改變任務的優先級，任務掛起和恢復等。

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

uC/OS-II的時間管理是通過定時中斷來實現的，該定時中斷一般為10毫秒或100毫秒發生一次，時間頻率取決於用户對硬件系統的定時器編程來實現。中斷髮生的時間間隔是固定不變的，該中斷也成為一個時鐘節拍。

uC/OS-II要求用户在定時中斷的服務程序中，調用系統提供的與時鐘節拍相關的系統函數，例如中斷級的任務切換函數，系統時間函數。

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

uC/OS-II中把連續的大塊內存按分區管理。每個分區中包含整數個大小相同的內存塊，但不同分區之間的內存塊大小可以不同。用户需要動態分配內存時，系統選擇一個適當的分區，按塊來分配內存。釋放內存時將該塊放回它以前所屬的分區，這樣能有效解決碎片問題，同時執行時間也是固定的。

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

uC/OS-II 採用的是可剝奪型實時多任務內核。可剝奪型的實時內核在任何時候都運行就緒了的最高優先級的任務。

uC/os-II的任務調度是完全基於任務優先級的搶佔式調度，也就是最高優先級的任務一旦處於就緒狀態，則立即搶佔正在運行的低優先級任務的處理器資源。為了簡化系統設計，uC/OS-II規定所有任務的優先級不同，因為任務的優先級也同時唯一標誌了該任務本身。

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

2） 高優先級的任務因為時鐘節拍到來，在時鐘中斷的處理程序中，內核發現高優先級任務獲得了執行條件(如休眠的時鐘到時)，則在中斷態直接切換到高優先級任務執行。這種調度也稱為中斷級的上下文切換。

這兩種調度方式在uC/OS-II的執行過程中非常普遍，一般來説前者發生在系統服務中，後者發生在時鐘中斷的服務程序中。

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

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

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

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

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

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

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

任務同步和通信部分 為事件處理部分，包括信號量、郵箱、郵箱隊列、事件標誌等部分；主要用於任務間的互相聯繫和對臨界資源的訪問。

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

2.1 函數調用和中斷調用的操作

MSP430最常使用的C編譯器應該就是IAR Embedd-ed WorkBench。對於這一編譯器來説，通過分析和研究，發現它有以下規律。

如果是函數級調用，編譯器會在函數調用時先把當前函數PC壓棧，然後調用函數，PC值改變。

如果被調用的函數帶有參數，那麼，編譯器按照以下的規則進行。

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

如果是在中斷中調用中斷服務子程序的話，編譯器將把當前執行語句的PC壓棧，同時再把SR壓棧。接着，根據中斷服務子程序的複雜程度，選擇把R12~R15中的寄存器壓棧。然後，執行中斷服務子程序。中斷處理結束後再把Rx寄存器出棧，SR出棧，PC出棧。把系統恢復到中斷前的狀態，使程序接着被中斷的部分繼續運行。

中斷髮生時的任務棧壓棧操作

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

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

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

void OSSched(void){

關中斷

如果（不是中斷嵌套並且系統可以被調度）{

確定優先級最高的任務

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

調用OSCtxSw();

}

}

開中斷

}

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

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

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

保存全部CPU寄存器

調用OSIntEnter()或OSIntNesting++

開放中斷

執行用户代碼

關閉中斷

調用OSIntExit();

恢復所有CPU寄存器

RETI

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

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

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

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

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

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

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

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

這兩點MSP430都可以做到。

下面對一個正在運行的優先級為6的任務中斷後，會發生的幾種情況進行分析。

1）在中斷的處理過程中沒有更高優先級的中斷產生，即不會產生中斷嵌套。

中斷髮生後對於任務優先級為6的任務堆棧所進行的操作。中斷髮生後，PC和SR被系統壓棧②，對於IAR C編譯器來説，會按照複雜度不同的中斷服務程序的要求，默認地進行一些寄存器的壓棧操作③。因為我們要求的堆棧格式，我們要把SP調整到SR後面④，然後進行R4~R15的壓棧操作，形成我們所要求的堆棧格式⑤。

進行任務堆棧的壓棧工作以後，就可以調整SP的指針到系統堆棧了。壓棧後的SP指向最後一個壓棧內容①。我們把SP的值賦值給優先級6任務的TCB->OSTCBStkPtr，以便進行任務調度的時候出棧使用②。接着，就把SP調整到系統堆棧處③。在中斷處理過程中，可能會出現壓棧的操作，那麼這種情況下SP的指針會隨之移動。由於是中斷堆棧中，所以不會破壞任務堆棧的格式。

由於沒有中斷嵌套，在中斷處理中沒有別的中斷髮生，那麼返回的步驟和上述的進棧操作正好相反。在中斷處理完了以後，SP會自動回到③的SP位置。接着，系統會查詢到優先級最高的任務，然後把SP的指針移到優先級最高的任務的任務堆棧，進行R15~R4的出棧工作，最後用RETI中斷返回指令返回到新的任務。因為我們把所有的任務堆棧都規定成相同的格式，所以它們之間不會產生問題。這裏需要注意的是，因為系統在C編譯器的中斷處理中會對中斷進入時默認壓棧的寄存器出棧，所以在設計出棧的程序時，要先把這些內容壓棧，這樣才能正確出棧。

2）在中斷的處理過程中，有別的中斷產生，產生中斷嵌套。

由於在處理中斷的時候，SP已經被移到系統堆棧去了，只有當中斷退出的時候才可能把SP移到別的任務的任務堆棧中。所以在中斷的時候進行中斷嵌套，那麼對於中斷的處理和第一次是一樣的，所不同的是，這次保存在堆棧中的不是任務運行中的寄存器，而是中斷處理中的寄存器，而且是保存在系統堆棧中而不是任務堆棧中。從這裏就可以看出優化內存的效果。所有的中斷嵌套中的寄存器壓棧都壓在系統堆棧中，這樣對於任務堆棧內存大小的要求大大降低。

因為μC/OS-II在進入中斷中，會把全局變量OSIntNesting++；在退出中斷的時候，又會把OSIntNesting--。在退出中斷進行任務切換之前，μC/OS-II會先判斷OSIntNesting是否為0，是0才會進行任務調度。當第二中斷運行結束以後，退出中斷嵌套的時候，OSIntNesting不為0，也就不會進行任務調度。因此，仍舊在系統堆棧出棧，那麼系統會繼續前面沒有完成的中斷服務程序。

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

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

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

中斷堆棧和任務堆棧分離設計的程序流程。

① 編寫中斷程序的時候，有條件儘量使用匯編語言。因為這樣可以避免一些編譯器自己進行的操作，減少指針調整的次數。

② 在用C編寫中斷服務的時候，因為有些功能必須調用匯編的函數才能實現。調用函數時，有些時候壓棧的PC會破壞堆棧的結構。這個時候需要把堆棧進行適當的調整，保證堆棧格式的正確。

③中斷處理過程中調用OSIntExit()的時候，由於 μC/OS-II的原始設計中SP指針有時是不調整的，所以在OSIntExit()返回了以後，還要判斷一下是否中斷嵌套。因為有的時候是需要切換任務的。

(綜合電子論壇)

在嵌入式系統的應用中，實時性是一個重要的指標，而優先級翻轉是影響系統實時性的重要問題。本文着重分析優先級翻轉問題的產生和影響，以及在uC/OS-II中的解決方案。 ^[2] 

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

在uC/OS-II中，多個任務按照優先級高低由內核調度執行，而且任務調度所花的時間是常數，與應用程序中建立的任務數無關。對於佔先式內核，任務的響應時間是確定的，而且是最優化的，佔先式內核保證最高優先級的任務最先執行。 ^[2] 

任務的響應時間=尋找最高優先級任務的時間+任務切換時間

在uC/OS-II中尋找進入就緒態的最高優先級任務是通過查就緒表實現的，這減少了所需時間。

y=OSUnMapTbl[OSRdyGrp];

x= OSUnMapTbl [OSRdyTbl[y]];

prio=(y<<3)+x;

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

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

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

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

總之，優先級翻轉問題是多任務實時操作系統普遍存在的問題，這個問題也存在於uC/OS-II中。通過在應用程序中進行簡單的判斷，在可能出現優先級翻轉的情況下動態的改變任務的優先級，可以有效地避免任務的優先級翻轉，保證高優先級任務的執行，提高了系統的實時性。 ^[2] 

uC/OS-II是一個簡潔、易用的基於優先級的嵌入式搶佔式多任務實時內核。儘管它非常簡單，但是它的確在很大程度上解放了我的嵌入式開發工作。既然是一個操作系統內核，那麼一旦使用它，就會涉及到如何基於操作系統設計應用軟件的問題。

void task_xxx(void *pArg)

{

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

……

/* 進入該任務的死循環 */

while(1)

{

……

}

}

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

(1)中斷服務函數發送的事件

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

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

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

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

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

BSP就是“板極支持包”，它包括基於uC/OS-II而開發的事件驅動模型、支持多任務的驅動程序，這些驅動程序直接控制各個硬件模塊並利用uC/OS-II的系統函數來實現多任務功能，它們應該儘量避免應用程序直接操縱硬件和uC/OS-II內核。BSP還應該為應用程序提供標準、統一的API，以達到軟件層次分明、應用軟件代碼可複用的目的。

應用程序就是用户為具體應用需要而開發的軟件，它必須符合uC/OS-II的編程模型，即“事件驅動的編程模型”。應用程序還應該儘量避免直接控制硬件和直接調用uC/OS-II系統函數、變量，一個完善的uC/OS-II系統是不需要應用程序來針對具體硬件而設計的。也就是説，uC/OS-II必須擁有完備的設備驅動程序，而驅動程序和BSP共同提供完備、標準的API。

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

創建每一個Mutex，都需要指定一個空閒的優先級號，這個優先級號的優先級必須比所有可能使用此Mutex的任務的優先級都高！

uC/OS-II的Mutex實現原理大致如下：

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

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

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

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

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

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

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

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

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

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

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

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

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