（一） uC/OS-II 簡介
uC/OS-II是一種基於優先級的可搶先的硬實時內核。自從９２年發佈以來，在世界各地都獲得了廣泛的應用，它是一種專門爲嵌入式設備設計的內核，目前已經被移植到４０多種不同結構的CPU上，運行在從８位到６４位的各種系統之上。尤其值得一提的是，該系統自從２.51版本之後，就通過了美國FAA認證，可以運行在諸如航天器等對安全要求極爲苛刻的系統之上。鑑於uC/OS-II可以免費獲得代碼，對於嵌入式RTOS而言，選擇uC/OS無疑是最經濟的選擇。
（二） uC/OS-II 應用程序基本結構
應用uC/OS-II，自然要爲它開發應用程序，下面論述基於uC/OS-II的應用程序的基本結構以及注意事項。
每一個uC/OS-II應用至少要有一個任務。而每一個任務必須被寫成無限循環的形式。以下是推薦的結構：
void task ( void* pdata )
{
INT8U err;
InitTimer(); // 可選
For( ;; )
{
// 你的應用程序代碼
…….
……..
OSTimeDly(1); // 可選
}
}
以上就是基本結構，至於爲什麼要寫成無限循環的形式呢？那是因爲系統會爲每一個任務保留一個堆棧空間，由系統在任務切換的時候換恢復上下文，並執行一條reti 指令返回。如果允許任務執行到最後一個花括號（那一般都意味着一條ret指令）的話，很可能會破壞系統堆棧空間從而使應用程序的執行不確定。換句話說，就是“跑飛”了。所以，每一個任務必須被寫成無限循環的形式。程序員一定要相信，自己的任務是會放棄CPU使用權的，而不管是系統強制（通過ISR）還是主動放棄(通過調用OS API)。
現在來談論上面程序中的InitTimer()函數，這個函數應該由系統提供，程序員有義務在優先級最高的任務內調用它而且不能在for循環內調用。注意，這個函數是和所使用的CPU相關的，每種系統都有自己的Timer初始化程序。在uC/OS-II的幫助手冊內，作者特地強調絕對不能在OSInit()或者OSStart()內調用Timer初始化程序，那會破壞系統的可移植性同時帶來性能上的損失。所以，一個折中的辦法就是象上面這樣，在優先級最高的程序內調用，這樣可以保證當OSStart()調用系統內部函數OSStartHighRdy()開始多任務後，首先執行的就是Timer初始化程序。或者專門開一個優先級最高的任務，只做一件事情，那就是執行Timer初始化，之後通過調用OSTaskSuspend()將自己掛起來，永遠不再執行。不過這樣會浪費一個TCB空間。對於那些RAM吃緊的系統來說，還是不用爲好。
（三） 一些重要的uC/OS-II API介紹
任何一個操作系統都會提供大量的API供程序員使用，uC/OS-II也不例外。由於uC/OS-II面向的是嵌入式開發，並不要求大而全，所以內核提供的API也就大多和多任務息息相關。主要的有以下幾類：
１）任務類
２）消息類
３）同步類
４）時間類
５）臨界區與事件類
我個人認爲對於初級程序員而言，任務類和時間類是必須要首先掌握的兩種類型的API。下面我就來介紹比較重要的：
１） OSTaskCreate函數
這個函數應該至少再main函數內調用一次，在OSInit函數調用之後調用。作用就是創建一個任務。目前有四個參數，分別是任務的入口地址，任務的參數，任務堆棧的首地址和任務的優先級。調用本函數後，系統會首先從TCB空閒列表內申請一個空的TCB指針，然後將會根據用戶給出參數初始化任務堆棧，並在內部的任務就緒表內標記該任務爲就緒狀態。最後返回，這樣一個任務就創建成功了。
２） OSTaskSuspend函數
這個函數很簡單，一看名字就該明白它的作用，它可以將指定的任務掛起。如果掛起的是當前任務的話，那麼還會引發系統執行任務切換先導函數OSShed來進行一次任務切換。這個函數只有一個參數，那就是指定任務的優先級。那爲什麼是優先級呢？事實上在系統內部，優先級除了表示一個任務執行的先後次序外，還起着分別每一個任務的作用，換句話說，優先級也就是任務的ID。所以uC/OS-II不允許出現相同優先級的任務。
３） OSTaskResume函數
這個函數和上面的函數正好相反，它用於將指定的已經掛起的函數恢復成就緒狀態。如果恢復任務的優先級高於當前任務，那麼還爲引發一次任務切換。其參數類似OSTaskSuspend函數，爲指定任務的優先級。需要特別說明是，本函數並不要求和OSTaskSuspend函數成對使用。
４） OS_ENTER_CRITICAL宏
很多人都以爲它是個函數，其實不然，仔細分析一下OS_CPU.H文件，它和下面馬上要談到的OS_EXIT_CRITICAL都是宏。他們都是涉及特定CPU的實現。一般都被替換爲一條或者幾條嵌入式彙編代碼。由於系統希望向上層程序員隱藏內部實現，故而一般都宣稱執行此條指令後系統進入臨界區。其實，它就是關個中斷而已。這樣，只要任務不主動放棄CPU使用權，別的任務就沒有佔用CPU的機會了，相對這個任務而言，它就是獨佔了。所以說進入臨界區了。這個宏能少用還是少用，因爲它會破壞系統的一些服務，尤其是時間服務。並使系統對外界響應性能降低。
５） OS_EXIT_CRITICAL宏
這個是和上面介紹的宏配套使用另一個宏，它在系統手冊裏的說明是退出臨界區。其實它就是重新開中斷。需要注意的是，它必須和上面的宏成對出現，否則會帶來意想不到的後果。最壞的情況下，系統會崩潰。我們推薦程序員們儘量少使用這兩個宏調用，因爲他們的確會破壞系統的多任務性能。
６） OSTimeDly函數
這應該程序員們調用最多的一個函數了，這個函數完成功能很簡單，就是先掛起當起當前任務，然後進行任務切換，在指定的時間到來之後，將當前任務恢復爲就緒狀態，但是並不一定運行，如果恢復後是優先級最高就緒任務的話，那麼運行之。簡單點說，就是可以任務延時一定時間後再次執行它，或者說，暫時放棄CPU的使用權。一個任務可以不顯式的調用這些可以導致放棄CPU使用權的API，但那樣多任務性能會大大降低，因爲此時僅僅依靠時鐘機制在進行任務切換。一個好的任務應該在完成一些操作主動放棄使用權，好東西要大家分享嘛！
（四） uC/OS-II 多任務實現機制分析
前面已經說過，uC/OS-II是一種基於優先級的可搶先的多任務內核。那麼，它的多任務機制到底如何實現的呢？瞭解這些原理，可以幫助我們寫出更加健壯的代碼來。由於我們面向的初級程序員，本文不打算寫成又一篇uC/OS-II的源碼分析，那樣的文章太多了，本文打算從實現原理的角度探討這個問題。
首先我們來看看爲什麼多任務機制可以實現？其實在單一CPU的情況下，是不存在真正的多任務機制的，存在的只有不同的任務輪流使用CPU，所以本質上還是單任務的。但由於CPU執行速度非常快，加上任務切換十分頻繁並且切換的很快，所以我們感覺好像有很多任務同時在運行一樣。這就是所謂的多任務機制。
由上面的描述，不難發現，要實現多任務機制，那麼目標CPU必須具備一種在運行期更改PC的途徑，否則無法做到切換。不幸的使，直接設置PC指針，目前還沒有哪個CPU支持這樣的指令。但是一般CPU都允許通過類似JMP，CALL這樣的指令來間接的修改PC。我們的多任務機制的實現也正是基於這個出發點。事實上，我們使用CALL指令或者軟中斷指令來修改PC，主要是軟中斷。但在一些CPU上，並不存在軟中斷這樣的概念，所以，我們在那些CPU上，使用幾條PUSH指令加上一條CALL指令來模擬一次軟中斷的發生。
回想一下你在微機原理課程上學過的知識，當發生中斷的時候，CPU保存當前的PC和狀態寄存器的值到堆棧裏，然後將PC設置爲中斷服務程序的入口地址，再下來一個機器週期，就可以去執行中斷服務程序了。執行完畢之後，一般都是執行一條RETI指令，這條指令會把當前堆棧裏的值彈出恢復到狀態寄存器和PC裏。這樣，系統就會回到中斷以前的地方繼續執行了。那麼設想一下？如果再中斷的時候，人爲的更改了堆棧裏的值，那會發生什麼？或者通過更改當前堆棧指針的值，又會發生什麼呢？如果更改是隨意的，那麼結果是無法預料的錯誤。因爲我們無法確定機器下一條會執行些什麼指令，但是如果更改是計劃好的，按照一定規則的話，那麼我們就可以實現多任務機制。事實上，這就是目前幾乎所有的OS的核心部分。不過他們的實現不像這樣簡單罷了。
下面，我們來看看uC/OS-II再這方面是怎麼處理的。再uC/OS-II裏，每個任務都有一個任務控制塊(Task Control Block)，這是一個比較複雜的數據結構。在任務控制快的偏移爲0的地方，存儲着一個指針，它記錄了所屬任務的專用堆棧地址。事實上，再uC/OS-II內，每個任務都有自己的專用堆棧，彼此之間不能侵犯。這點要求程序員再他們的程序中保證。一般的做法是把他們申明成靜態數組。而且要申明成OS_STK類型。當任務有了自己的堆棧，那麼就可以將每一個任務堆棧再那裏記錄到前面談到的任務控制快偏移爲0的地方。以後每當發生任務切換，系統必然會先進入一箇中斷，這一般是通過軟中斷或者時鐘中斷實現。然後系統會先把當前任務的堆棧地址保存起來，僅接着恢復要切換的任務的堆棧地址。由於哪個任務的堆棧裏一定也存的是地址（還記得我們前面說過的，每當發生任務切換，系統必然會先進入一箇中斷，而一旦中斷CPU就會把地址壓入堆棧），這樣，就達到了修改PC爲下一個任務的地址的目的。
以上就是uC/OS-II的多任務實現機制，我們在這裏大費筆墨談論這個問題，是希望我們的程序員們可以善加利用這個機制，寫出更健壯，更富有效率的代碼來。