μC／OS -III為縮短中斷關閉時間作出的改進

諶普江，龔光華，宮輝，邵貝貝

（1.清華大學 工程物理系，北京 100084；2.清華大學 粒子技術與輻射成像教育部重點實驗室；3.清華大學 飛思卡爾培訓中心）

引 言

μC／OS－III是一款全新的實時內核，源于世界上流行的實時內核μC／OS－II。較μC／OS－II，μC／OS－III做了很多改進。其中，很重要的一點就是為了縮短中斷關閉時間作出的改進。本文將深入分析為什么這些改進能夠使得μC／OS－III的實時性能得到提升。

1 中斷簡介

所謂中斷，其實就是一種硬件機制，用于通知CPU有一個異步事件發生了。由于μC／OS－III是面向以ARM Cortex為代表的高端32位CPU的，因此，本文將以ARM Cortex－M3為例來介紹一般CPU對中斷的處理。

如圖1所示，中斷控制器NVIC和ARM Cortex－M3 CPU緊密合作完成中斷的處理。中斷控制器NVIC負責接收所有的中斷請求。NVIC會把當前優先級最高的中斷請求的服務地址傳遞給CPU。Cortex－M3CPU在確認中斷后，會自動將R0～R2、R12～R15入棧保存［1］，并跳轉執行中斷服務程序。中斷服務程序執行完后，R0～R2、R12～R15會自動出棧。

圖1 ARM Cortex M3中斷處理示意圖

通過對中斷的處理，CPU能夠在外部事件發生的時候立刻進行處理，從而滿足系統的實時性要求。在一些特殊情況下，CPU需要通過特殊的指令來關中斷。然而，需要引起特別注意的是，關中斷會增加中斷延遲時間，可能導致后續的中斷請求丟失。嵌入式系統中斷源眾多，對實時性要求高，中斷關閉的時間越短越好，中斷處理程序運行時間越短越好。中斷關閉時間的長短是實時內核最重要的一個指標。

2 μC／OS -III作出的改進

在μC／OS－III中，如果一個中斷對應的事件不需要任務知道，不需要給任務發送信號或者消息，推薦用戶把這個中斷寫成無需內核參與的中斷；如果這個中斷需要給任務發送信號或者消息，用戶可以選擇直接發布或者延遲發布這兩種發布模式中的一種。

2.1 無需內核參與的中斷

在很多情況下，中斷需要做的處理非常簡單，比如一些I／O中斷，并不需要內核知道。這種情況下典型的無需內核參與的中斷服務程序示意代碼如下：

在無需內核參與的中斷服務程序中（1）處不要開中斷，因為開中斷后，其他中斷可能嵌套，也可能調用μC／OS－III的內核函數，導致調度回到高優先級任務繼續執行。而內核并不知道有這個中斷，所以這個中斷的完成時間將會變得特別長。

筆者建議，I／O中斷處理程序最好使用這種方式。另外，在ARM Cortex－M3中，因為R0～R2是自動入棧和出棧的，簡單的I／O處理中斷盡量只使用R0～R2，這樣可以省掉中斷服務程序中保存和恢復寄存器的步驟，縮短了中斷服務程序的運行時間。

2.2 需要內核參與的中斷

一個中斷對應的事件正好是一個任務正在等待的事件，這意味著這個中斷需要向對應的任務發送信號或者消息。μC／OS－III由中斷向任務發送信號或者消息有兩種模式。這兩種模式分別為直接發布（Direct Post）和延遲發布（Deferred Post）模式。所謂直接發布，是指在中斷服務函數中調用各種post函數時，會立即完成post操作；而延遲發布，是指在中斷服務函數中調用各種post函數時，不會立即完成post操作，該操作會被緩存起來。

在分析μC／OS－III的這兩種發布模式之前，先看看μC／OS－III中典型的需要內核參與的中斷服務程序的結構。需要內核參與的中斷服務程序［1］示意性代碼如下：

2.2.1 直接發布

μC／OS－II中使用的是直接發布模式，μC／OS－III中保留了這個模式。

圖2為直接發布模式的示意圖，當一個外設產生中斷，并向CPU發出中斷請求，然后CPU執行中斷服務程序。這個需要內核參與的中斷服務程序在示意性代碼標志（1）這個步驟中，將會調用 OSSemPost（）、OSTaskSem－Post（）、OSFlagPost（）、OSQPost（）和 OSTaskQPost（）這5個發布函數其中的一個給任務發消息或信號，并且這些post操作會被立即執行，使得正在等待這個中斷發生的任務進入就緒狀態。

圖2 直接發布示意圖

在需要內核參與的中斷服務程序示意性代碼標志（2）中，調用OSIntExit（），OSIntExit（）中會調用 OSIntCtxSw（）進行任務調度。然后系統將執行更高優先級的任務或者之前被中斷的任務。

在直接發布模式下，中斷服務程序會直接執行post操作。而這些post操作會訪問μC／OS－III中的很多臨界段代碼，因此μC／OS－III必須通過關中斷來保護系統中會被上述post操作所訪問到的臨界段代碼，這樣無疑會增加中斷關閉的時間。中斷關閉時間的增加會導致實時內核的實時性能降低。

2.2.2 延遲發布

在詳細研究延遲發布模式之前，必須先了解μC／OSIII中兩個新的概念。

（1）中斷隊列

中斷隊列類似于一個堆棧，它專門用來保存發布函數調用操作以及與這個調用相關的參數。

（2）中斷隊列處理任務

中斷隊列處理任務是μC／OS－III中一個新的內部任務，它具有最高的優先級（優先級0）。這個任務專門用來處理中斷隊列。

圖3為延遲發布模式的示意圖，一個外設產生中斷，并向CPU發出中斷請求，然后CPU執行中斷服務程序。

圖3 延遲發布模式示意圖

與直接發布模式不同的是，這個中斷服務程序調用發布函數給任務發布消息或信號時，系統不會立即執行這些post操作，而是將這些post函數的調用以及相應的參數寫入中斷隊列中，并且使中斷隊列處理任務進入就緒態。

舉例說明，μC／OS－III中，中斷服務程序給任務發送信號量時，調用OSSemPost（）函數。在OSSemPost（）函數中，系統先判斷是什么發布模式。如果是延遲發布模式，則調用OS＿IntQPost（），OS＿IntQPost（）用來將 OSSem－Post（）函數的調用和相應的參數寫入中斷隊列并使得中斷處理任務進入就緒態；如果是直接發布模式，則調用OS＿SemPost（），這個函數用來執行信號量的post操作。OSSemPost（）函數的部分源碼如下：

然后，中斷服務程序執行 OSIntExit（），OSIntExit（）中調用OSIntCtxSw（）執行任務調度。由于中斷隊列處理任務優先級最高，μC／OS－III將執行中斷隊列處理任務。該任務從中斷隊列中提取出發布函數調用信息，此時仍需要關閉中斷，以防止中斷服務程序同時對中斷隊列進行訪問。中斷隊列處理任務提取出發布函數調用的信息后重新開中斷，并且鎖定任務調度器，然后進行發布函數調用，相當于發布函數調用一直在任務級代碼中進行。

這個中斷隊列處理任務將中斷隊列一一處理完后，將自身掛起，并重新啟動任務調度來運行當前處于最高優先級的就緒任務。

由于延遲發布模式下，μC／OS－III的中斷服務程序不會直接進行post操作。所以μC／OS－III中那些能夠被post操作所訪問的臨界段代碼不需要進行關閉中斷的操作，只需要禁止任務調度就行。這將使得系統關中斷時間大大縮短。

延遲發布模式下，用最高優先級的中斷隊列處理任務來處理需要做任務調度的中斷，在保護了臨界段代碼的同時，又保持了中斷的快速響應和處理。中斷服務程序不需要進行post操作，從而縮短了中斷服務程序的時間。

2.2.3 模式選擇

直接發布模式和延遲發布模式最主要的區別在于中斷關閉時間。延遲發布模式很大程度上縮短了中斷關閉時間和中斷程序的運行時間，但是卻增加了任務的延時。

應用中如果存在要求響應非常迅速的中斷源，用戶應該選擇延遲發布模式，因為用直接發布模式很有可能無法處理。

另外，由于μC／OS－III中，相同優先級下的多任務、事件標志組、等待多個內核對象、調用廣播方式發布這4個特性都會導致臨界段代碼變長。如果應用中用到了這些特性，應該使用延遲發布模式。

如果應用中不存在要求響應非常迅速的中斷源，也沒有用到以上幾種特性，用戶可以使用直接發布模式，即μC／OS－II模式，否則還是建議用戶盡量使用延遲發布模式。

選擇μC／OS－III的發布模式非常簡單，只需要在OS＿cfg.h中設置OS＿CFG＿ISR＿POST＿DEFERRED＿EN的值即可，對應用程序和中斷服務程序，代碼不需要做任何改動：置0，為直接發布模式；置1，為延遲發布模式。

2.2.4 實驗結果比較

筆者在PK10N512VLL100上移植了μC／OS－III，這是Freescale公司的一款基于ARM Cortex－M4核的微控制器。通過一些簡單的小實驗來分析直接發布模式以及延遲發布模式下，中斷關閉時間的對比。實驗中通過啟動系統的統計任務stat＿task，然后讀取系統的全局變量OSIntDisTimeMax來獲取系統的最大中斷關閉時間。

整個實驗用控制LED的閃爍任務來實現4種不同的實驗條件。第1種，只有一個初始化任務，用來初始化硬件和控制LED的閃爍；第2種，有一個初始化任務（初始化硬件）和兩個優先級一樣的用戶任務（分別控制兩個不同的LED周期閃爍）；第3種，有一個初始化任務（初始化硬件）和4個優先級一樣的用戶任務（分別控制4個不同的LED周期閃爍），并且沒用到廣播消息的功能；第4種，有一個初始化任務（初始化硬件）和4個優先級一樣的用戶任務（分別控制4個不同的LED周期閃爍），并且實驗中用到了廣播消息的功能（初始化任務向4個優先級一樣的用戶任務廣播消息）。

表1是實驗結果，表中的最大中斷關閉時間的單位為系統的時鐘周期數，實驗中系統的時鐘為100MHz。

從以上實驗結果可以看出，4種實驗條件下，延遲發布模式的最大中斷關閉時間基本保持恒定。而直接發布模式下，系統的任務越多，功能越復雜，最大中斷關閉時間也越來越長。并且，在相同條件下，直接發布模式的最大中斷關閉時間比延遲發布模式大很多。

表1 實驗結果

結 語

相對于μC／OS－II，μC／OS－III在縮短中斷關閉時間方面作出了突出的改進。首先，用戶可以根據中斷的類型使用無需內核參與的中斷服務程序和需要內核參與的中斷服務程序，盡最大可能減少中斷程序的運行時間。另外，新增了由中斷給任務發送信號或消息的延遲發布模式。該模式有效地縮短了中斷關閉的時間和中斷程序的運行時間，提高了系統的實時性。

［1］Joseph Yiu.ARM Cortex－M3權威指南［M］.宋巖，譯.北京：北京航空航天大學出版社，2009.

［2］Labrosse Jean J.μC／OS－III the Real Time Kernel［M］.Weston：Micriμm Press，2011.