ucosii中文書邵貝貝

1、集團(tuán)企業(yè)公司編碼ucosii 中文書邵貝貝(LL3698-KKI1269-TM2483-LUI12689-ITT289-第 5 章時(shí)間管理在 3. 10 節(jié)時(shí)鐘節(jié)拍中曾提到， p C/0S- II( 其它內(nèi)核也一樣 ) 要求用 戶提供定時(shí)中斷來實(shí)現(xiàn)延時(shí)與超時(shí)控制等功能。這個(gè)定時(shí)中斷叫做時(shí)鐘 節(jié)拍，它應(yīng)該每秒發(fā)生 10 至 100 次。時(shí)鐘節(jié)拍的實(shí)際頻率是由用戶的應(yīng)用程序決定的。時(shí)鐘節(jié)拍的頻率越高，系統(tǒng)的負(fù)荷就越重。3. 10 節(jié)討論了時(shí)鐘的中斷效勞子程序和節(jié)時(shí)鐘節(jié)函數(shù)OSTimeTick該函數(shù)用于通知 M C/OS-II發(fā)生了時(shí)鐘節(jié)拍中斷。本章主 要 講述五個(gè)與時(shí)鐘節(jié)拍有關(guān)的系統(tǒng)效勞：OSTi

2、meDlyOOSTimeDlyHMSMOOST imeDlyResume ()OSTimeGet ()OSTimeSet ()本章所提到的函數(shù)可以在 OS_TIME. C文件中找到。5.0 任務(wù)延時(shí)函數(shù)， OSTimeDlyOpc/os-II 提供了這樣一個(gè)系統(tǒng)效勞：申請?jiān)撔诘娜蝿?wù)可以延時(shí)一 段 時(shí)間，這段時(shí)間的長短是用時(shí)鐘節(jié)拍的數(shù)目來確定的。實(shí)現(xiàn)這個(gè)系統(tǒng)效勞的函數(shù)叫做OSTimeDIyO o調(diào)用該函數(shù)會使 U C/OS-II進(jìn)行一次任務(wù) 調(diào) 度，并且執(zhí)行下一個(gè)優(yōu)先級最高的就緒態(tài)任務(wù)。任務(wù)調(diào)用 0STimeDlyO 后，一旦規(guī)定的時(shí)問期滿或者有其它的任務(wù)通過調(diào)用OSTimeDlyResume

3、O取消了延時(shí)，它就會馬上進(jìn)入就緒狀態(tài)。注意，只有當(dāng)該任務(wù)在所有就緒任務(wù)中具有最高的優(yōu)先級時(shí)，它才會立即運(yùn)行。程序清單L5. 1所示的是任務(wù)延時(shí)函數(shù)OSTimeDIyO的代碼。用戶的應(yīng)用程序是通過提供延時(shí)的時(shí)鐘節(jié)拍數(shù) 個(gè)1到65535之間的數(shù)，來 調(diào)用該函數(shù)的。如果用戶指定 0值L5. 1(1),那么說明用戶不想延時(shí)任務(wù),函數(shù)會立即返回到調(diào)用者。非 0值會使得任務(wù)延時(shí)函數(shù) OSTimeDIyO將當(dāng)前 任務(wù)從就緒表中移除L5.1 (2) o接著，這個(gè)延時(shí)節(jié)拍數(shù)會被保存在當(dāng)前任 務(wù)的OS_TC中 L5. 1,并且通H OSTimeTick()每隔一個(gè)時(shí) 鐘節(jié)拍就減少一個(gè)延時(shí)節(jié)拍數(shù)。最后，既然任務(wù)已經(jīng)

4、不再處于就緒狀態(tài)，任務(wù)調(diào)度程序 會執(zhí)行下一個(gè)優(yōu)先級最高的就緒任務(wù)。程序清單 L5.1 OSTimeDIyO.voidOSTimeDly (INT16Uticks)if(ticks0)(1)OS_ENTER_CRITICAL();if( (OSRdyTblOSTCBCur-OSTCB Y&=OSTCBCur-OSTCBBitX)=0)(2)OSRdyGrp& OSTCBCurOSTCBBitY;OSTCBCur-OSTCBDly=ticks;(3)OS_EXIT_CRITICAL();OSSched() ; (4)清楚地認(rèn)識0到一個(gè)節(jié)拍之間的延時(shí)過程是非常重要的。換句話說，如果用戶只想延時(shí)一個(gè)時(shí)

5、鐘節(jié)拍，而實(shí)際上是在0到一個(gè)節(jié)拍之間 結(jié) 束延時(shí)。即使用戶的處理器的負(fù)荷不是很重，這種情況依然是存在 的。圖F5. 1詳細(xì)說明了整個(gè)過程。系統(tǒng)每隔10ms發(fā)生一次時(shí)鐘節(jié)拍中斷Fb.KDlo 假設(shè)用戶沒有執(zhí)行其它的中斷并且此時(shí)的中斷是開著的， 時(shí)鐘節(jié) 拍中斷效勞就會發(fā)生 F5. 1(2) 。也許用戶有好兒個(gè)高優(yōu)先級的任 務(wù) (HPT)在等待延時(shí)期滿，它們會接著執(zhí)行F5. 1(3)。接下來，圖5.1中所示的低優(yōu)先級任務(wù) (LPT) 會得到執(zhí)行的時(shí)機(jī)，該任務(wù)在執(zhí)行完后馬上 調(diào)用 F5. 1(4) 所示的 0STimeDly(l) o H C/OS- II 會使該任務(wù)處于休眠狀 態(tài) 直至下一個(gè)節(jié)拍的到

6、來。當(dāng)下一個(gè)節(jié)拍到來后，時(shí)鐘節(jié)拍中斷效勞子 程序 會執(zhí)行 F5. 1(5) , 但是這一次由于沒有高優(yōu)先級的任務(wù)被執(zhí)行， PC/0S- II 會立即執(zhí)行申請延時(shí)一個(gè)時(shí)鐘節(jié)拍的任務(wù) F5. 1(6) 。正如用 戶所看 到的，該任務(wù)實(shí)際的延時(shí)少于一個(gè)節(jié)拍！在負(fù)荷很重的系統(tǒng)中，任務(wù)茯至有可能會在時(shí)鐘中斷即將發(fā)生時(shí)調(diào)用 OSTimeDly(l), 在這種情 況下，任務(wù)兒 乎就沒有得到任何延時(shí)，因?yàn)槿蝿?wù)馬上又被重新調(diào)度了。如果用戶的應(yīng)用程序至少得延時(shí)一個(gè)節(jié)拍，必須要調(diào)用 0STimeDly(2), 指定延時(shí)兩個(gè)節(jié)拍！Figures. 1 Delayresol u tion.5.1 按時(shí)分秒延時(shí)函數(shù) OS

7、TimeDlyHMSMOOSTimeDIyO雖然是一個(gè)非常有用的函數(shù)，但用戶的應(yīng)用程序需要知道延時(shí)時(shí)間對應(yīng)的時(shí)鐘節(jié)拍的數(shù)目。用戶可以使用定義全局常數(shù)OS_TICKS_PER_SE參看OS_CFG. H的方法將時(shí)間轉(zhuǎn)換成時(shí)鐘段，但這種方法有時(shí)顯得比擬愚笨。筆者增加了OSTimeDlyHMSM函數(shù)后，用戶就可 以按小時(shí)(H)、分(M)、秒(S)和毫秒(m)來定義時(shí)間了，這樣會顯得更自然些。與 OSTimeDIyO 樣，調(diào)用 OSTimeDlyHMSM函數(shù)也會使 P C/OS-II 進(jìn)行一次任務(wù)調(diào)度，并且執(zhí)行下一個(gè)優(yōu)先級最高的就緒態(tài)任務(wù)。任務(wù)調(diào)用OSTimeDlyHMSMO，旦規(guī)定的時(shí)間期滿或者有其

8、它的任務(wù)通過調(diào)用OSTimeDlyResume ()取消了延時(shí)慘看 5. 02, 恢復(fù)延時(shí)的任務(wù)OSTimeDlyResumeO)它就會馬上處于就緒態(tài)。同樣，只有當(dāng)該任務(wù)在所有就緒態(tài)任務(wù)中具有最高的優(yōu)先級時(shí)，它才會立即運(yùn)行。程序清單 L5. 2所示的是OSTimeDlyHMSM的代碼。從中可以看出，應(yīng)用程序是通過用小時(shí)、分、秒和毫秒指定延時(shí)來調(diào)用該函數(shù)的。在實(shí)際 應(yīng)用中，用戶應(yīng)防止使任務(wù)延時(shí)過長的時(shí)間，因?yàn)閺娜蝿?wù)中獲得 一些反應(yīng) 行為(如減少計(jì)數(shù)器，去除LED等等)經(jīng)常是很不錯(cuò)的事。但 是，如果用戶 確實(shí)需要延時(shí)長時(shí)間的話， PC/OS-II 可以將任務(wù)延時(shí)長達(dá) 256個(gè)小時(shí) (接近 11天)

9、。OSTimeDlyHMSM開始先要檢驗(yàn)用戶是否為參數(shù)定義了有效的值:L5.2(l) o與OSTimeDlyO-樣,即使用戶沒有定義延時(shí),OSTimeDlyHMSM () 也是存在的 L5. 2(9) 。因?yàn)?U C/OS- II 只知道節(jié)拍，所 以節(jié)拍總數(shù) 是從指定的時(shí)間中計(jì)算出來的 L5.2(3) 。很明顯，程序清單 L5. 2 中的 程序并不是十分有效的。筆者只是用這種方法告訴大家一個(gè)公 式，這樣用 戶就可以知道怎樣計(jì)算總的節(jié)拍數(shù)了。真正有意義的只是 OS_TICKS_PER_SECo L5. 2(3) 決定了最接近需要延遲的時(shí)間的時(shí)鐘節(jié)拍 總數(shù)。500/0S_TICKS_PER_SEC

10、0ND值根本上與 0. 5 個(gè)節(jié)拍對應(yīng)的毫秒數(shù) 相同。例如，假設(shè)將時(shí)鐘頻率 (OS_TICKS_PER_SEC)置成100Hz(10ms), 4ms 的延時(shí)不會產(chǎn)生任何延時(shí)！而5ms的延時(shí)就等于延時(shí)10msp C/OS-II支持的延時(shí)最長為65, 535個(gè)節(jié)拍。要想支持更長時(shí)問的 延時(shí)，如L5.2(2)所示，OSTimeDlyHMSM確定了用戶想延時(shí)多少次超過65, 535個(gè)節(jié)拍的數(shù)目:L5.2和剩下的節(jié)拍數(shù):L5.2。例如，假設(shè)OS_TICKS_PER_SBC值為 100,用戶想延時(shí) 15 分鐘，那么 OSTimeDlyHMSMO 會延時(shí)15x60x100二90, 000個(gè)時(shí)鐘。這個(gè)延時(shí)會被

11、分割成兩次 32, 768個(gè) 節(jié)拍的延時(shí)(因?yàn)橛脩糁荒苎訒r(shí)65, 535個(gè)節(jié)拍而不是65536個(gè)節(jié)拍)和一 次24,464個(gè)節(jié)拍的延時(shí)。在這種情況下，OSTimeDlyHMSM首先考慮剩 下的節(jié)拍，然后是超過 65, 535的節(jié)拍數(shù)L5. 2(7)和(8)(即兩個(gè)32, 768 個(gè)節(jié)拍延時(shí))O程序清單 L5. 20STimeDlyHMSM().INT8U0STimeDlyHMSM(INT8Uhours, INTSUmi nu tes, INTSUsec on ds, INT16 Umilli)INT32Uticks;INT16Uloops;if (hours0 minutes0 seconds

12、。； milli0) (1)if (minu tes59)return(OS_TIMEN VALID_MINUTES);if (sec on ds59)return(OS_TIMEN VALID_SECONDS);If(m 訂 li999) return(OS_TIMEN VALID_MILLI);ticks=(INT32U)hours*3600L*0S_TICKS_PER_SEC + (INT32U)mi nu tes*60L*0S_TICKS_PER_SEC +(INT32U)sec on ds*0S TICKS PER SEC+OS_TICKS_PER_SEC*(INT32U)milli

13、 +500L/0S_TICKS_PER_SEC)/1000L;loops 二 ticks/65536L;ticks二ticks%65536L;OSTimeDly(ticks);while(loops0) OSTimeDly(32768);OSTimeDly(32768);loops ;return(O S_NO_ERR);else return(OS_TIME_ZERO_DL Y); 由于OSTimeDlyHMSM的具休實(shí)現(xiàn)方法，用戶不能結(jié)束延時(shí)調(diào)用OSTimeDlyHMSM要求延時(shí)超過65535個(gè)節(jié)拍的任務(wù)。換句話說，如果時(shí) 鐘節(jié)拍的頻率是100Hz,用戶不能讓調(diào)用OSTimeDlyHMSM

14、 10, 55, 350)或更 長延遲時(shí)問的任務(wù)結(jié)束延時(shí)。5.2讓處在延時(shí)期的任務(wù)結(jié)束延時(shí)，OSTimeDlyResume ()y C/OS- II允許用戶結(jié)束延時(shí)正處于延時(shí)期的任務(wù)。延時(shí)的任務(wù)可以不等待延時(shí)期滿，而是通過其它任務(wù)取消延時(shí)來使自己處于就緒態(tài)。這可以通過調(diào)用OSTimeDlyResume ()和指定要恢復(fù)的任務(wù)的優(yōu)先級來完成。實(shí)際上，OSTimeDlyResume ()也可以喚醒正在等待事件(參看第六章 一一任 務(wù)問的通訊和同步)的任務(wù)，雖然這一點(diǎn)并沒有提到過。在這種情況下，等 待事件發(fā)生的任務(wù)會考慮是否終止等待事件OSTimeDlyResume ()的代碼如程序清單L5. 3所

15、爾，它首先要確保指 定的任務(wù)優(yōu)先級有效L5. 3(1)1 o 接著，OSTimeDlyResume ()要確認(rèn)要結(jié) 束延時(shí)的任務(wù)是確實(shí)存在的L5. 3(2) o如果任務(wù)存在，OSTimeDlyResume ()會檢驗(yàn)任務(wù)是否在等待延時(shí)期滿 L5. 3 (3)。只要OS_TC域中的OSTCBDly包含非0值就說明任務(wù)正在等待延時(shí)期滿，因?yàn)?任 務(wù)調(diào)用了 OSTimeDlyO OSTimeDlyHMSM或其它在第六章中所描述的 PEND 函數(shù)。然后延時(shí)就可以通過強(qiáng)制命令 OSTCBDly為0來取消L5. 3 (4) o延時(shí)的任務(wù)有可能已被掛起了，這樣的話，任務(wù)只有在沒有被掛起的情況下才能處于就緒狀

16、態(tài)L5.3(5)o 當(dāng)上面的條件都滿足后，任 務(wù)就會被放在就緒表中L5. 3(6)1 o 這時(shí)，OSTimeDlyResume ()會調(diào)用任 務(wù)調(diào)度程序來看被恢復(fù)的任務(wù)是否擁有比當(dāng)前任務(wù)更高的優(yōu)先級L5. 3o這會導(dǎo)致任務(wù)的切換。程序清單L5. 3恢復(fù)正在延時(shí)的任務(wù)INT8U0STimeDlyResume(INTSUprio)OS_TCB*ptcb;1X 7辻(pr i o=OS_LOWEST_PRI0) return(OS_PRI ON VALID);OS_ENTER_CRITICAL();ptcb=(OS_TCB*)OSTCBPrioTblEprio; if(ptcb! = (0S_TCB

17、*)0) if(ptcb-OSTCBDly!=O) ptcb-0STCBDly=0;辻(! (ptcb-OSTCBStat&O S_STAT_SUSPEND) OSRdyGrp二/( /(7 7 X7 X7 X72 3 4 5 6 /IX /| /|ptcb-OSTCBBit Y;OSRdyTblptcb-OSTCBY二 ptcb-OSTCBBitX;OS_EXIT_CRITICAL();OSSchedO;else OS_EXIT_CRITICAL();return( OS_NO_ERR);else OS_EXIT_CRITICAL();return(OS_TIME_NOT_DL Y);els

18、e OS_EXIT_CRITICAL();return( OS_TASK_NOT_EXIST);注意，用戶的任務(wù)有可能是通過暫時(shí)等待信號量、郵箱或消息隊(duì)列來延時(shí)白己的(參看第六章)?？梢院唵蔚赝ㄟ^控制信號量、郵箱或消息隊(duì)列來恢復(fù)這樣的任務(wù)。這種情況存在的唯一問題是它要求用戶分配事件控制塊(參看6. 00),因此用戶的應(yīng)用程序會多占用一些RAM 5.3 系統(tǒng)時(shí)問，OSTimeGet ()禾口 OSTimeSet ()無論時(shí)鐘節(jié)拍何時(shí)發(fā)生，u C/OS-II都會將一個(gè)32位的計(jì)數(shù)器加lo這個(gè)計(jì)數(shù)器在用戶調(diào)用 OSStart ()初始化多任務(wù)和4, 294, 967, 295 個(gè)節(jié)拍執(zhí)行完一遍的時(shí)候從0開始計(jì)數(shù)。在時(shí)鐘節(jié)拍的頻率等于100Hz的時(shí)候，這個(gè)32位的計(jì)數(shù)器每隔497天就重新開始計(jì)數(shù)。用戶可以通過調(diào)用OSTimeGet ()來獲得該計(jì)數(shù)器的當(dāng)前值。也可以通過調(diào)用OSTimeSetO來改變該計(jì)數(shù)器的值。OSTimeGet ()和OSTimeSetC兩個(gè)函數(shù)的代碼如程序清單L5