資料介紹
1 引言
uC/OS-II是著名的源碼公開的實時內核[1],是專為嵌入式應用設計的,可用于各類8位16位和32位單片機或DSP?,F(xiàn)在有很多使用者正在或已經(jīng)將其移植到各種類型的芯片。因為源碼公開,uC/OS-II也經(jīng)常被作為嵌入式實時內核的教材,為專業(yè)人員提供了學習實時內核的難得機會。在實際使用中不管基于何種操作系統(tǒng)平臺,應用程序經(jīng)常會等待一些系統(tǒng)資源,如信號量,事件標志,消息等。等待類型共有三種:(1)如果不能馬上獲取,懸掛等待;(2)不管是否能獲取資源,馬上返回,不會等待;(3) 如果不能馬上獲取資源,將進行有限時間的等待,即超時等待。
2 超時等待機制的基本原理
應用程序通過操作系統(tǒng)提供的系統(tǒng)調用接口獲取資源時,在系統(tǒng)調用的入口參數(shù)里可以指定超時等待的最大時間,通常以毫秒為單位,內核會將其轉化為系統(tǒng)的時鐘滴嗒數(shù)(tick)。一般內核都會執(zhí)行以下流程:
(1)如果資源能馬上獲取,系統(tǒng)調用將成功返回。
(2)如果資源不能馬上獲取,內核將設置一定時器進行計時,把當前任務懸掛在該資源的等待隊列上,該任務從就緒表中刪除,并進行調度,讓出CPU的使用權。
?。?)如果在指定的時間內資源變得可以獲取了,定時器應馬上停止計時,該任務從等待隊列里摘下并且重新回到就緒表中等候調度。
?。?)如果定時器到時,任務應該從等待隊列里摘下并且重新回到就緒表中,系統(tǒng)調用返回超時信息。
內核在每一個tick都會做一系列的工作,包括任務的延遲以及超時等待資源的定時器等相關的檢查操作。一般來講,在指定的時間間隔以外到達的資源和信號被認為是無效的,這也是指定超時時間間隔的原意所在,有些對時間要求苛刻的場合就有這種需求,內核必須處理好這方面的問題。
3 uC/OS-II內核超時等待機制的分析
假設某任務T超時等待信號量資源R,先來分析時鐘節(jié)拍函數(shù)的源代碼。
void OSTimeTick(void)
{
OS_TCB *ptcb;
OSTimeTickHook();
ptcb=OSTCBList;
while(ptcb-》OSTCBPrio!=OS_IDLE_PRIO){
OS_ENTER_CRITICAL();
if(ptcb-》OSTCBDly!=0){
if(--ptcb-》OSTCBDly==0){
if(?。╬tcb-》OSTCBStat&OS_STAT_SUSPEND)){//(1)
OSRdyGrp|=ptcb-》OSTCBBity; //(2)
OSRdyTbl[ptcb-》OSTCBY]|=ptcb-》OSTCBBitX;//(3)
}else {
ptcb-》OSTCBDly=1;
}
}
}
ptcb=ptcb-》OSTCBNext;
OS_EXIT_CRITICAL();
}
OS_ENTER_CRITICAL();
OSTime++;
OS_EXIT_CRITICAL();
}
語句(1),(2),(3)表明:時鐘中斷服務程序在每一個時鐘中斷在需要的情況下對任務的延遲項進行減1操作,如果任務T的定時時間間隔到期(延遲項被減為0),并且任務T沒有附加的掛起操作,任務T就會進入就緒表,然而該函數(shù)卻沒有進一步將任務T移出資源R的等待隊列,也就是說此時任務T跨了兩個狀態(tài),這兩個狀態(tài)從本質上講是矛盾的。雖然任務T此時處于就緒狀態(tài),但未必馬上就能獲得執(zhí)行權,這取決于任務T的優(yōu)先級。在任務T沒有被調度執(zhí)行之前的這段時間內,假設資源R到達了,比如一個中斷服務程序調用了OSSemPost函數(shù),會是什么情況呢?我們再來分析OSSemPost函數(shù)。
void OSSemPost(OS_EVENT *pevent)
{
OS_ENTER_CRITICAL();
if(pevent-》OSEventGrp!=0x00){
OS_EventTaskRdy(pevent,(void*)0,OS_STAT_SEM);//(4)
OS_EXIT_CRITICAL();
OS_Sched();
return(OS_NO_ERR);
}
if(pevent-》OSEventCnt《65535){
pevent-》OSEventCnt++;
OS_EXIT_CRITICAL();
return(OS_NO_ERR);
}
OS_EXIT_CRITICAL();
return(OS_SEM_OVF);
}
}
從語句(4)可以看出,在資源R的等待列表中有等待任務的情況下,等待表中最高優(yōu)先級的任務將從等待列表中刪除,并且進入就緒表。如果等待表中的最高優(yōu)先級任務就是前面講的等待超時的任務T,這相當于任務T又一次進入就緒表,不過只有一次從等待表中刪除。任務T獲取到了資源,只不過是在超時時間以外獲取到的。任務T獲得執(zhí)行權以后從調度程序返回將運行函數(shù)OSSemPend()語句(6)處的條件代碼,此時語句(5)處的條件不成立,任務按獲取到資源對待。
void OSSemPend(OS_EVENT *pevent,INT16U timeout,INT8U *err)
{
OS_ENTER_CRITICAL();
if(pevent-》OSEventType!=OS_EVENT_TYPE_SEM){
OS_EXIT_CRITICAL();
*err=OS_ERR_EVENT_TYPE;
}
if(pevent-》OSEventCnt》0){
pevent-》OSEventCnt--;
OS_EXIT_CRITICAL();
*err=OS_NO_ERR;
}else if(OSIntNesting》0){
OS_EXIT_CRITICAL();
*err=OS_ERR_PEND_ISR;
}else{
OSTCBCur-》OSTCBStat|=OS_STAT_SEM;
OSTCBCur-》OSTCBDly=timeout;
OSEventTaskWait(pevent);
OS_EXIT_CRITICAL();
OSSched();
OS_ENTER_CRITICAL();
if(OSTCBCur-》OSTCBStat&OS_STAT_SEM){ //(5)
OSEventTo(pevent);
OS_EXIT_CRITICAL();
*err=OS_TIMEOUT;
}else{ //(6)
OSTCBCur-》OSTCBEventPtr=(OS_EVENT*0);
OS_EXIT_CRITICAL();
*err=OS_NO_ERR;
}
}
}
void OSEventTo(OS_EVENT *pevent)
{
if((pevent-》OSEventTbl[OSTCBCur-》OSTCBY]&=~OSTCBCur-》OSTCBBitX)==0)
{
pevent-》OSEventGrp&=~OSTCBBitY;
}
OSTCBCur-》OSTCBStat=OS_STAT_RDY;
v OSTCBCur-》OSTCBEventPtr=(OS_EVENT*0);}
如果任務T由于超時進入就緒態(tài),到T獲得執(zhí)行權之前,仍沒有獲取到資源R,將運行語句(5)處的條件代碼,由函數(shù)OSEventTo()可以看出,此時任務T才被從等待表中刪除,最后返回超時狀態(tài)。
通過分析開放源碼的nucleus內核,發(fā)現(xiàn)nucleus在超時到期時執(zhí)行定時器的一個回調函數(shù),此回調函數(shù)馬上將等待任務從等待鏈表中刪除,將返回狀態(tài)定性為超時。這樣在任務獲得執(zhí)行權前,即使資源到達,該任務也不會得到。這樣一來,uC/OS-II內核只要在時鐘節(jié)拍函數(shù)里增加代碼將延時期滿的任務從相應的資源等待列表中刪除即可。這一工作很容易實現(xiàn),內核任務控制塊有指向所等待的信號量,消息等事件控制塊的指針,事件控制塊里有相應的等待表。對于uC/OS-II新引進的事件標志組[2],任務控制塊有指向相應的等待節(jié)點的指針,等待節(jié)點有指向相應的事件標志組控制塊的指針,刪除一個等待節(jié)點也能實現(xiàn)。
4 結論
uC/OS-II其它資源的等待機制,比如消息以及包括2.5.2版引入的事件標志組的實現(xiàn)都存在上述的超時時間不嚴格的問題,這是由中斷節(jié)拍函數(shù)OSTimeTick()決定的,該函數(shù)只負責將任務移入就緒表,而不處理相應的等待表。
參考文獻:
?。?]Labrosse Jean J.uc/OS-II-源碼公開的實時嵌入式操作系統(tǒng)[M]。北京:中國電力出版社,2001.
?。?]Labrosse Jean J. 嵌入式實時操作系統(tǒng)uc/OS-II[M]。北京:北京航空航天大學出版社,2003.
uC/OS-II是著名的源碼公開的實時內核[1],是專為嵌入式應用設計的,可用于各類8位16位和32位單片機或DSP?,F(xiàn)在有很多使用者正在或已經(jīng)將其移植到各種類型的芯片。因為源碼公開,uC/OS-II也經(jīng)常被作為嵌入式實時內核的教材,為專業(yè)人員提供了學習實時內核的難得機會。在實際使用中不管基于何種操作系統(tǒng)平臺,應用程序經(jīng)常會等待一些系統(tǒng)資源,如信號量,事件標志,消息等。等待類型共有三種:(1)如果不能馬上獲取,懸掛等待;(2)不管是否能獲取資源,馬上返回,不會等待;(3) 如果不能馬上獲取資源,將進行有限時間的等待,即超時等待。
2 超時等待機制的基本原理
應用程序通過操作系統(tǒng)提供的系統(tǒng)調用接口獲取資源時,在系統(tǒng)調用的入口參數(shù)里可以指定超時等待的最大時間,通常以毫秒為單位,內核會將其轉化為系統(tǒng)的時鐘滴嗒數(shù)(tick)。一般內核都會執(zhí)行以下流程:
(1)如果資源能馬上獲取,系統(tǒng)調用將成功返回。
(2)如果資源不能馬上獲取,內核將設置一定時器進行計時,把當前任務懸掛在該資源的等待隊列上,該任務從就緒表中刪除,并進行調度,讓出CPU的使用權。
?。?)如果在指定的時間內資源變得可以獲取了,定時器應馬上停止計時,該任務從等待隊列里摘下并且重新回到就緒表中等候調度。
?。?)如果定時器到時,任務應該從等待隊列里摘下并且重新回到就緒表中,系統(tǒng)調用返回超時信息。
內核在每一個tick都會做一系列的工作,包括任務的延遲以及超時等待資源的定時器等相關的檢查操作。一般來講,在指定的時間間隔以外到達的資源和信號被認為是無效的,這也是指定超時時間間隔的原意所在,有些對時間要求苛刻的場合就有這種需求,內核必須處理好這方面的問題。
3 uC/OS-II內核超時等待機制的分析
假設某任務T超時等待信號量資源R,先來分析時鐘節(jié)拍函數(shù)的源代碼。
void OSTimeTick(void)
{
OS_TCB *ptcb;
OSTimeTickHook();
ptcb=OSTCBList;
while(ptcb-》OSTCBPrio!=OS_IDLE_PRIO){
OS_ENTER_CRITICAL();
if(ptcb-》OSTCBDly!=0){
if(--ptcb-》OSTCBDly==0){
if(?。╬tcb-》OSTCBStat&OS_STAT_SUSPEND)){//(1)
OSRdyGrp|=ptcb-》OSTCBBity; //(2)
OSRdyTbl[ptcb-》OSTCBY]|=ptcb-》OSTCBBitX;//(3)
}else {
ptcb-》OSTCBDly=1;
}
}
}
ptcb=ptcb-》OSTCBNext;
OS_EXIT_CRITICAL();
}
OS_ENTER_CRITICAL();
OSTime++;
OS_EXIT_CRITICAL();
}
語句(1),(2),(3)表明:時鐘中斷服務程序在每一個時鐘中斷在需要的情況下對任務的延遲項進行減1操作,如果任務T的定時時間間隔到期(延遲項被減為0),并且任務T沒有附加的掛起操作,任務T就會進入就緒表,然而該函數(shù)卻沒有進一步將任務T移出資源R的等待隊列,也就是說此時任務T跨了兩個狀態(tài),這兩個狀態(tài)從本質上講是矛盾的。雖然任務T此時處于就緒狀態(tài),但未必馬上就能獲得執(zhí)行權,這取決于任務T的優(yōu)先級。在任務T沒有被調度執(zhí)行之前的這段時間內,假設資源R到達了,比如一個中斷服務程序調用了OSSemPost函數(shù),會是什么情況呢?我們再來分析OSSemPost函數(shù)。
void OSSemPost(OS_EVENT *pevent)
{
OS_ENTER_CRITICAL();
if(pevent-》OSEventGrp!=0x00){
OS_EventTaskRdy(pevent,(void*)0,OS_STAT_SEM);//(4)
OS_EXIT_CRITICAL();
OS_Sched();
return(OS_NO_ERR);
}
if(pevent-》OSEventCnt《65535){
pevent-》OSEventCnt++;
OS_EXIT_CRITICAL();
return(OS_NO_ERR);
}
OS_EXIT_CRITICAL();
return(OS_SEM_OVF);
}
}
從語句(4)可以看出,在資源R的等待列表中有等待任務的情況下,等待表中最高優(yōu)先級的任務將從等待列表中刪除,并且進入就緒表。如果等待表中的最高優(yōu)先級任務就是前面講的等待超時的任務T,這相當于任務T又一次進入就緒表,不過只有一次從等待表中刪除。任務T獲取到了資源,只不過是在超時時間以外獲取到的。任務T獲得執(zhí)行權以后從調度程序返回將運行函數(shù)OSSemPend()語句(6)處的條件代碼,此時語句(5)處的條件不成立,任務按獲取到資源對待。
void OSSemPend(OS_EVENT *pevent,INT16U timeout,INT8U *err)
{
OS_ENTER_CRITICAL();
if(pevent-》OSEventType!=OS_EVENT_TYPE_SEM){
OS_EXIT_CRITICAL();
*err=OS_ERR_EVENT_TYPE;
}
if(pevent-》OSEventCnt》0){
pevent-》OSEventCnt--;
OS_EXIT_CRITICAL();
*err=OS_NO_ERR;
}else if(OSIntNesting》0){
OS_EXIT_CRITICAL();
*err=OS_ERR_PEND_ISR;
}else{
OSTCBCur-》OSTCBStat|=OS_STAT_SEM;
OSTCBCur-》OSTCBDly=timeout;
OSEventTaskWait(pevent);
OS_EXIT_CRITICAL();
OSSched();
OS_ENTER_CRITICAL();
if(OSTCBCur-》OSTCBStat&OS_STAT_SEM){ //(5)
OSEventTo(pevent);
OS_EXIT_CRITICAL();
*err=OS_TIMEOUT;
}else{ //(6)
OSTCBCur-》OSTCBEventPtr=(OS_EVENT*0);
OS_EXIT_CRITICAL();
*err=OS_NO_ERR;
}
}
}
void OSEventTo(OS_EVENT *pevent)
{
if((pevent-》OSEventTbl[OSTCBCur-》OSTCBY]&=~OSTCBCur-》OSTCBBitX)==0)
{
pevent-》OSEventGrp&=~OSTCBBitY;
}
OSTCBCur-》OSTCBStat=OS_STAT_RDY;
v OSTCBCur-》OSTCBEventPtr=(OS_EVENT*0);}
如果任務T由于超時進入就緒態(tài),到T獲得執(zhí)行權之前,仍沒有獲取到資源R,將運行語句(5)處的條件代碼,由函數(shù)OSEventTo()可以看出,此時任務T才被從等待表中刪除,最后返回超時狀態(tài)。
通過分析開放源碼的nucleus內核,發(fā)現(xiàn)nucleus在超時到期時執(zhí)行定時器的一個回調函數(shù),此回調函數(shù)馬上將等待任務從等待鏈表中刪除,將返回狀態(tài)定性為超時。這樣在任務獲得執(zhí)行權前,即使資源到達,該任務也不會得到。這樣一來,uC/OS-II內核只要在時鐘節(jié)拍函數(shù)里增加代碼將延時期滿的任務從相應的資源等待列表中刪除即可。這一工作很容易實現(xiàn),內核任務控制塊有指向所等待的信號量,消息等事件控制塊的指針,事件控制塊里有相應的等待表。對于uC/OS-II新引進的事件標志組[2],任務控制塊有指向相應的等待節(jié)點的指針,等待節(jié)點有指向相應的事件標志組控制塊的指針,刪除一個等待節(jié)點也能實現(xiàn)。
4 結論
uC/OS-II其它資源的等待機制,比如消息以及包括2.5.2版引入的事件標志組的實現(xiàn)都存在上述的超時時間不嚴格的問題,這是由中斷節(jié)拍函數(shù)OSTimeTick()決定的,該函數(shù)只負責將任務移入就緒表,而不處理相應的等待表。
參考文獻:
?。?]Labrosse Jean J.uc/OS-II-源碼公開的實時嵌入式操作系統(tǒng)[M]。北京:中國電力出版社,2001.
?。?]Labrosse Jean J. 嵌入式實時操作系統(tǒng)uc/OS-II[M]。北京:北京航空航天大學出版社,2003.
下載該資料的人也在下載
下載該資料的人還在閱讀
更多 >
- 基于STM32F103C8T6+uC/OS-II的例程筆記(二)
- 【嵌入式系統(tǒng)—實時操作系統(tǒng)】uC/OS-II 及其STM32F103移植
- 提高uc/os-ii操作系統(tǒng)安全與穩(wěn)定性的方法 0次下載
- uC/OS-II 應用程序基本結構及重要的API介紹 2次下載
- 嵌入式實時操作系統(tǒng)uC/OS-II內核_英版 0次下載
- 基于UC_OS-II的腹腔灌注熱化療儀的優(yōu)化設計
- uc-os-II入門學習 165次下載
- 基于MCF5213和uC/OS-II的低成本Zigbee無線
- uc/os-ii在ARM處理器上的移植
- 基于uc/os-ii 的嵌入式GUI研究與應用
- 基于uC/OS-II的齒輪流量計二次儀表的設計
- 編寫μC OS-II 實時內核下的串行驅動
- μC/OS-II 任務調度機制的改進
- 基于μC/OS-II的嵌入式音頻系統(tǒng)設計
- The uC/OS-II port for Keil C V
- 基于實時嵌入式操作系統(tǒng)mC/OS-II實現(xiàn)GPRS終端系統(tǒng)的設計 2252次閱讀
- 基于MC9S12DP256芯片和μC/OS-II實現(xiàn)CCP軟件的設計 2685次閱讀
- 基于嵌入式工控模塊和μC/OS-II實現(xiàn)車載狀態(tài)監(jiān)控系統(tǒng)的設計 1907次閱讀
- 基于μC/OS-II操作系統(tǒng)實現(xiàn)在P89V51RD2微控制器上運行 747次閱讀
- 基于μC/OS-II操作系統(tǒng)在SPCE061A上的移植優(yōu)化研研究 779次閱讀
- 基于μC/OS-II嵌入式系統(tǒng)開發(fā)中低功耗系統(tǒng)的設計 2984次閱讀
- 51單片機對μC/OS-II實時操作系統(tǒng)的移植 2385次閱讀
- LPC213X通過μC/OS-II的多種移植方案 621次閱讀
- 淺論uC/OS-II 在電動車電池管理系統(tǒng)中的應用研究 1313次閱讀
- μC/OS-II系統(tǒng)基礎嵌入式開發(fā)編程教程 4370次閱讀
- LPC2119簡介 μC/OS-II在LPC2119上的移植 2705次閱讀
- 車輛調度系統(tǒng)的整體設計 UC/OS-II的內核調度機理 1116次閱讀
- 嵌入式設備設計的內核uc/os-ii api使用手冊大全 4213次閱讀
- uC/OS-III的特點 2090次閱讀
- 用AndesCore N1033A-S處理器實現(xiàn)μC/OS-II的移植 3969次閱讀
下載排行
本周
- 1純電動汽?的主要部件及?作原理
- 5.76 MB | 11次下載 | 5 積分
- 2明偉電源模塊RSP-3000圖紙
- 0.30 MB | 5次下載 | 免費
- 3無鉛焊接的可靠性
- 1.03 MB | 5次下載 | 1 積分
- 4800VA純正弦波逆變器的參考設計
- 2.96MB | 4次下載 | 免費
- 5PT500齒輪傳動動力學綜合測試實驗臺
- 0.16 MB | 3次下載 | 免費
- 6GBT1094.11-2022電力變壓器第11部分:干式變壓器
- 14.12 MB | 2次下載 | 免費
- 7爬電距離和電氣間隙計算
- 0.75 MB | 2次下載 | 1 積分
- 8卓顯-體視顯微鏡-ZEX-075M
- 1.89 MB | 1次下載 | 免費
本月
- 1ACDC變換器的原理圖免費下載
- 0.26 MB | 65次下載 | 免費
- 2無刷電機控制方案設計合作
- 1.05 MB | 22次下載 | 免費
- 3美的超薄電磁爐TM-S1-09B主板原理圖
- 0.08 MB | 20次下載 | 免費
- 4純電動汽?的主要部件及?作原理
- 5.76 MB | 11次下載 | 5 積分
- 5GP328和GP88S對講機的維修實列資料合集免費下載
- 0.03 MB | 10次下載 | 10 積分
- 6舒爾SLX4無線話筒接收機原理圖:二次變頻超外差部分
- 0.27 MB | 8次下載 | 免費
- 7IP5385_DEMO開發(fā)資料
- 1.96 MB | 7次下載 | 2 積分
- 8i.MX Linux開發(fā)實戰(zhàn)指南—基于野火i.MX系列開發(fā)板
- 17.86 MB | 6次下載 | 免費
總榜
- 1matlab軟件下載入口
- 未知 | 935115次下載 | 10 積分
- 2開源硬件-PMP21529.1-4 開關降壓/升壓雙向直流/直流轉換器 PCB layout 設計
- 1.48MB | 420061次下載 | 10 積分
- 3Altium DXP2002下載入口
- 未知 | 233084次下載 | 10 積分
- 4電路仿真軟件multisim 10.0免費下載
- 340992 | 191363次下載 | 10 積分
- 5十天學會AVR單片機與C語言視頻教程 下載
- 158M | 183329次下載 | 10 積分
- 6labview8.5下載
- 未知 | 81580次下載 | 10 積分
- 7Keil工具MDK-Arm免費下載
- 0.02 MB | 73805次下載 | 10 積分
- 8LabVIEW 8.6下載
- 未知 | 65985次下載 | 10 積分
評論
查看更多