<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>

新聞中心

EEPW首頁(yè) > 嵌入式系統 > 設計應用 > μC/OS―III為縮短中斷關(guān)閉時(shí)間作出的改進(jìn)

μC/OS―III為縮短中斷關(guān)閉時(shí)間作出的改進(jìn)

作者: 時(shí)間:2016-10-08 來(lái)源:網(wǎng)絡(luò ) 收藏

摘要:本文介紹了的中斷機制,研究了μC/OS—III為縮短中斷關(guān)閉時(shí)間做出的改進(jìn)。通過(guò)對比μC/OS—II以及μC/OS—III的辦法,分析μC/OS—III在哪些方面作出了改進(jìn)。這些改進(jìn)使得μC/OS—III的實(shí)時(shí)性能得到顯著(zhù)提升,使得μC/OS—III的中斷關(guān)閉時(shí)間大大縮短。
關(guān)鍵詞:μC/OS—III;;;

引言
μC/OS—III是一款全新的,源于世界上流行的實(shí)時(shí)內核μC/OS—II。較μC/OS—II,μC/OS—III做了很多改進(jìn)。其中,很重要的一點(diǎn)就是為了縮短中斷關(guān)閉時(shí)間作出的改進(jìn)。本文將深入分析為什么這些改進(jìn)能夠使得μC/OS—III的實(shí)時(shí)性能得到提升。

1 中斷簡(jiǎn)介
所謂中斷,其實(shí)就是一種硬件機制,用于通知CPU有一個(gè)異步事件發(fā)生了。由于μC/OS—III是面向以ARMCortex為代表的高端32位CPU的,因此,本文將以ARMCortex—M3為例來(lái)介紹一般CPU對中斷的處理。
如圖1所示,中斷控制器NVIC和ARM Cortex—M3CPU緊密合作完成中斷的處理。中斷控制器NVIC負責接收所有的中斷請求。NVIC會(huì )把當前優(yōu)先級最高的中斷請求的服務(wù)地址傳遞給CPU。Cortex—M3 CPU在確認中斷后,會(huì )自動(dòng)將R0~R2、R12~R15入棧保存,并跳轉執行中斷服務(wù)程序。中斷服務(wù)程序執行完后,R0~R2、R12~R15會(huì )自動(dòng)出棧。

本文引用地址:http://dyxdggzs.com/article/201610/305955.htm

a.JPG


通過(guò)對中斷的處理,CPU能夠在外部事件發(fā)生的時(shí)候立刻進(jìn)行處理,從而滿(mǎn)足系統的實(shí)時(shí)性要求。在一些特殊情況下,CPU需要通過(guò)特殊的指令來(lái)關(guān)中斷。然而,需要引起特別注意的是,關(guān)中斷會(huì )增加中斷延遲時(shí)間,可能導致后續的中斷請求丟失。嵌入式系統中斷源眾多,對實(shí)時(shí)性要求高,中斷關(guān)閉的時(shí)間越短越好,中斷處理程序運行時(shí)間越短越好。中斷關(guān)閉時(shí)間的長(cháng)短是實(shí)時(shí)內核最重要的一個(gè)指標。

2 μC/OS-Ⅲ作出的改進(jìn)
在μC/OS—III中,如果一個(gè)中斷對應的事件不需要任務(wù)知道,不需要給任務(wù)發(fā)送信號或者消息,推薦用戶(hù)把這個(gè)中斷寫(xiě)成無(wú)需內核參與的中斷;如果這個(gè)中斷需要給任務(wù)發(fā)送信號或者消息,用戶(hù)可以選擇直接發(fā)布或者延遲發(fā)布這兩種發(fā)布模式中的一種。
2. 1 無(wú)需內核參與的中斷
在很多情況下,中斷需要做的處理非常簡(jiǎn)單,比如一些I/O中斷,并不需要內核知道。這種情況下典型的無(wú)需內核參與的中斷服務(wù)程序示意代碼如下:
保存中斷服務(wù)程序用到的寄存器;
清除中斷請求;
不要打開(kāi)中斷;(1)
調用中斷處理程序;
恢復保存的寄存器;
中斷返回;
在無(wú)需內核參與的中斷服務(wù)程序中(1)處不要開(kāi)中斷,因為開(kāi)中斷后,其他中斷可能嵌套,也可能調用μC/OS—III的內核函數,導致調度回到高優(yōu)先級任務(wù)繼續執行。而內核并不知道有這個(gè)中斷,所以這個(gè)中斷的完成時(shí)間將會(huì )變得特別長(cháng)。
筆者建議,I/O中斷處理程序最好使用這種方式。另外,在A(yíng)RM Cortex—M3中,因為R0~R2是自動(dòng)入棧和出棧的,簡(jiǎn)單的I/O處理中斷盡量只使用R0~R2,這樣可以省掉中斷服務(wù)程序中保存和恢復寄存器的步驟,縮短了中斷服務(wù)程序的運行時(shí)間。
2.2 需要內核參與的中斷
一個(gè)中斷對應的事件正好是一個(gè)任務(wù)正在等待的事件,這意味著(zhù)這個(gè)中斷需要向對應的任務(wù)發(fā)送信號或者消息。μC/OS—III由中斷向任務(wù)發(fā)送信號或者消息有兩種模式。這兩種模式分別為直接發(fā)布(Direct Post)和延遲發(fā)布(Deferred Post)模式。所謂直接發(fā)布,是指在中斷服務(wù)函數中調用各種post函數時(shí),會(huì )立即完成post操作;而延遲發(fā)布,是指在中斷服務(wù)函數中調用各種post函數時(shí),不會(huì )立即完成post操作,該操作會(huì )被緩存起來(lái)。
在分析μC/OS—III的這兩種發(fā)布模式之前,先看看μC/OS—III中典型的需要內核參與的中斷服務(wù)程序的結構。需要內核參與的中斷服務(wù)程序示意性代碼如下:
關(guān)閉中斷;
保存全部CPU寄存器;
OSIntNestingCtr直接加1;
if(OSIntNestingCtr==1){
OSTCBCurPtr->StkPtr=當前任務(wù)的堆棧指針;
}
清中斷源;
重新開(kāi)中斷;
執行用戶(hù)中斷處理程序; (1)
調用OSIntExit(); (2)
恢復所有CPU寄存器;
執行中斷返回指令;
2.2.1 直接發(fā)布
μC/OS—II中使用的是直接發(fā)布模式,μC/OS—III中保留了這個(gè)模式。
圖2為直接發(fā)布模式的示意圖,當一個(gè)外設產(chǎn)生中斷,并向CPU發(fā)出中斷請求,然后CPU執行中斷服務(wù)程序。這個(gè)需要內核參與的中斷服務(wù)程序在示意性代碼標志(1)這個(gè)步驟中,將會(huì )調用OSSemPost()、OSTaskSemPost()、OSFlagPost()、OSQPost()和OSTaskQPost()這5個(gè)發(fā)布函數其中的一個(gè)給任務(wù)發(fā)消息或信號,并且這些post操作會(huì )被立即執行,使得正在等待這個(gè)中斷發(fā)生的任務(wù)進(jìn)入就緒狀態(tài)。

d.JPG


在需要內核參與的中斷服務(wù)程序示意性代碼標志(2)中,調用OSIntExit(),OSIntExit()中會(huì )調用OSIntCtxSw()進(jìn)行任務(wù)調度。然后系統將執行更高優(yōu)先級的任務(wù)或者之前被中斷的任務(wù)。
在直接發(fā)布模式下,中斷服務(wù)程序會(huì )直接執行post操作。而這些post操作會(huì )訪(fǎng)問(wèn)μC/OS—III中的很多臨界段代碼,因此μC/OS—III必須通過(guò)關(guān)中斷來(lái)保護系統中會(huì )被上述post操作所訪(fǎng)問(wèn)到的臨界段代碼,這樣無(wú)疑會(huì )增加中斷關(guān)閉的時(shí)間。中斷關(guān)閉時(shí)間的增加會(huì )導致實(shí)時(shí)內核的實(shí)時(shí)性能降低。
2.2.2 延遲發(fā)布
在詳細研究延遲發(fā)布模式之前,必須先了解μC/OS—III中兩個(gè)新的概念。
(1)中斷隊列
中斷隊列類(lèi)似于一個(gè)堆棧,它專(zhuān)門(mén)用來(lái)保存發(fā)布函數調用操作以及與這個(gè)調用相關(guān)的參數。
(2)中斷隊列處理任務(wù)
中斷隊列處理任務(wù)是μC/OS—III中一個(gè)新的內部任務(wù),它具有最高的優(yōu)先級(優(yōu)先級0)。這個(gè)任務(wù)專(zhuān)門(mén)用來(lái)處理中斷隊列。
圖3為延遲發(fā)布模式的示意圖,一個(gè)外設產(chǎn)生中斷,并向CPU發(fā)出中斷請求,然后CPU執行中斷服務(wù)程序。

e.JPG


與直接發(fā)布模式不同的是,這個(gè)中斷服務(wù)程序調用發(fā)布函數給任務(wù)發(fā)布消息或信號時(shí),系統不會(huì )立即執行這些post操作,而是將這些post函數的調用以及相應的參數寫(xiě)入中斷隊列中,并且使中斷隊列處理任務(wù)進(jìn)入就緒態(tài)。
舉例說(shuō)明,μC/OS—III中,中斷服務(wù)程序給任務(wù)發(fā)送信號量時(shí),調用OSSemPost()函數。在OSSemPost()函數中,系統先判斷是什么發(fā)布模式。如果是延遲發(fā)布模式,則調用OS_IntQPost(),OS_IntQPost()用來(lái)將OSSemPost()函數的調用和相應的參數寫(xiě)入中斷隊列并使得中斷處理任務(wù)進(jìn)入就緒態(tài);如果是直接發(fā)布模式,則調用OS_SemPost(),這個(gè)函數用來(lái)執行信號量的post操作。OSSemPost()函數的部分源碼如下:
f.JPG
然后,中斷服務(wù)程序執行OSIntExit(),OSIntExit()中調用OSIntCtxSw()執行任務(wù)調度。由于中斷隊列處理任務(wù)優(yōu)先級最高,μC/OS—III將執行中斷隊列處理任務(wù)。該任務(wù)從中斷隊列中提取出發(fā)布函數調用信息,此時(shí)仍需要關(guān)閉中斷,以防止中斷服務(wù)程序同時(shí)對中斷隊列進(jìn)行訪(fǎng)問(wèn)。中斷隊列處理任務(wù)提取出發(fā)布函數調用的信息后重新開(kāi)中斷,并且鎖定任務(wù)調度器,然后進(jìn)行發(fā)布函數調用,相當于發(fā)布函數調用一直在任務(wù)級代碼中進(jìn)行。
這個(gè)中斷隊列處理任務(wù)將中斷隊列一一處理完后,將自身掛起,并重新啟動(dòng)任務(wù)調度來(lái)運行當前處于最高優(yōu)先級的就緒任務(wù)。
由于延遲發(fā)布模式下,μC/OS—III的中斷服務(wù)程序不會(huì )直接進(jìn)行post操作。所以μC/OS—III中那些能夠被post操作所訪(fǎng)問(wèn)的臨界段代碼不需要進(jìn)行關(guān)閉中斷的操作,只需要禁止任務(wù)調度就行。這將使得系統關(guān)中斷時(shí)間大大縮短。
延遲發(fā)布模式下,用最高優(yōu)先級的中斷隊列處理任務(wù)來(lái)處理需要做任務(wù)調度的中斷,在保護了臨界段代碼的同時(shí),又保持了中斷的快速響應和處理。中斷服務(wù)程序不需要進(jìn)行post操作,從而縮短了中斷服務(wù)程序的時(shí)間。
2.2.3 模式選擇
直接發(fā)布模式和延遲發(fā)布模式最主要的區別在于中斷關(guān)閉時(shí)間。延遲發(fā)布模式很大程度上縮短了中斷關(guān)閉時(shí)間和中斷程序的運行時(shí)間,但是卻增加了任務(wù)的延時(shí)。
應用中如果存在要求響應非常迅速的中斷源,用戶(hù)應該選擇延遲發(fā)布模式,因為用直接發(fā)布模式很有可能無(wú)法處理。
另外,由于μC/OS—III中,相同優(yōu)先級下的多任務(wù)、事件標志組、等待多個(gè)內核對象、調用廣播方式發(fā)布這4個(gè)特性都會(huì )導致臨界段代碼變長(cháng)。如果應用中用到了這些特性,應該使用延遲發(fā)布模式。
如果應用中不存在要求響應非常迅速的中斷源,也沒(méi)有用到以上幾種特性,用戶(hù)可以使用直接發(fā)布模式,即μC/OS—II模式,否則還是建議用戶(hù)盡量使用延遲發(fā)布模式。
選擇μC/OS—III的發(fā)布模式非常簡(jiǎn)單,只需要在OS_cfg.h中設置OS_CFG_ISR_POST_DEFERRED_EN的值即可,對應用程序和中斷服務(wù)程序,代碼不需要做任何改動(dòng):置0,為直接發(fā)布模式;置1,為延遲發(fā)布模式。
2.2.4 實(shí)驗結果比較
筆者在PK10N512VLL100上移植了μC/OS—III,這是Freescale公司的一款基于A(yíng)RM Cortex—M4核的微控制器。通過(guò)一些簡(jiǎn)單的小實(shí)驗來(lái)分析直接發(fā)布模式以及延遲發(fā)布模式下,中斷關(guān)閉時(shí)間的對比。實(shí)驗中通過(guò)啟動(dòng)系統的統計任務(wù)stat_task,然后讀取系統的全局變量OS Int DisTimeMax來(lái)獲取系統的最大中斷關(guān)閉時(shí)間。
整個(gè)實(shí)驗用控制LED的閃爍任務(wù)來(lái)實(shí)現4種不同的實(shí)驗條件。第1種,只有一個(gè)初始化任務(wù),用來(lái)初始化硬件和控制LED的閃爍;第2種,有一個(gè)初始化任務(wù)(初始化硬件)和兩個(gè)優(yōu)先級一樣的用戶(hù)任務(wù)(分別控制兩個(gè)不同的LED周期閃爍);第3種,有一個(gè)初始化任務(wù)(初始化硬件)和4個(gè)優(yōu)先級一樣的用戶(hù)任務(wù)(分別控制4個(gè)不同的LED周期閃爍),并且沒(méi)用到廣播消息的功能,第4種,有一個(gè)初始化任務(wù)(初始化硬件)和4個(gè)優(yōu)先級一樣的用戶(hù)任務(wù)(分別控制4個(gè)不同的LED周期閃爍),并且實(shí)驗中用到了廣播消息的功能(初始化任務(wù)向4個(gè)優(yōu)先級一樣的用戶(hù)任務(wù)廣播消息)。
表1是實(shí)驗結果,表中的最大中斷關(guān)閉時(shí)間的單位為系統的時(shí)鐘周期數,實(shí)驗中系統的時(shí)鐘為100 MHz。

g.JPG


從以上實(shí)驗結果可以看出,4種實(shí)驗條件下,延遲發(fā)布模式的最大中斷關(guān)閉時(shí)間基本保持恒定。而直接發(fā)布模式下,系統的任務(wù)越多,功能越復雜,最大中斷關(guān)閉時(shí)間也越來(lái)越長(cháng)。并且,在相同條件下,直接發(fā)布模式的最大中斷關(guān)閉時(shí)間比延遲發(fā)布模式大很多。

結語(yǔ)
相對于μC/OS—II,μC/OS—III在縮短中斷關(guān)閉時(shí)間方面作出了突出的改進(jìn)。首先,用戶(hù)可以根據中斷的類(lèi)型使用無(wú)需內核參與的中斷服務(wù)程序和需要內核參與的中斷服務(wù)程序,盡最大可能減少中斷程序的運行時(shí)間。另外,新增了由中斷給任務(wù)發(fā)送信號或消息的延遲發(fā)布模式。該模式有效地縮短了中斷關(guān)閉的時(shí)間和中斷程序的運行時(shí)間,提高了系統的實(shí)時(shí)性。



評論


相關(guān)推薦

技術(shù)專(zhuān)區

關(guān)閉
国产精品自在自线亚洲|国产精品无圣光一区二区|国产日产欧洲无码视频|久久久一本精品99久久K精品66|欧美人与动牲交片免费播放
<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>