初級程序員指南：uC/OS-II 的使用手冊在這裏

uC/OS-II 簡介

uC/OS-II是一種基於優先級的可搶先的硬實時內核。自從92年發佈以來，在世界各地都得到了普遍的應用，它是一種專門爲嵌入式設備設計的內核，目前已經被移植到40多種不一樣結構的CPU上，運行在從8位到64位的各類系統之上。尤爲值得一提的是，該系統自從2.51版本以後，就經過了美國FAA認證，能夠運行在諸如航天器等對安全要求極爲苛刻的系統之上。鑑於uC/OS-II能夠免費得到代碼，對於嵌入式RTOS而言，選擇uC/OS無疑是最經濟的選擇。

 

2

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吃緊的系統來講，仍是不用爲好。

 

3

一些重要的uC/OS-II API介紹

任何一個操做系統都會提供大量的API供程序員使用，uC/OS-II也不例外。因爲uC/OS-II面向的是嵌入式開發，並不要求大而全，因此內核提供的API也就大多和多任務息息相關。主要的有如下幾類：

1)任務類

2)消息類

3)同步類

4)時間類

5)臨界區與事件類

 

我我的認爲對於初級程序員而言，任務類和時間類是必需要首先掌握的兩種類型的API。下面我就來介紹比較重要的：

 

1) OSTaskCreate函數

這個函數應該至少再main函數內調用一次，在OSInit函數調用以後調用。做用就是建立一個任務。目前有四個參數，分別是任務的入口地址，任務的參數，任務堆棧的首地址和任務的優先級。調用本函數後，系統會首先從TCB空閒列表內申請一個空的TCB指針，而後將會根據用戶給出參數初始化任務堆棧，並在內部的任務就緒表內標記該任務爲就緒狀態。最後返回，這樣一個任務就建立成功了。

 

2) OSTaskSuspend函數

這個函數很簡單，一看名字就該明白它的做用，它能夠將指定的任務掛起。若是掛起的是當前任務的話，那麼還會引起系統執行任務切換先導函數OSShed來進行一次任務切換。這個函數只有一個參數，那就是指定任務的優先級。那爲何是優先級呢?事實上在系統內部，優先級除了表示一個任務執行的前後次序外，還起着分別每個任務的做用，換句話說，優先級也就是任務的ID。因此uC/OS-II不容許出現相同優先級的任務。

 

3) OSTaskResume函數

這個函數和上面的函數正好相反，它用於將指定的已經掛起的函數恢復成就緒狀態。若是恢復任務的優先級高於當前任務，那麼還爲引起一次任務切換。其參數相似OSTaskSuspend函數，爲指定任務的優先級。須要特別說明是，本函數並不要求和OSTaskSuspend函數成對使用。

 

4) OS_ENTER_CRITICAL宏

不少人都覺得它是個函數，其實否則，仔細分析一下OS_CPU.H文件，它和下面立刻要談到的OS_EXIT_CRITICAL都是宏。他們都是涉及特定CPU的實現。通常都被替換爲一條或者幾條嵌入式彙編代碼。因爲系統但願向上層程序員隱藏內部實現，故而通常都宣稱執行此條指令後系統進入臨界區。其實，它就是關個中斷而已。這樣，只要任務不主動放棄CPU使用權，別的任務就沒有佔用CPU的機會了，相對這個任務而言，它就是獨佔了。因此說進入臨界區了。這個宏能少用仍是少用，由於它會破壞系統的一些服務，尤爲是時間服務。並使系統對外界響應性能下降。

 

5) OS_EXIT_CRITICAL宏

這個是和上面介紹的宏配套使用另外一個宏，它在系統手冊裏的說明是退出臨界區。其實它就是從新開中斷。須要注意的是，它必須和上面的宏成對出現，不然會帶來意想不到的後果。最壞的狀況下，系統會崩潰。咱們推薦程序員們儘可能少使用這兩個宏調用，由於他們的確會破壞系統的多任務性能。

 

6) OSTimeDly函數

這應該程序員們調用最多的一個函數了，這個函數完成功能很簡單，就是先掛起當起當前任務，而後進行任務切換，在指定的時間到來以後，將當前任務恢復爲就緒狀態，可是並不必定運行，若是恢復後是優先級最高就緒任務的話，那麼運行之。簡單點說，就是能夠任務延時必定時間後再次執行它，或者說，暫時放棄CPU的使用權。一個任務能夠不顯式的調用這些能夠致使放棄CPU使用權的API，但那樣多任務性能會大大下降，由於此時僅僅依靠時鐘機制在進行任務切換。一個好的任務應該在完成一些操做主動放棄使用權，好東西要你們分享嘛!

 

4

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的多任務實現機制，咱們在這裏大費筆墨談論這個問題，是但願咱們的程序員們能夠善加利用這個機制，寫出更健壯，更富有效率的代碼來