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

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

void  task_xxx(void *pArg)

{

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

……   

/* 進入該任務的死迴圈 */

while(1)

{

……

}

}

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

(1)中斷服務函式傳送的事件

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

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

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

2.uC/OS-II的任務優先順序分配

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

3.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。

4.uC/OS-II中使用互斥訊號物件應該注意

互斥訊號物件(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是最高效最省記憶體的核心物件。

5.uC/OS-II應用程式呼叫OSSchedLock()和OSSchedUnlock()函式應注意

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()之類的事件等待函式是允許的。

6.uC/OS-II驅動程式編寫規範，特別推薦

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

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

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

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

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

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

免責宣告：本文系網路轉載，版權歸原作者所有。如涉及作品版權問題，請與我們聯絡，我們將根據您提供的版權證明材料確認版權並支付稿酬或者刪除內容。