中斷的具體行為_第1頁
中斷的具體行為_第2頁
中斷的具體行為_第3頁
中斷的具體行為_第4頁
中斷的具體行為_第5頁
已閱讀5頁,還剩38頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、中斷的具體行為 中斷/異常的響應序列 異常返回 嵌套的中斷 咬尾中斷 晚到(的高優先級)中斷 異常返回值 中斷延遲 異常響應期間的 faults在本章中,如無特殊說明,“中斷”與“異常”這兩個術語都是同一個意思,可以互換使用。中斷異常的響應序列當CM3開始響應一個中斷時,會在它看不見的體內奔涌起三股暗流:入棧: 把8個寄存器的值壓入棧取向量:從向量表中找出對應的服務程序入口地址選擇堆棧指針MSP/PSP,更新堆棧指針SP,更新連接寄存器LR,更新程序計數器PC入棧入棧響應異常的第一個行動,就是自動保存現場的必要部分:依次把xPSR, PC, LR, R12以及R3 R0由硬件自動壓入適當的堆棧

2、中:如果當響應異常時,當前的代碼正在使用PSP,則壓入PSP,即使用線程堆棧;否則壓入MSP,使用主堆棧。一旦進入了服務例程,就將一直使用主堆棧。假設入棧開始時,SP的值為N,則在入棧后,堆棧內部的變化如表9.1表示。又因為AHB接口上的流水線操作本質,地址和數據都在經過一個流水線周期之后才進入。另外,這種入棧在機器的內部,并不是嚴格按堆棧操作的順序的但是機器會保證:正確的寄存器將被保存到正確的位置,如圖9.1和表9.1的第3列所示。CM3在看不見的內部打亂了入棧的順序,這是有深層次的原因的。先把PC與xPSR的值保存,就可以更早地啟動服務例程指令的預取因為這需要修改PC;同時,也做到了在早期

3、就可以更新xPSR中IPSR位段的值。細心的讀者一定在猜測:為啥袒護R0 R3以及R12呢,R4 R11就是下等公民?原來,在ARM上,有一套的C函數調用標準約定(C/C+ Procedure Call Standard for the ARM Architecture,AAPCS, Ref5)。個中原因就在它上面:它使得中斷服務例程能用C語言編寫,編譯器優先使用被入棧的寄存器來保存中間結果(當然,如果程序過大也可能要用到R4 R11,此時編譯器負責生成代碼來push它們。但是,ISR應該短小精悍,不要讓系統如此操心譯者注)。如果讀者再仔細看,會發現R0 R3, R12是最后被壓進去的。這里也

4、有一番良苦用心:為的是可以更容易地使用SP基址來索引尋址,(以及為了LDM等多重加載指令,因為LDM必須加載地址連續的一串數據)。參數的傳遞也是受益者:使之可以方便地通過壓入棧的R0 R3取出(主要為系統軟件所利用,多見于SVC與PendSV中的參數傳遞)。取向量取向量當數據總線(系統總線)正在為入棧操作而忙得團團轉時,指令總線(I Code總線)可不是涼快地坐著看熱鬧它正在為響應中斷緊張有序地執行另一項重要的任務:從向量表中找出正確的異常向量,然后在服務程序的入口處預取指。由此可以看到各自都有專用總線的好處:入棧與取指這兩個工作能同時進行。更新寄存器更新寄存器在入棧和取向量的工作都完畢之后,

5、執行服務例程之前,還要更新一系列的寄存器: SP:在入棧中會把堆棧指針(PSP或MSP)更新到新的位置。在執行服務例程后,將由MSP負責對堆棧的訪問。 PSR:IPSR位段(地處PSR的最低部分)會被更新為新響應的異常編號。 PC:在向量取出完畢后,PC將指向服務例程的入口地址, LR:LR的用法將被重新解釋,其值也被更新成一種特殊的值,稱為“EXC_RETURN”,并且在異常返回時使用。EXC_RETURN的二進制值除了最低4位外全為1,而其最低4位則有另外的含義(后面講到,見表9.3和表9.4)。 以上是在響應異常時通用寄存器的變化。另一方面,在NVIC中,也伴隨著更新了與之相關的若干寄存

6、器。例如,新響應異常的懸起位將被清除,同時其活動位將被置位。異常返回當異常服務例程執行完畢后,需要很正式地做一個“異常返回”動作序列,從而恢復先前的系統狀態,才能使被中斷的程序得以繼續執行。從形式上看,有3種途徑可以觸發異常返回序列,如表9.2所示;不管使用哪一種,都需要用到先前儲的LR的值。有些處理器使用特殊的返回指令來標示中斷返回,例如8051就使用reti。但是在CM3中,是通過把EXC_RETURN往PC里寫來識別返回動作的。因此,可以使用上述的常規返回指令,從而為使用C語言編寫服務例程掃清了最后的障礙(無需特殊的編譯器命令,如_interrupt)。在啟動了中斷返回序列后,下述的處理

7、就將進行:1. 出棧:先前壓入棧中的寄存器在這里恢復。內部的出棧順序與入棧時的相對應,堆棧指針的值也改回去。2. 更新NVIC寄存器:伴隨著異常的返回,它的活動位也被硬件清除。對于外部中斷,倘若中斷輸入再次被置為有效,懸起位也將再次置位,新一次的中斷響應序列也可隨之再次開始。嵌套的中斷在CM3內核以及NVIC的深處,就已經內建了對中斷嵌套的全力支持,根本無需使用用匯編寫封皮代碼(wrapper code)。事實上,我們要做的就只是為每個中斷適當地建立優先級,不用再操心別的。表現在:第一、 NVIC和CM3處理器會為我們排出優先級解碼的順序。因此,在某個異常正在響應時,所有優先級不高于它的異常都

8、不能搶占之,而且它自己也不能搶占自己。第二、 有了自動入棧和出棧,就不用擔心在中斷發生嵌套時,會使寄存器的數據損毀,從而可以放心地執行服務例程。然而,有一件事情卻必須更加一絲不茍地處理了,否則有功能紊亂甚至死機的危險,這就是計算主堆棧容量的最小安全值。我們已經知道,所有服務例程都只使用主堆棧。所以當中斷嵌套加深時,對主堆棧的壓力會增大:每嵌套一級,就至少再需要8個字,即32字節的堆棧空間而且這還沒算上ISR對堆棧的額外需求,并且何時嵌套多少級也是不可預料的。如果主堆棧的容量本來就已經所剩無幾了,中斷嵌套又突然加深,則主堆棧有被用穿的兇險。這就好像已經表現出了高血壓危象的時候,情緒又一激動,就容

9、易導致中風一般。在這里,堆棧溢出同樣是很致命的,它會使入棧數據與主堆棧前面的數據區發生混迭,使這些數據被破壞;若服務例程又更改了混迭區的數據,則堆棧內容被破壞。這么一來在執行中斷返回后,系統極可能功能紊亂,甚至當場被一擊必殺程序跑飛/死機!另一個要注意的,是相同的異常是不允許重入的。因為每個異常都有自己的優先級,并且在異常處理期間,同級或低優先級的異常是要阻塞的,因此對于同一個異常,只有在上次實例的服務例程執行完畢后,方可繼續響應新的請求。由此可知,在SVC服務例程中,就不得再使用SVC指令,否則將fault伺候。咬尾中斷CM3為縮短中斷延遲做了很多努力,第一個要提的,就是新增的“咬尾中斷”(

10、Tail Chaining)機制。當處理器在響應某異常時,如果又發生其它異常,但它們優先級不夠高,則被阻塞這個我們已經知道。那么在當前的異常執行返回后,系統處理懸起的異常時,倘若還是先POP然后又把POP出來的內容PUSH回去,這不成了砸鍋煉鐵再鑄鍋,白白浪費CPU時間嗎,可知還有多少緊急的事件懸而未決呀!正因此,CM3不會傻乎乎地POP這些寄存器,而是繼續使用上一個異常已經PUSH好的成果,消滅了這種鋪張浪費。這么一來,看上去好像后一個異常把前一個的尾巴咬掉了,前前后后只執行了一次入棧出棧操作。于是,這兩個異常之間的“時間溝”變窄了很多,如圖9.2所示。晚到(的高優先級)異常CM3的中斷處理

11、還有另一個機制,它強調了優先級的作用,這就是“晚到的異常處理”。當CM3對某異常的響應序列還處在早期:入棧的階段,尚未執行其服務例程時,如果此時收到了高優先級異常的請求,則本次入棧就成了為高優先級中斷所做的了入棧后,將執行高優先級異常的服務例程。可見,它雖然來晚了,卻還是因優先級高而受到偏袒,低優先級的異常為它“火中取栗”。比如,若在響應某低優先級異常#1的早期,檢測到了高優先級異常#2,則只要#2沒有太晚,就能以“晚到中斷”的方式處理在入棧完畢后執行ISR #2,如圖9.3所示。如果異常#2來得太晚,以至于已經執行了ISR #1的指令,則按普通的搶占處理,這會需要更多的處理器時間和額外32字

12、節的堆棧空間。在ISR #2執行完畢后,則以剛剛講過的“咬尾中斷”方式,來啟動ISR #1的執行。異常返回值前面已經講到,在進入異常服務程序后,LR的值被自動更新為特殊的EXC_RETURN,這是一個高28位全為1的值,只有3:0的值有特殊含義,如表9.3所示。當異常服務例程把這個值送往PC時,就會啟動處理器的中斷返回序列。因為LR的值是由CM3自動設置的,所以只要沒有特殊需求,就不要改動它。總結一下表9.3,可以得出,合法的EXC_RETURN值共3個,如表9.4所示如果主程序在線程模式下運行, 并且在使用MSP 時被中斷, 則在服務例程中LR=0 xFFFF_FFF9(主程序被打斷前的LR

13、已被自動入棧)。如果主程序在線程模式下運行, 并且在使用PSP 時被中斷, 則在服務例程中LR=0 xFFFF_FFFD(主程序被打斷前的LR已被自動入棧)。如果主程序在Handler模式下運行,則在服務例程中LR=0 xFFFF_FFF1(主程序被打斷前的LR已被自動入棧)。這時的“主程序”,其實更可能是被搶占的服務例程。事實上,在嵌套時,更深層ISR所看到的LR總是0 xFFFF_FFF1,如圖9.5所示。由EXC_RETURN的格式可見,你不能把0 xFFFF_FFF0 0 xFFFF_FFFF中的地址作為任何返回地址。其實也并不用擔心會弄錯,因為CM3已經把這個范圍標記成“取指不可區”

14、了。中斷延遲在設計實時系統時,必須對中斷延遲進行嚴肅和仔細地估算。在這里,中斷延遲的定義是:從檢測到某中斷請求,到執行了其服務例程的第一條指令時,已經流逝了的時間。在CM3中,若存儲器系統夠快,且總線系統允許入棧與取指同時進行,同時該中斷可以立即響應,則中斷延遲是雷打不動的12周期(滿足硬實時所要求的確定性)。在與時間賽跑的這12個周期里,處理器內部一直開足馬力,進行了入棧、取向量、更新寄存器以及服務例程取指的一系列操作。但若存儲器太慢以至于引入等待周期,或者還有其它因素,則會引入額外的延時。反正CM3內核是決不會拖后腿的。當處理咬尾中斷時,省去了堆棧操作,因此切入新異常服務例程的耗時可以短至

15、6周期。有些指令需要較多的周期才能完成。它們是除法指令,雙字傳送指令LDRD/STRD以及多重數據傳送指令(LDM/STM)。對于前兩者,CM3將為了保證中斷及時響應而取消它們的執行,待返回后重新開始這犧牲了一點性能,以及某些子程序的一點個人利益,但換來了對意外事件的更快救援。對于LDM/STM,則有另外的處理方式。因為它們不照前兩者那么渾然一體它們其實是一串LDR/STR的速度優化版。于是,為了加速中斷的響應,CM3支持LDM/STM指令的中止和繼續,就好像它們只是普通的一串LDR/STR一樣。為了實現“指令撕裂與粘合”的目的,需要記錄中斷時數據傳送的進程。為此,CM3在xPSR中開出若干個

16、“ICI位”,記錄下一個即將傳送的寄存器是哪一個(LDM/STM在匯編時,都把寄存器號升序排序)。在服務例程返回后,xPSR被彈出,CM3再從ICI bits中獲取當時LDM/STM執行的進度,從而可以繼續傳送。這個辦法聽起來是個好主意,只是在個別情況下還有一點限制:IF THEN(IT)指令的執行也需要在xPSR中使用幾個位,可它需要的位剛好與ICI位重合(類似C中的union)both ICI bits和IT條件都記錄在EPSR中。所以,如果在IF THEN中使用了LDM/STM,則不再記錄LDM/STM的執行進度。但盡管如此,及時響應中斷依然是首要任務。此時只好把LDM/STM取消,待中

17、斷返回后繼續執行。譯注:仔細的讀者可能會注意到,xPSR中有很多位空著沒用,從而可能想不通,為啥要讓“有人可憐沒人愛,有人卻忙不過來”。這可能是因為在其它款式中,這些位被用掉了,或者還有其它什么難言之隱。另外,如果在總線接口上還有未完成的(outstanding)數據傳送,例如有一個帶緩沖的寫操作未完成,處理器也只能等待此傳送完成。這是迫不得以的只有這樣,才能保證在發生了總線fault時,其服務例程能夠安全地搶占其它程序。當多個中斷同時請求時,也會發生中斷延遲,這表現在只有優先級最高的得到立即響應,所有其它的中斷將被延遲。另外,在中斷嵌套時,每個中斷都會阻塞同級和低優先級的中斷。最后,如果中斷

18、被掩蔽(也就是俗稱的關中,在多任務系統下滿地都有),則在掩蔽期間也會附加中斷延遲。異常響應期間的faultsFaults是運行時發生各種故障的表現,在中斷響應期間的故障也不例外。中斷響應的每一步驟都可以觸發faults。入棧期間入棧期間如果在入棧期間引起了總線fault,則本次入棧操作將被強行中止,并且把總線異常懸起或者在允許時立即響應。若除能了總線fault,則此次故障將成為“硬傷”上訪至硬fault。在總線fault被使能的情況下,如果它的優先級比正在響應的異常高,則搶占之,否則將懸起直到引起fault的異常執行完畢。這種情況被稱為“入棧錯誤”(stacking error),由總線fault狀態寄存器(BFSR,地址:0 xE000_ED29)的STKERR位指示(位偏移:4)。如果入棧操作引起MPU訪問違例,則產生存儲管理fault,并且必須立即執行MemFault服務例程,否則將無條件上訪成硬fault。在發生入棧時訪問違例時,存儲管理fault寄存器(MFSR,地址:0 xE000_ED28)中的MSTKERR位(位偏移:4)被置位,用于指示該faul

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論