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

1、uC/OS-II的任務框架

void task_xxx(void *pArg)

{

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

……

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

while(1)

{

……

}

}

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

2、uC/OS-II的任務優(yōu)先級分配

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

3、uC/OS-II的軟件層次

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

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

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

4、uC/OS-II中使用互斥信號對象應該注意

互斥信號對象(Mutual Exclusion Semaphore)簡稱Mutex，是uC/OS-II的內核對象之一，用于管理那些需要獨占訪問的資源，并使其適應多任務環(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后，就不要再等待其它內核對象(諸如：信號量、郵箱、隊列、事件標志等等)了，而應該盡量快速的完成工作，釋放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時間和內存的。如果某高優(yōu)先級的任務要使用獨占資源，但是不在乎久等的情況下，就可以使用Sem，因為Sem是最高效最省內存的內核對象。

5、uC/OS-II應用程序調用OSSchedLock()和OSSchedUnlock()函數(shù)應注意

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

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

6、uC/OS-II驅動程序編寫規(guī)范，特別推薦

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

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

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

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

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

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

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