淺析μC/OS-ⅡAPI的設計思想及實現(xiàn)機制

3.5查詢一個信號量的當前狀態(tài), OSSemQuery()

INT8U OSSemQuery (OS_EVENT *pevent, OS_SEM_DATA *pdata)

在應用程序中，用戶隨時可以調(diào)用函數(shù)OSSemQuery()來查詢一個信號量的當前狀態(tài)。該函數(shù)有兩個參數(shù)：一個是指向信號量對應事件控制塊的指針pevent。該指針是在生產(chǎn)信號量時，由OSSemCreate()函數(shù)返回的;另一個是指向用于記錄信號量信息的數(shù)據(jù)結構OS_SEM_DATA(見uCOS_II.H)的指針pdata。因此，調(diào)用該函數(shù)前，用戶必須先定義該結構變量，用于存儲信號量的有關信息。在這里，之所以使用一個新的數(shù)據(jù)結構的原因在于，調(diào)用函數(shù)應該只關心那些和特定信號量有關的信息，而不是象OS_EVENT數(shù)據(jù)結構包含的很全面的信息。該數(shù)據(jù)結構只包含信號量計數(shù)值.OSCnt和等待任務列表.OSEventTbl[]、.OSEventGrp，而OS_EVENT中還包含了另外的兩個域.OSEventType和.OSEventPtr。

4. 時間類API的設計思路和實現(xiàn)機制

μC/OS-Ⅱ(其它內(nèi)核也一樣)要求用戶提供定時中斷來實現(xiàn)延時與超時控制等功能。這個定時中斷叫做時鐘節(jié)拍，它應該每秒發(fā)生10至100次。時鐘節(jié)拍的實際頻率是由用戶的應用程序決定的。時鐘節(jié)拍的頻率越高，系統(tǒng)的負荷就越重。

下面主要講述五個與時鐘節(jié)拍有關的API函數(shù)。

4.1 任務延時函數(shù)，OSTimeDly()

void OSTimeDly (INT16U ticks)

這應該程序員們調(diào)用最多的一個函數(shù)了，這個函數(shù)完成功能很簡單，就是先掛起當起當前任務，然后進行任務切換，在指定的時間到來之后，將當前任務恢復為就緒狀態(tài)，但是并不一定運行，如果恢復后是優(yōu)先級最高就緒任務的話，那么運行之。簡單點說，就是可以任務延時一定時間后再次執(zhí)行它，或者說，暫時放棄CPU的使用權。一個任務可以不顯式的調(diào)用這些可以導致放棄CPU使用權的API，但那樣多任務性能會大大降低，因為此時僅僅依靠時鐘機制在進行任務切換。一個好的任務應該在完成一些操作主動放棄使用權。

4.2 按時分秒延時函數(shù) OSTimeDlyHMSM()

INT8U OSTimeDlyHMSM (INT8U hours, INT8U minutes, INT8U seconds, INT16U milli)

OSTimeDly()雖然是一個非常有用的函數(shù)，但用戶的應用程序需要知道延時時間對應的時鐘節(jié)拍的數(shù)目。增加了OSTimeDlyHMSM()函數(shù)后，用戶就可以按小時(H)、分(M)、秒(S)和毫秒(m)來定義時間了，這樣會顯得更自然些。與OSTimeDly()一樣，調(diào)用OSTimeDlyHMSM()函數(shù)也會使μC/OS-Ⅱ進行一次任務調(diào)度，并且執(zhí)行下一個優(yōu)先級最高的就緒態(tài)任務。任務調(diào)用OSTimeDlyHMSM()后，一旦規(guī)定的時間期滿或者有其它的任務通過調(diào)用OSTimeDlyResume()取消了延時，它就會馬上處于就緒態(tài)。同樣，只有當該任務在所有就緒態(tài)任務中具有最高的優(yōu)先級時，它才會立即運行。

4.3 讓處在延時期的任務結束延時，OSTimeDlyResume()

INT8U OSTimeDlyResume (INT8U prio)

μC/OS-Ⅱ允許用戶結束延時正處于延時期的任務。延時的任務可以不等待延時期滿，而是通過其它任務取消延時來使自己處于就緒態(tài)。這可以通過調(diào)用OSTimeDlyResume()和指定要恢復的任務的優(yōu)先級來完成。實際上，OSTimeDlyResume()也可以喚醒正在等待事件的任務，雖然這一點并沒有提到過。在這種情況下，等待事件發(fā)生的任務會考慮是否終止等待事件。

4.4 系統(tǒng)時間，OSTimeGet()和OSTimeSet()

INT32U OSTimeGet (void)

void OSTimeSet (INT32U ticks)

用戶可以通過調(diào)用OSTimeGet()來獲得該計數(shù)器的當前值。也可以通過調(diào)用OSTimeSet()來改變該計數(shù)器的值。注意，在訪問OSTime的時候中斷是關掉的。這是因為在大多數(shù)8位處理器上增加和拷貝一個32位的數(shù)都需要數(shù)條指令，這些指令一般都需要一次執(zhí)行完畢，而不能被中斷等因素打斷。

5. 臨界區(qū)類API的設計思路和實現(xiàn)機制

和其它內(nèi)核一樣，μC/OS-Ⅱ為了處理臨界段代碼需要關中斷，處理完畢后再開中斷。這使得μC/OS-Ⅱ能夠避免同時有其它任務或中斷服務進入臨界段代碼。

μC/OS-Ⅱ定義兩個宏(macros)來關中斷和開中斷，以便避開不同C編譯器廠商選擇不同的方法來處理關中斷和開中斷。μC/OS-Ⅱ中的這兩個宏調(diào)用分別是：OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()。因為這兩個宏的定義取決于所用的微處理器，故在文件OS_CPU.H中可以找到相應宏定義。每種微處理器都有自己的OS_CPU.H文件。

5.1 OS_ENTER_CRITICAL宏

很多人都以為它是個函數(shù)，其實不然，仔細分析一下OS_CPU.H文件，它和下面馬上要談到的OS_EXIT_CRITICAL都是宏。他們都是涉及特定CPU的實現(xiàn)。一般都被替換為一條或者幾條嵌入式匯編代碼。由于系統(tǒng)希望向上層程序員隱藏內(nèi)部實現(xiàn)，故而一般都宣稱執(zhí)行此條指令后系統(tǒng)進入臨界區(qū)。其實，它就是關個中斷而已。這樣，只要任務不主動放棄CPU使用權，別的任務就沒有占用CPU的機會了，相對這個任務而言，它就是獨占了。所以說進入臨界區(qū)了。這個宏能少用還是少用，因為它會破壞系統(tǒng)的一些服務，尤其是時間服務。并使系統(tǒng)對外界響應性能降低。

5.2 OS_EXIT_CRITICAL宏

這個是和上面介紹的宏配套使用另一個宏，它在系統(tǒng)手冊里的說明是退出臨界區(qū)。其實它就是重新開中斷。需要注意的是，它必須和上面的宏成對出現(xiàn)，否則會帶來意想不到的后果。最壞的情況下，系統(tǒng)會崩潰。我們推薦程序員們盡量少使用這兩個宏調(diào)用，因為他們的確會破壞系統(tǒng)的多任務性能。

6. 結束語

通過對μC/OS-II中這幾類API的簡單分析，我們可以看出μC/OS-II作為一個多任務、搶占式嵌入式操作系統(tǒng)，其API都是為多任務及其多任務之間的調(diào)度和通信的實現(xiàn)來設計的。μC/OS-II提供的API簡潔而靈活，使用戶在設計實際應用時能夠很方便的利用系統(tǒng)提供的各種調(diào)用，充分發(fā)揮μC/OS-II實時、高效的優(yōu)點。