當(dāng)前位置:首頁 > 嵌入式 > 嵌入式教程
[導(dǎo)讀]淺析μC/OS-ⅡAPI的設(shè)計思想及實現(xiàn)機制

任何一個操作系統(tǒng)都會提供大量的API供程序員使用,μC/OS-Ⅱ也不例外。由于μC/OS-Ⅱ面向的是嵌入式開發(fā),并不要求大而全,所以內(nèi)核提供的API也就大多和多任務(wù)息息相關(guān)。本文通過分析μC/OS-Ⅱ中提供的API來引出μC/OS-Ⅱ中API的設(shè)計思路和實現(xiàn)機制。

API全稱ApplicaTION Programming Interface,中文是應(yīng)用程序編程接口的意思。API是操作系統(tǒng)提供給用戶的一組函數(shù),供用戶在編寫應(yīng)用程序時調(diào)用,可以完成應(yīng)用程序?qū)Σ僮飨到y(tǒng)的各種調(diào)用,包括進程調(diào)度、存儲管理、圖形設(shè)備接口及文件管理等。μC/OS-Ⅱ作為一個嵌入式操作系統(tǒng),相對于其他操作系統(tǒng),有很多自己的特色,在設(shè)計思路和實現(xiàn)機制上都和一般操作系統(tǒng)有很大的不同。

1. 簡介

任何一個操作系統(tǒng)都會提供大量的API供程序員使用,μC/OS-Ⅱ也不例外。由于μC/OS-Ⅱ面向的是嵌入式開發(fā),并不要求大而全,所以內(nèi)核提供的API也就大多和多任務(wù)息息相關(guān)。μC/OS-Ⅱ的API主要分以下幾類:(1)任務(wù)類、(2)消息類、(3)同步類、(4)時間類、(5)臨界區(qū)與事件類等。下面分別從這幾類API分析各自的設(shè)計思路和實現(xiàn)機制。

2. 任務(wù)類API的設(shè)計思路和實現(xiàn)機制

μC/OS-Ⅱ可以管理多達64個任務(wù),并從中保留了四個最高優(yōu)先級和四個最低優(yōu)先級的任務(wù)供自己使用,所以用戶可以使用的只有56個任務(wù)。任務(wù)類API包括如何在用戶的應(yīng)用程序中建立任務(wù)、刪除任務(wù)、改變?nèi)蝿?wù)的優(yōu)先級、掛起和恢復(fù)任務(wù),以及獲得有關(guān)任務(wù)的信息等。

2.1 建立任務(wù)API

想讓μC/OS-Ⅱ管理用戶的任務(wù),用戶必須要先建立任務(wù)。用戶可以通過傳遞任務(wù)地址和其它參數(shù)到以下兩個函數(shù)之一來建立任務(wù):OSTaskCreate() 或 OSTaskCreateExt()。

OSTaskCreate()與μC/OS是向下兼容的,OSTaskCreateExt()是OSTaskCreate()的擴展版本,提供了一些附加的功能。用兩個函數(shù)中的任何一個都可以建立任務(wù)。任務(wù)可以在多任務(wù)調(diào)度開始前建立,也可以在其它任務(wù)的執(zhí)行過程中被建立。在開始多任務(wù)調(diào)度(即調(diào)用OSStart())前,用戶必須建立至少一個任務(wù)。任務(wù)不能由中斷服務(wù)程序(ISR)來建立。

OSTaskCreate()的函數(shù)定義如下。從中可以知道,OSTaskCreate()需要四個參數(shù):task是任務(wù)代碼的指針,pdata是當(dāng)任務(wù)開始執(zhí)行時傳遞給任務(wù)的參數(shù)的指針,ptos是分配給任務(wù)的堆棧的棧頂指針,prio是分配給任務(wù)的優(yōu)先級。

INT8U OSTaskCreate (void (*task)(void *pd), void *pdata, OS_STK *ptos, INT8U prio)

用OSTaskCreateExt()函數(shù)來建立任務(wù)會更加靈活,但會增加一些額外的開銷。

OSTaskCreateExt()需要九個參數(shù)!前四個參數(shù)(task,pdata,ptos和prio)與OSTaskCreate()的四個參數(shù)完全相同,連先后順序都一樣。這樣做的目的是為了使用戶能夠更容易地將用戶的程序從OSTaskCreate()移植到OSTaskCreateExt()上去。函數(shù)的定義如下:

INT8U OSTaskCreateExt (void (*task)(void *pd),

void *pdata,

OS_STK *ptos,

INT8U prio,

INT16U id,

OS_STK *pbos,

INT32U stk_size,

void *pext,

INT16U opt)

2.2 刪除任務(wù)API

有時候刪除任務(wù)是很有必要的。刪除任務(wù),是說任務(wù)將返回并處于休眠狀態(tài),并不是說任務(wù)的代碼被刪除了,只是任務(wù)的代碼不再被μC/OS-Ⅱ調(diào)用。通過調(diào)用OSTaskDel()就可以完成刪除任務(wù)的功能。OSTaskDel()一開始應(yīng)確保用戶所要刪除的任務(wù)并非是空閑任務(wù),因為刪除空閑任務(wù)是不允許的。不過,用戶可以刪除statistic任務(wù)。接著,OSTaskDel()還應(yīng)確保用戶不是在ISR例程中去試圖刪除一個任務(wù),因為這也是不被允許的。調(diào)用此函數(shù)的任務(wù)可以通過指定OS_PRIO_SELF參數(shù)來刪除自己。接下來OSTaskDel()會保證被刪除的任務(wù)是確實存在的。該函數(shù)的入口參數(shù)很簡單,只需要知道要刪除任務(wù)的優(yōu)先級即可。

INT8U OSTaskDel (INT8U prio)

2.3 改變?nèi)蝿?wù)優(yōu)先級API

在用戶建立任務(wù)的時候會分配給任務(wù)一個優(yōu)先級。在程序運行期間,用戶可以通過調(diào)用OSTaskChangePrio()來改變?nèi)蝿?wù)的優(yōu)先級。換句話說,就是μC/OS-Ⅱ允許用戶動態(tài)的改變?nèi)蝿?wù)的優(yōu)先級。函數(shù)定義如下:

INT8U OSTaskChangePrio (INT8U oldprio, INT8U newprio)

用戶不能改變空閑任務(wù)的優(yōu)先級,但用戶可以改變調(diào)用本函數(shù)的任務(wù)或者其它任務(wù)的優(yōu)先級。為了改變調(diào)用本函數(shù)的任務(wù)的優(yōu)先級,用戶可以指定該任務(wù)當(dāng)前的優(yōu)先級或OS_PRIO_SELF,OSTaskChangePrio()會決定該任務(wù)的優(yōu)先級。用戶還必須指定任務(wù)的新(即想要的)優(yōu)先級。因為μC/OS-Ⅱ不允許多個任務(wù)具有相同的優(yōu)先級,所以O(shè)STaskChangePrio()需要檢驗新優(yōu)先級是否是合法的(即不存在具有新優(yōu)先級的任務(wù))。如果新優(yōu)先級是合法的,μC/OS-Ⅱ通過將某些東西儲存到OSTCBPrioTbl[newprio]中保留這個優(yōu)先級。如此就使得OSTaskChangePrio()可以重新允許中斷,因為此時其它任務(wù)已經(jīng)不可能建立擁有該優(yōu)先級的任務(wù),也不能通過指定相同的新優(yōu)先級來調(diào)用OSTaskChangePrio()。接下來OSTaskChangePrio()可以預(yù)先計算新優(yōu)先級任務(wù)的OS_TCB中的某些值。而這些值用來將任務(wù)放入就緒表或從該表中移除。

2.4 掛起任務(wù)和恢復(fù)任務(wù)API

有時候?qū)⑷蝿?wù)掛起是很有用的。掛起任務(wù)可通過調(diào)用OSTaskSuspend()函數(shù)來完成。被掛起的任務(wù)只能通過調(diào)用OSTaskResume()函數(shù)來恢復(fù)。任務(wù)掛起是一個附加功能。也就是說,如果任務(wù)在被掛起的同時也在等待延時的期滿,那么,掛起操作需要被取消,而任務(wù)繼續(xù)等待延時期滿,并轉(zhuǎn)入就緒狀態(tài)。任務(wù)可以掛起自己或者其它任務(wù)。

OSTaskSuspend()函數(shù)的函數(shù)定義如下:

INT8U OSTaskSuspend (INT8U prio)

恢復(fù)任務(wù)OSTaskResume()函數(shù)定義為:

INT8U OSTaskResume (INT8U prio)

被掛起的任務(wù)只有通過調(diào)用OSTaskResume()才能恢復(fù)。因為OSTaskSuspend()不能掛起空閑任務(wù),所以必須得確認用戶的應(yīng)用程序不是在恢復(fù)空閑任務(wù)。注意,這個測試也可以確保用戶不是在恢復(fù)優(yōu)先級為OS_PRIO_SELF的任務(wù)(OS_PRIO_SELF被定義為0xFF,它總是比OS_LOWEST_PRIO大)。

2.5 獲得任務(wù)信息API

用戶的應(yīng)用程序可以通過調(diào)用OSTaskQuery()來獲得自身或其它應(yīng)用任務(wù)的信息。實際上,OSTaskQuery()獲得的是對應(yīng)任務(wù)的OS_TCB中內(nèi)容的拷貝。用戶能訪問的OS_TCB的數(shù)據(jù)域的多少決定于用戶的應(yīng)用程序的配置(參看OS_CFG.H)。由于μC/OS-Ⅱ是可裁剪的,它只包括那些用戶的應(yīng)用程序所要求的屬性和功能。[!--empirenews.page--]

void MyTask (void *pdata)

函數(shù)參數(shù)為一指針變量,指向?qū)?yīng)任務(wù)的OS_TCB結(jié)構(gòu)地址。本函數(shù)是有用的調(diào)試工具。

3. 消息和同步類API的設(shè)計思路和實現(xiàn)機制

μC/OS-Ⅱ中有三種方法實現(xiàn)消息通信和同步:信號量、郵箱和消息隊列。一個任務(wù)或者中斷服務(wù)子程序可以通過事件控制塊ECB(Event Control Blocks)來向另外的任務(wù)發(fā)信號。這里,所有的信號都被看成是事件(Event)。這也說明為什么上面把用于通訊的數(shù)據(jù)結(jié)構(gòu)叫做事件控制塊。一個任務(wù)還可以等待另一個任務(wù)或中斷服務(wù)子程序給它發(fā)送信號。這里要注意的是,只有任務(wù)可以等待事件發(fā)生,中斷服務(wù)子程序是不能這樣做的。對于處于等待狀態(tài)的任務(wù),還可以給它指定一個最長等待時間,以此來防止因為等待的事件沒有發(fā)生而無限期地等下去。多個任務(wù)可以同時等待同一個事件的發(fā)生。在這種情況下,當(dāng)該事件發(fā)生后,所有等待該事件的任務(wù)中,優(yōu)先級最高的任務(wù)得到了該事件并進入就緒狀態(tài),準(zhǔn)備執(zhí)行。上面講到的事件,可以是信號量、郵箱或者消息隊列等。當(dāng)事件控制塊是一個信號量時,任務(wù)可以等待它,也可以給它發(fā)送消息。

μC/OS-II中的信號量由兩部分組成:一個是信號量的計數(shù)值,它是一個16位的無符號整數(shù)(0 到65,535之間);另一個是由等待該信號量的任務(wù)組成的等待任務(wù)表。用戶要在OS_CFG.H中將OS_SEM_EN開關(guān)量常數(shù)置成1,這樣μC/OS-II才能支持信號量。

郵箱是μC/OS-II中另一種通訊機制,它可以使一個任務(wù)或者中斷服務(wù)子程序向另一個任務(wù)發(fā)送一個指針型的變量。該指針指向一個包含了特定“消息”的數(shù)據(jù)結(jié)構(gòu)。為了在μC/OS-II中使用郵箱,必須將OS_CFG.H中的OS_MBOX_EN常數(shù)置為1。

消息隊列是μC/OS-II中另一種通訊機制,它可以使一個任務(wù)或者中斷服務(wù)子程序向另一個任務(wù)發(fā)送以指針方式定義的變量。因具體的應(yīng)用有所不同,每個指針指向的數(shù)據(jù)結(jié)構(gòu)變量也有所不同。為了使用μC/OS-II的消息隊列功能,需要在OS_CFG.H 文件中,將OS_Q_EN常數(shù)設(shè)置為1,并且通過常數(shù)OS_MAX_QS來決定μC/OS-II支持的最多消息隊列數(shù)。

μC/OS-Ⅱ提供一系列API函數(shù)供用戶調(diào)用,實現(xiàn)各個任務(wù)之間的通信和同步功能。下面以信號量為例說明各個API的實現(xiàn)。

μC/OS-II提供了5個對信號量進行操作的函數(shù)。它們是:OSSemCreate(),OSSemPend(),OSSemPost(),OSSemAccept()和OSSemQuery()函數(shù)。圖 F6.5說明了任務(wù)、中斷服務(wù)子程序和信號量之間的關(guān)系。圖中用鑰匙或者旗幟的符號來表示信號量:如果信號量用于對共享資源的訪問,那么信號量就用鑰匙符號。符號旁邊的數(shù)字N代表可用資源數(shù)。對于二值信號量,該值就是1;如果信號量用于表示某事件的發(fā)生,那么就用旗幟符號。這時的數(shù)字N代表事件已經(jīng)發(fā)生的次數(shù)。從圖 F6.5中可以看出OSSemPost()函數(shù)可以由任務(wù)或者中斷服務(wù)子程序調(diào)用,而OSSemPend()和OSSemQuery()函數(shù)只能有任務(wù)程序調(diào)用。

3.1建立一個信號量, OSSemCreate()

OS_EVENT *OSSemCreate (INT16U cnt)

函數(shù)參數(shù)傳遞的是要創(chuàng)建的信號量的初始值,在函數(shù)內(nèi)部對任務(wù)控制塊進行初始化。OSSemCreate()返回給調(diào)用函數(shù)一個指向任務(wù)控制塊的指針。以后對信號量的所有操作,如OSSemPend(), OSSemPost(), OSSemAccept()和OSSemQuery()都是通過該指針完成的。因此,這個指針實際上就是該信號量的句柄。如果系統(tǒng)中沒有可用的任務(wù)控制塊,OSSemCreate()將返回一個NULL指針。

值得注意的是,在μC/OS-II中,信號量一旦建立就不能刪除了,因此也就不可能將一個已分配的任務(wù)控制塊再放回到空閑ECB鏈表中。如果有任務(wù)正在等待某個信號量,或者某任務(wù)的運行依賴于某信號量的出現(xiàn)時,刪除該任務(wù)是很危險的。

3.2等待一個信號量, OSSemPend()

void OSSemPend (OS_EVENT *pevent, INT16U timeout, INT8U *err)

它首先檢查指針pevent所指的任務(wù)控制塊是否是由OSSemCreate()建立的。如果信號量當(dāng)前是可用的(信號量的計數(shù)值大于0),將信號量的計數(shù)值減1,然后函數(shù)將“無錯”錯誤代碼返回給它的調(diào)用函數(shù)。顯然,如果正在等待信號量,這時的輸出正是我們所希望的,也是運行OSSemPend()函數(shù)最快的路徑。

3.3發(fā)送一個信號量, OSSemPost()

INT8U OSSemPost (OS_EVENT *pevent)

它首先檢查參數(shù)指針pevent指向的任務(wù)控制塊是否是OSSemCreate()函數(shù)建立的,接著檢查是否有任務(wù)在等待該信號量。如果該任務(wù)控制塊中的.OSEventGrp域不是0,說明有任務(wù)正在等待該信號量。這時,就要調(diào)用函數(shù)OSEventTaskRdy(),使一個任務(wù)進入就緒狀態(tài),把其中的最高優(yōu)先級任務(wù)從等待任務(wù)列表中刪除并使它進入就緒狀態(tài)。然后,調(diào)用OSSched()任務(wù)調(diào)度函數(shù)檢查該任務(wù)是否是系統(tǒng)中的最高優(yōu)先級的就緒任務(wù)。如果是,這時就要進行任務(wù)切換[當(dāng)OSSemPost()函數(shù)是在任務(wù)中調(diào)用的],準(zhǔn)備執(zhí)行該就緒任務(wù)。如果不是,OSSched()直接返回,調(diào)用OSSemPost()的任務(wù)得以繼續(xù)執(zhí)行。如果這時沒有任務(wù)在等待該信號量,該信號量的計數(shù)值就簡單地加1。

上面是由任務(wù)調(diào)用OSSemPost()時的情況。當(dāng)中斷服務(wù)子程序調(diào)用該函數(shù)時,不會發(fā)生上面的任務(wù)切換。如果需要,任務(wù)切換要等到中斷嵌套的最外層中斷服務(wù)子程序調(diào)用OSIntExit()函數(shù)后才能進行。

3.4無等待地請求一個信號量, OSSemAccept()

INT16U OSSemAccept (OS_EVENT *pevent)

當(dāng)一個任務(wù)請求一個信號量時,如果該信號量暫時無效,也可以讓該任務(wù)簡單地返回,而不是進入睡眠等待狀態(tài)。這種情況下的操作是由OSSemAccept()函數(shù)完成的。該函數(shù)在最開始也是檢查參數(shù)指針pevent指向的事件控制塊是否是由OSSemCreate()函數(shù)建立的,接著從該信號量的事件控制塊中取出當(dāng)前計數(shù)值,并檢查該信號量是否有效(計數(shù)值是否為非0值)。如果有效,則將信號量的計數(shù)值減1,然后將信號量的原有計數(shù)值返回給調(diào)用函數(shù)。調(diào)用函數(shù)需要對該返回值進行檢查。如果該值是0,說明該信號量無效。如果該值大于0,說明該信號量有效,同時該值也暗示著該信號量當(dāng)前可用的資源數(shù)。應(yīng)該注意的是,這些可用資源中,已經(jīng)被該調(diào)用函數(shù)自身占用了一個(該計數(shù)值已經(jīng)被減1)。中斷服務(wù)子程序要請求信號量時,只能用OSSemAccept()而不能用OSSemPend(),因為中斷服務(wù)子程序是不允許等待的。[!--empirenews.page--]

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

INT8U OSSemQuery (OS_EVENT *pevent, OS_SEM_DATA *pdata)

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

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

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

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

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

void OSTimeDly (INT16U ticks)

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

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

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

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

4.3 讓處在延時期的任務(wù)結(jié)束延時,OSTimeDlyResume()

INT8U OSTimeDlyResume (INT8U prio)

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

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

INT32U OSTimeGet (void)

void OSTimeSet (INT32U ticks)

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

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

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

μC/OS-Ⅱ定義兩個宏(macros)來關(guān)中斷和開中斷,以便避開不同C編譯器廠商選擇不同的方法來處理關(guān)中斷和開中斷。μC/OS-Ⅱ中的這兩個宏調(diào)用分別是:OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()。因為這兩個宏的定義取決于所用的微處理器,故在文件OS_CPU.H中可以找到相應(yīng)宏定義。每種微處理器都有自己的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ū)。其實,它就是關(guān)個中斷而已。這樣,只要任務(wù)不主動放棄CPU使用權(quán),別的任務(wù)就沒有占用CPU的機會了,相對這個任務(wù)而言,它就是獨占了。所以說進入臨界區(qū)了。這個宏能少用還是少用,因為它會破壞系統(tǒng)的一些服務(wù),尤其是時間服務(wù)。并使系統(tǒng)對外界響應(yīng)性能降低。

5.2 OS_EXIT_CRITICAL宏

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

6. 結(jié)束語

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

本站聲明: 本文章由作者或相關(guān)機構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險,如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學(xué)會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉