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等等也是如此。
關於驅動程序的設計，還有很多很多的文章可作，需要具體問題具體分析。在這裏我就不列出個條條目目了，希望有興趣的朋友多多討論。