μC/OS-II的任務切換機理及中斷調度優化

由于沒有中斷嵌套，在中斷處理中沒有別的中斷發生，那么返回的步驟和上述的進棧操作正好相反。在中斷處理完了以后，SP會自動回到圖4中③的SP位置。接著，系統會查詢到優先級最高的任務，然后把SP的指針移到優先級最高的任務的任務堆棧，進行R15~R4的出棧工作，最后用RETI中斷返回指令返回到新的任務。因為我們把所有的任務堆棧都規定成相同的格式，所以它們之間不會產生問題。這里需要注意的是，因為系統在C編譯器的中斷處理中會對中斷進入時默認壓棧的寄存器出棧，所以在設計出棧的程序時，要先把這些內容壓棧，這樣才能正確出棧。

2） 在中斷的處理過程中，有別的中斷產生，產生中斷嵌套。

如圖5所示，由于在處理中斷的時候，SP已經被移到系統堆棧去了，只有當中斷退出的時候才可能把SP移到別的任務的任務堆棧中。所以在中斷的時候進行中斷嵌套，那么對于中斷的處理和第一次是一樣的，所不同的是，這次保存在堆棧中的不是任務運行中的寄存器，而是中斷處理中的寄存器，而且是保存在系統堆棧中而不是任務堆棧中。從這里就可以看出優化內存的效果。所有的中斷嵌套中的寄存器壓棧都壓在系統堆棧中，這樣對于任務堆棧內存大小的要求大大降低。

因為μC/OS-II在進入中斷中，會把全局變量OSIntNesting++；在退出中斷的時候，又會把OSIntNesting--。在退出中斷進行任務切換之前，μC/OS-II會先判斷OSIntNesting是否為0，是0才會進行任務調度。當第二中斷運行結束以后，退出中斷嵌套的時候，OSIntNesting不為0，也就不會進行任務調度。因此，仍舊在系統堆棧出棧，那么系統會繼續前面沒有完成的中斷服務程序。

接著退出中斷的順序和非中斷嵌套的順序是一樣的。在中斷處理完以后，SP會自動回到圖4中③的SP位置。接著，系統會查詢到優先級最高的任務，然后把SP的指針移到優先級最高的任務的任務堆棧。進行R15~R4的出棧工作，最后用RETI中斷返回指令返回到新的任務。

中斷的情況基本上就是上述兩種。對于有些文獻中提到的在中斷中會調度到更高優先級的任務的情況，筆者覺得是不應該發生的。因為從上面的分析可以看出，默認的（μC/OS-II的設計思路）中斷處理會同時對全局變量OSIntNesting進行增減處理，以給出是否需要任務調度的條件。那么即使在中斷服務程序中把更高優先級的任務就緒，也會等到中斷退出以后再進行調度，除非是在中斷中直接調用更高優先級的任務函數。但這種方法應該是和μC/OS-II的原則相違背的，沿用的是以前前后臺設計的思路。

對于這樣的設計方式，時鐘節拍的處理方式必須和一般的中斷處理方式是一樣的。一般來說，MSP430使用WATCHDOG時鐘中斷作為時鐘節拍的產生源。從本質上來說，時鐘節拍本身也是中斷處理過程，所以對于時鐘節拍的處理應該和其它的中斷處理過程相同。實際上，在時鐘節拍的處理過程中也可能會存在中斷嵌套的問題。

中斷堆棧和任務堆棧分離設計的程序流程如圖6所示。

4 幾點建議

① 編寫中斷程序的時候，有條件盡量使用匯編語言。因為這樣可以避免一些編譯器自己進行的操作，減少指針調整的次數。

② 在用C編寫中斷服務的時候，因為有些功能必須調用匯編的函數才能實現。調用函數時，有些時候壓棧的PC會破壞堆棧的結構。這個時候需要把堆棧進行適當的調整，保證堆棧格式的正確。

③ 中斷處理過程中調用OSIntExit()的時候，由于 μC/OS-II的原始設計中SP指針有時是不調整的，所以在OSIntExit()返回了以后，還要判斷一下是否中斷嵌套。因為有的時候是需要切換任務的。