uC/OS-II

μC/OS 和μC/OS-II 是專門為計算機的嵌入式套用設計的， 絕大部分代碼是用C語言編寫的。CPU 硬體相關部分是用彙編語言編寫的、總量約200行的彙編語言部分被壓縮到最低限度，為的是便於移植到任何一種其它的CPU 上。

基本介紹

• 外文名：uC/OS-II
• 服務對象：計算機的嵌入式套用
• 簡介：絕大部分代碼是用C語言編寫的
• 實質：硬實時核心。

工作原理

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為下一個任務的地址的目的。

任務管理

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出棧。把系統恢復到中斷前的狀態，使程式接著被中斷的部分繼續運行。

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

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的任務堆疊設計成圖1所示的形式。這種方法是把編譯器默認的壓棧操作放在前面，然後再把剩下的暫存器進棧。但是，由於編譯器在處理複雜程度不同的中斷服務程式的時候，壓入棧的暫存器的數量不定，所以會對以後其餘暫存器的壓棧和出棧操作增加複雜度。這裡，我們採用了圖2所示的方式生成堆疊。在這種堆疊中，PC和SR壓棧後，通過調整SP指針，使得R4~R15暫存器覆蓋編譯器默認壓棧的暫存器。這樣，處理的難度會小一點。

解決方法

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

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

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

這兩點MSP430都可以做到。

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

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

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

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

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

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

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

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

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

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

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

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

相關建議

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

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

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

(綜合電子論壇)

優先權

運行機制

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

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()，等待用戶程式的運行。

優先翻轉

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

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

在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)兩種辦法。

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

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

翻轉解決

在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時間，有利於系統實時性的提高。

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

開發筆記

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等等也是如此。

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