基于μC／OS-II的中斷下半部設計方案

1 中斷下半部的設計方案
目前，在μC／OS―II內核中任務的運行空間分為中斷空間和任務空間。中斷空間即為中斷服務程序運行所處的空間，這時處理器執行中斷服務程序，而所有任務(task)都被處于被中斷態。對很多處理器而言，在中斷空間內中斷請求是被屏蔽的。中斷下半部的引入將中斷空間一分為二，如圖1所示。中斷的上半部為中斷服務程序，執行那些有嚴格時限要求不能被打斷的工作；中斷的下半部執行那些在中斷上半部被延后，允許被中斷的工作。中斷上半部和下半部都應有自己獨立的棧空間，二者不會干擾。

μC／0S―II已經設計了完善的中斷服務程序的入口和出口函數，所以為了實現中斷上半部和下半部的銜接，要從μC／0S―II的中斷出口函數OSintExit()著手進行修改。修改后的OSIntExit()實現的功能將是：退出中斷的上半部，檢查中斷下半部是否有就緒的服務程序，若有則在允許中斷的情況下執行中斷下半部的處理函數，若沒有則進行任務調度恢復處理器到任務空間執行。
中斷下半部的核心是中斷下半部的管理函數OSDo-Sirq()。它的功能是檢查中斷下半部的狀態變量，依據優先級順序選擇就緒的下半部服務程序順序執行，并且對相應的下半部狀態進行修改，最后跳轉到下半部的出口函數。出口函數OSSirqExit()使處理器完成從中斷空間到任務空間的轉換。至此，中斷服務全部完成，用戶任務得以繼續執行。
本設計使用softirq來指中斷下半部的服務程序。中斷下半部支持最多32個具有不同靜態優先級的softirq。中斷優先級范圍為0～31，O是最高優先級，31是最低優先級。這里引入了優先級的思想，因為上半部服務程序可能需要對應的softirq來完成延后的任務，類似的softirq也應有不同的優先級來標識它們先后的運行順序。而采用靜態實現的目的是為了實時性和穩定性的考慮，若采用動態實現，代價是可能產生內存碎片和更多的處理器資源損耗。每一個softirq都有對應的標志變量來標識它的使能、屏蔽和就緒的狀態。一組具有明確功能定義的API用于softirq的注冊、屏蔽和使能等功能。
一般情況下，中斷服務程序是不會重入的，因為絕大多數處理器會在中斷執行時禁止中斷，至少是禁止同級和更低優先級的中斷。本設計的中斷下半部同樣不要求softirq具有可重入性，因為在下半部的實現中已通過巧妙的設計消除了重入的可能性。softirq遵循μC／OS―II對編寫中斷服務程序的限制要求，例如中斷服務函數不能執行可能會導致任務阻塞的函數等，在此不再贅述。

2 中斷下半部的實現
基于操作系統設計全局的考慮，中斷下半部的實現應遵循以下幾點原則：
①中斷下半部也將運行于中斷空間，這意味著任務空間的所有任務都要被阻塞。中斷下半部與中斷上半部(即中斷服務程序)一個根本的不同是：中斷下半部允許中斷。
②盡量對原μC／0S―II體系結構做最小化的修改，如任務調度機制、任務空間的各種保護和同步機制等。改動所涉及的范圍越大，引入bug的可能性也越大。在所增加的代碼中盡量利用原μC／0S―II提供的系統調用，如開關中斷還有任務調度等函數，這樣兼顧了效率和安全性。
③盡量減少使用平臺相關性代碼，保證μC／OS―II的可移植性。
④設計簡潔明確的API接口，以方便其他開發者能夠輕松使用這種機制。
根據中斷下半部的設計方案，其實現分為以下4個主要的模塊。
2．1 中斷下半部入口的實現
μC／OS―II核心代碼os_core．c中的OSIntExit()函數是μC／OS―II中斷處理程序的出口。為了實現中斷下半部的入口，應將OSIntExit()函數中if((OSIntNesting=0)(OSLockNesting==O))語句以下列代碼來代替：

第1條if語句判斷是否所有中斷服務程序都已經結束，注意這里也包括softirq。因為在進入下半部管理函數后會執行OSIntNesting++，若softirq正在執行則OSInt-Nesting一定大于O。這個簡單的if判斷語句消除了soft―irq的重入的可能性。判斷條件為真后，繼續判斷全局變量softirq_flag，若其值為SOFTIRQ_ENABLE則啟用中斷下半部。全局變量softirq_stat可能的值有3個：
①SOFTIRQ_READY，說明有就緒的softirq等待運行；
②SOFTIRQ_RUNNING，說明softirq正在被調度但其狀態可能為被中斷態；
③SOFTIRQ_NONE，說明沒有softirq處于就緒狀態。

此判斷語句條件為真時，函數OSIntCallSirq()將會保存被中斷任務的上下文，初始化中斷下半部堆棧指針，并執行下半部管理函數OSDo-Sirq()。若判斷結果為假，則中斷處理返回被中斷的語句繼續執行。而這條語句可能為中斷下半部的代碼，也可能為任務空間的代碼。0S―IntCallSirq()是一段具有平臺相關性的匯編代碼，在不同的處理器平臺上有不同的實現代碼，其流程如圖2所示。

2．2 下半部管理函數OSDoSirq()的實現
這是中斷下半部實現的核心部分。其代碼如下：

首先，通過使用OSIntNesting++以防止softirq的重入，設置softirq_stat的值為S0FTIRQ_RUNNING以標識softirq在執行。通過檢查softirq_pending的值來判斷是否還有就緒的softirq等待執行。
然后，利用INTS_0N()顯示允許中斷，并執行getHighPrioSirq()函數快速地判斷已就緒最高優先級的softirq的序號。getHighPrioSirq()利用了PendingMap[]數組實現了以空間換時間的思想，能夠快速計算出一個32位無符號整數中最低一位“1”的序號。PendingMap口是有256個INT32U類型數據的數組，PendingMap[temp]的值就是以二進制表示的8位無符號整數temp中最低一位“1”的序號。getHighPrioSirq()判斷一個32位整型無符號數中最低一位“1”的序號，最多只要經過4次與操作和移位操作。所以，getHighPrioSirq()是一個非常快速的函數，不會給處理器帶來明顯的負擔。
softirq[]是中斷下半部服務函數指針數組，它內含32個數據對應不同的32個softirq。(*softirq[num])()會將PC設為第num個服務函數的入口地址，從而執行這個服務函數。執行完成后立即關閉中斷并清除這個softirq的就緒標志。
當所有的就緒softirq執行完成后，設置softirq_stat為SOFTIRQ_NONE，執行OSIntNesting一一，并調度下半部出口函數OSSirqExit()離開中斷下半部。
2．3 中斷下半部出口函數OSSirqExit()的實現
OSSirqExit()將首先判斷OSLockNesting的值，若為O，則執行OSStartHighRdy()調度執行已就緒的最高優先級的任務；若非0，則執行OSResumeCur()調度執行被中斷的任務，如圖3所示。以上兩個函數都會從對應任務的堆棧中恢復出任務的上下文，使得處理器返回到任務空間。

2．4 通過API使用中斷下半部
本設計的中斷下半部提供了以下API，供開發者使用這種機制：

這個調用將使當前任務阻塞并立即切換到中斷下半部執行softirq的系統調用。開發者可能希望在開啟中斷并且禁止任務調度的情況下執行某個任務(利用softirq，這很容易做到)，并且對實時響應外部中斷無任何影響。這個調用實現的功能類似于模擬一個中斷的發生。
以上API接口均經過良好的設計，功能定義明確，實現代碼短小精悍，所有帶返回值的函數在遇到參數錯誤的情況下，能返回相應的錯誤信息以有利于開發者調試。

3 測試中斷下半部對實時性的貢獻
3．1 測試平臺及測試方法說明
測試采用三星公司基于ARM7核的S3C44BOX處理器，其工作在66 MHz的頻率。μC／OS―II版本號為2．85。用處理器內部的定時器在調試環境下進行時間測試，因為調試環境下可以通過設置斷點，快速、準確地查看定時器的當前值。
測試方法：使用中斷下半部對一個中斷服務的典型應用進行修改，分別測試修改前和修改后的中斷響應中關閉中斷的時間，并對比關閉中斷時間來說明實時性。
3．2 測試中斷下半部屏蔽中斷的時間
主要函數屏蔽中斷的時間如表1所列。

從表1可以看出，在中斷下半部入口函數OSIntExit()中所增加的代碼給內核增加了約6．2μs的關中斷時間，中斷下半部管理函數OSDoSirq()給內核增加了約3．5μs的關中斷時間，中斷下半部出口函數OSSirqExit()屏蔽中斷的時間約為4．4μs。經過計算，一次完整的中斷下半部處理增加了約14．1μs的關中斷時間。
3．3 測試中斷下半部縮短中斷關閉的時間
Uart_Printf()為常用的串口打印函數，其常用于滿足特定條件時通過串口打印信息。很多開發者喜歡在中斷服務程序中使用它，所以，僅僅包含一句Uart_Printf()的中斷服務程序，可以被認為是一個普遍而簡單的應用。下面給出針對只包含一句Uart_Printf()的中斷服務程序進行測試的結果。
中斷上半部除設置中斷相關寄存器指令外，僅包含一條Uart_Printf(“real-time test＼n”)，其通過串口發送一串字符。通過S3C44BOX內部定時器測試得到，CPU從中斷觸發到回到任務空間繼續執行所花的時間為970μs，在這段時間內所有中斷都被屏蔽。
若在中斷服務程序中使用OSRegSirq()注冊softirq，將Uart_Printf(“real―time test＼n”)轉移到中斷的下半部執行，這時從中斷發生到回到任務空間繼續執行所花的時間為990 μs。總的運行時間雖然增加了20μs；但在此過程中，中斷僅僅被屏蔽了30．6μs，剩下的959．4μs時間里，所有的中斷屏蔽都被開啟。可見，將一句簡單的Uart_Printf(“real―time test＼n”)移到中斷下半部執行就能夠節省939．4μs的中斷屏蔽時間。
3．4 測試結果分析
通過以上的測試結果可以看出：中斷下半部為μC／0S-II內核帶來的負擔極小，一次完整的中斷上／下半部處理時間延長了約20μs，而關中斷時間增加了約14．1μs；通過測試一個簡單而普遍的中斷服務應用，并采用中斷下半部實現，縮短了中斷關閉時間約939．4μs，這相當于94．9％的中斷響應的總耗時。如果粗略地以中斷屏蔽時間來衡量系統的實時性，這個測試中，使用中斷下半部將實時性提高了約32倍。若對更加復雜的中斷服務程序使用這種機制來進行設計，則實時性的提高將更為顯著。因此，采用中斷下半部將極大地縮短中斷服務處理中屏蔽中斷的時間，這對于實時系統的意義不言而喻。

結 語
中斷上／下半部的層次化處理機制為開發者提供了一種靈活、便捷的中斷服務程序的設計方法。通過合理利用中斷下半部，中斷上半部的執行時間將明顯縮短，中斷被屏蔽的時間也會大大減少，處理器可以更快地響應中斷，從而將大大減小丟失中斷信號的可能性。
本設計實現了基于μC／OS-II的中斷下半部。這種機制的實現充分利用了μC／0S―II的現有資源，代碼簡潔而高效，且與平臺相關性代碼極少，方便移植。一組功能定義明確的API極大地方便了開發者使用這種機制。通過在ARM7處理器上的測試表明，這種機制極大地改良了原μC／OS―II內核簡陋的中斷處理方式，給μC／OS―II內核帶來的負擔極小，卻能為使用μC／OS―II的開發者帶來極大的益處，對于嵌入式系統整體實時性的提高具有重要意義。