μC/OS-II的實時性能分析

摘要：簡單介紹一種公開源代碼的實時操作系統μC/OS-II，並對它的實時性能進行簡單的測試。通過改變測試條件，如改變中斷的類型或中斷髮生時系統的狀態等，分析μC/OS-II在中斷時的中斷響應時間與各種條件之間的關係，從而為分析或改善實時操作系統的中斷響應時間提供理論依據。
關鍵詞：RTOS μC/OS-II 中斷響應時間 實時性能
引 言
1 嵌入式實時操作系統和μC/OS-II
　　嵌入式操作系統EOS(Embedded Operating System)主要負責嵌入式系統的全部軟、硬體資源的分配、調度、控制、協調併發活動;它必須體現其所在系統的特徵，能夠通過裝卸某些模塊來達到系統所要求的功能[1]。
　　μC/OS-II是專門為計算機的嵌入式應用而設計的實時操作系統，是基於靜態優先順序的佔先式（preemptive）多任務實時內核。採用μC/OS-II作為測試的目標，一方面是因為它已經通過了很多嚴格的測試，被確認是一個安全的、高效的實時操作系統；另一個重要的原因，是因為它免費提供了內核的源代碼，通過修改相關的源代碼，就可以比較容易地構造自己所需要的測試環境，實現自己需要的功能。
2 實時操作系統和系統實時性能指標
　　實時系統對邏輯和時序的要求非常嚴格，如果邏輯和時序出現偏差將會引起嚴重後果。實時系統有兩種類型：軟實時系統和硬實時系統。軟實時系統僅要求事件響應是實時的，並不要求限定某一任務必須在多長時間內完成；而在硬實時系統中，不僅要求任務響應要實時，而且要求在規疾的時間內完成事件的處理。通常，大多數實時系統是兩者的結合。
　　事實上，沒有一個絕對的數字可以說明什麼是硬實時，什麼是軟實時。它們之間的界限是十分模糊的。這與選擇什麼樣的CPU，它的主頻、內存等參數有一定的關係[1]。另外，因為應用的場合對系統實時性能要求的不同而有不同的定義。因此，在現有的固定的軟、硬體平台上，如何測試並找出決定系統實時性能的關鍵參數，並給出優化的措施和試驗數據，就成為一個具有普遍意義並且值得深入探討的課題。本文就是基於此目的進行討論的。
　　因為採用實時操作系統的意義就在於能夠及時處理各種突發的事件，即處理各種中斷，因而衡量嵌入式實時操作系統的最主要、最具有代表性的性能指標參數無疑應該是中斷響應時間了。中斷響應時間通常被定義為：
　　中斷響應時間=中斷延遲時間+保存CPU狀態的時間+該內核的ISR進入函數的執行時間[2]。
　　中斷延遲時間=MAX(關中斷的最長時間，最長指令時間) + 開始執行ISR的第一條指令的時間[2]。
　　通俗點定義就是：從中斷髮生起，到執行中斷處理程序的第一條指令所用的時間。由於實時操作系統更多考慮的是最壞的情況，而不是平均的情況，因此指令執行的時間就按照最長的指令執行時間來計算，所以中斷延遲時間，通常是由關中斷的最長時間來決定的。當FIQ（快速中斷）使能時，最壞情況下FIQ的中斷延遲時間由以下幾個部分構成：
　　t同步——請求通過同步器的最長時間，約4個處理器周期。
　　t最長指令時間——最長指令完成的時間。最長指令是載入包括PC的所有寄存器的LDM指令，在零等待狀態的系統中，約為20個周期。
　　t異常——數據異常進入時間，為3個周期。
　　tFIQ——FIQ進入時間， 2個周期。
　　最大的FIQ中斷延遲時間約為29個時鐘周期。在系統使用40 MHz處理器時鐘時，約為0.7 μs。
　　對於最大的IRQ延遲，其計算與FIQ類似。若必須允許FIQ有更高的優先順序，那麼進入IRQ處理程序的延遲時間是隨機的[3]。
3 試驗原理和測試方法
　　首先需要啟動並開始運行μC/OS-II，因為試驗需要使用的計時函數是系統函數。進行堆棧和中斷向量等系統初始化后，首先要創建一個任務，用以產生中斷。這樣OS啟動后，中斷服務程序可以在任務中調用或者切換，中斷源可以設置為外部中斷或由任務產生。在主程序的臨界段循環查詢中斷狀態（VICRawIntr;中斷狀態寄存器），一旦發現有中斷標識，則立即啟動計數器，並使能該中斷，跳出臨界段（在進入臨界段之前要關中斷(OS_ENTER_CRITICAL())，而跳出臨界段代碼進入中斷服務子程序后，保存全部CPU寄存器后清除中斷源，並立即開中斷(OS_EXIT_CRITICAL())，然後停止計時並執行中斷處理代碼）。由於是在檢測到中斷標識后才跳出臨界段，所以一跳出臨界段就會立即發生中斷，進行中斷處理。保存了CPU寄存器後進入中斷服務的第一條指令就是保存計數器值。由於在跳出臨界段時才啟動的計數器，而在進入中斷服務時立即保存了計數值，所以這個計數值就是所需要的中斷響應時間。

　　如果要測試不同類型的中斷響應時間，可以在程序中，分別使用不同類型的中斷（向量中斷，非向量中斷，快速中斷）來測試中斷類型對中斷響應時間的影響。原則上快速中斷（FIQ）要求具有最高的優先順序，而且快速中斷的處理與操作系統基本無關，中斷服務子程序可以自行編寫（在不調用μC/OS-II的系統服務程序的情況下），沒有特別的要求。向量中斷則不能如此。因為雖然ADS可以使用_irq關鍵字來聲明一個函數是用來處理中斷的，從而可以避免在程序中使用彙編代碼，但是在μC/OS-II中不能這樣處理。因為使用C語言無法確保堆棧的結構，而RTOS必須使堆棧保持一定的結構。這隻有彙編語言可以做到。這部分的代碼在文件VECTORS.S中（為了簡化用戶編寫中斷服務子程序，這段彙編代碼已經被編寫成一個宏HANDLER）[4]。具體可見參考文獻[4]的P358~P359中所列的程序清單6.5中的彙編代碼，即中斷服務子程序必須按照 μC/OS-II的中斷服務程序的要求編寫，格式如下[4]：
保存全部CPU寄存器;(1)
調用OSIntEnter或OSIntNesting直接加1；(2)
清除中斷源(3)
重新開中斷(4)
執行用戶代碼做中斷服務;(5)
調用OSIntExit()；(6)
恢復所有CPU寄存器；（7）
執行中斷返回指令；（8）
　　如果要測試存儲器加速模塊對中斷響應時間的影響，可以在關閉、部分使能和完全使能3種設置下分別測試同一個中斷的響應時間，從而得出中斷響應時間與存儲器加速模塊設置之間的關係。