|
uC/OS-II是一個簡潔、易用的基于優(yōu)先級的嵌入式搶占式多任務實時內(nèi)核。盡管它非常簡單，但是它的確在很大程度上解放了我的嵌入式開發(fā)工作。既然是一個操作系統(tǒng)內(nèi)核，那么一旦使用它，就會涉及到如何基于操作系統(tǒng)設計應用軟件的問題。 1. uC/OS-II的任務框架 void task_xxx(void *pArg) { /* 該任務的初始化工作 */ …… /* 進入該任務的死循環(huán) */ while(1) { …… } } 每個用戶的任務都必須符合事件驅(qū)動的編程模型，即uC/OS-II的應用程序都必須是“事件驅(qū)動的編程模型”。一個任務首先等待一個事件的發(fā)生，事件可以是系統(tǒng)中斷發(fā)出的，也可以是其它任務發(fā)出的，又可以是任務自身等待的時間片。當一個事件發(fā)生了，任務再作相應處理，處理結束后又開始等待下一個事件的發(fā)生。如此周而復始的任務處理模型就是“事件驅(qū)動的編程模型”。事件驅(qū)動模型也涵蓋了中斷驅(qū)動模型，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)出“事件驅(qū)動的編程模型”。 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的內(nèi)核時基時鐘就需要硬件定時器的中斷。 BSP就是“板極支持包”，它包括基于uC/OS-II而開發(fā)的事件驅(qū)動模型、支持多任務的驅(qū)動程序，這些驅(qū)動程序直接控制各個硬件模塊并利用uC/OS-II的系統(tǒng)函數(shù)來實現(xiàn)多任務功能，它們應該盡量避免應用程序直接操縱硬件和uC/OS-II內(nèi)核。BSP還應該為應用程序提供標準、統(tǒng)一的API，以達到軟件層次分明、應用軟件代碼可復用的目的。 應用程序就是用戶為具體應用需要而開發(fā)的軟件，它必須符合uC/OS-II的編程模型，即“事件驅(qū)動的編程模型”。應用程序還應該盡量避免直接控制硬件和直接調(diào)用uC/OS-II系統(tǒng)函數(shù)、變量，一個完善的uC/OS-II系統(tǒng)是不需要應用程序來針對具體硬件而設計的。也就是說，uC/OS-II必須擁有完備的設備驅(qū)動程序，而驅(qū)動程序和BSP共同提供完備、標準的API。 4.uC/OS-II中使用互斥信號對象應該注意 互斥信號對象(Mutual Exclusion Semaphore)簡稱Mutex，是uC/OS-II的內(nèi)核對象之一，用于管理那些需要獨占訪問的資源，并使其適應多任務環(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后，就不要再等待其它內(nèi)核對象(諸如：信號量、郵箱、隊列、事件標志等等)了，而應該盡量快速的完成工作，釋放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時間和內(nèi)存的。如果某高優(yōu)先級的任務要使用獨占資源，但是不在乎久等的情況下，就可以使用Sem，因為Sem是最高效最省內(nèi)存的內(nèi)核對象。 5.uC/OS-II應用程序調(diào)用OSSchedLock()和OSSchedUnlock()函數(shù)應注意 uC/OS-II的OSSchedLock()和OSSchedUnlock()函數(shù)允許應用程序鎖定當前任務不被其它任務搶占。使用時應當注意的是：當你調(diào)用了OSSchedLock()之后，而在調(diào)用OSSchedUnlock()之前，千萬不要再調(diào)用諸如OSFlagPend()、OSMboxPend()、OSMutexPend()、OSQPend()、OSSemPend()之類的事件等待函數(shù)！而且應當確保OSSchedLock()和OSSchedUnlock()函數(shù)成對出現(xiàn)，特別是在有些分支條件語句中，要考慮各種分支情況，不要有遺漏！ 需要一并提醒用戶的是：當您調(diào)用開關中斷函數(shù)OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()時也要確保成對出現(xiàn)，否則系統(tǒng)將可能崩潰！不過，在OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()函數(shù)之間調(diào)用OSFlagPend()、OSMboxPend()、OSMutexPend()、OSQPend()、OSSemPend()之類的事件等待函數(shù)是允許的。 6.uC/OS-II驅(qū)動程序編寫規(guī)范，特別推薦 首先應該闡明的是，我們這里討論的是“驅(qū)動程序”，而不是“中斷服務程序”，這兩個詞語往往被用戶混淆。 (1)中斷服務程序指那種硬件中斷一旦發(fā)生，就會立即被硬件中斷控制器調(diào)用的一小段程序，它的操作追求簡單明了，越快速越精簡就越好。 (2)驅(qū)動程序是指封裝了某種硬件操作細節(jié)的函數(shù)集，它提供給應用程序的是統(tǒng)一、標準、清晰、易用的API。 對于中斷服務程序的編寫，往往與驅(qū)動程序的設計相關聯(lián)。比如驅(qū)動程序提供異步操作的功能，那么就需要中斷服務程序為它準備緩沖區(qū)和一個結構體，并且中斷服務程序會依照這個結構體的成員參數(shù)自動完成所要求的操作。又如，串口(UART)中斷服務程序的設計有兩種：基于數(shù)據(jù)包傳輸和基于單字節(jié)傳輸，前者適用于以數(shù)據(jù)包為單位的通信程序，而后者適用于如超級終端這樣的應用程序。 如果在一個系統(tǒng)中，要求使用同一個硬件設備完成幾種不同的操作方式，就需要設計一個通用的驅(qū)動程序，而該驅(qū)動程序可以根據(jù)需要安裝各種針對性很強的中斷服務程序。 在設計驅(qū)動程序時，特別需要注意的是，某些外設的操作往往以一個連續(xù)而嚴格的時序作為原子操作，比如用I/O端口來訪問DS1302、24C01、LM75A等等。在這類設備的操作過程中，不允許有其它任務來控制對應的I/O端口，否則會引起數(shù)據(jù)錯誤甚至器件損壞。所以，這種設備的驅(qū)動程序都應該仔細設計“原子操作”，把必須連貫操作的時序控制代碼用互斥對象封裝成一個“原子操作”，以適應多任務環(huán)境。其實，大部分設備都是這樣，需要確定“原子操作”，如LCD、RTL8019AS、Flash等等也是如此。 1.AI時代FPGA廠商與FPGA工程師該如何轉型？ 2.介紹幾款嵌入式開發(fā)工具，或許能用上！ 3.牛人已經(jīng)總結了單片機應用程序架構，去看即可！ 4.4 月編程語言排行榜：萬年不變的前三 5.通過這 9 本開源好書學習 C 語言 6.ARM寄存器與匯編指令詳解 更多嵌入式學習，歡迎咨詢余工Q 二八五九七八零二零三 |
