引 言
μC／OS-II操作系統是建立在微內核基礎上的實時操作系統，搶占式多任務、微內核、移植性好等特點，使其在諸多領域都有較好的應用。
在μC／OS-II 2．83及其以后的版本中，一個較大的變化就是增加了對軟件定時器的支持。這使得μC／OS實時操作系統的功能更加完善，在其上的應用程序開發與移植也更加方便。在實時操作系統中一個好的軟件定時器實現要求有較高的精度、較小的處理器開銷，且占用較少的存儲器資源。本文在對μC／OS-II定時器算法分析的基礎上，對定時精度和處理器占用情況進行了分析與測試，其結果在實時系統的設計與應用中具有借鑒意義。
1 定時器實現架構
在μC／OS-II操作系統內部，任務的延時功能及軟件定時器功能，都需要底層有一個硬件的計數器支持。硬件計數器以固定的頻率遞減，計數到0時，觸發時鐘中斷。這個特定的周期性的中斷稱為“時鐘節拍”。每當有時鐘節拍到來時，系統在保存現場和中斷嵌套計數加1后都會跳到時鐘節拍函數OSTimTick()中，進行軟件計數器加1和遍歷任務控制塊，以判斷任務延時是否到時。
μC／OS-II中并未在 OSTim Tick()中進行定時器到時判斷與處理，而是創建了一個高于應用程序中所有其他任務優先級的定時器管理任務OSTmr_Task()，在這個任務中進行定時器的到時判斷和處理。時鐘節拍函數通過信號量給這個高優先級任務發信號。這種方法縮短了中斷服務程序的執行時間，但也使得定時器到時處理函數的響應受到中斷退出時恢復現場和任務切換的影響。軟件定時器功能實現代碼存放在tmr．c文件中，移植時需只需在os_cfg．h文件中使能定時器和設定定時器的相關參數。
2 μC／OS-II的軟件定時器算法分析
μC／OS-II中軟件定時器的實現方法是，將定時器按定時時間分組，使得每次時鐘節拍到來時只對部分定時器進行比較操作，縮短了每次處理的時間。但這就需要動態地維護一個定時器組。定時器組的維護只是在每次定時器到時時才發生，而且定時器從組中移除和再插入操作不需要排序。這是一種比較高效的算法，減少了維護所需的操作時間。
2．1 定時器管理所需的數據結構
一旦定時器被建立，一個定時器控制塊(OS_TMR)就被賦值了。定時器控制塊是定時器管理的基本單元，包含定時器的名稱、定時時間、在鏈表中的位置、使用狀態、使用方式，以及到時回調函數及其參數等基本信息。
在μC／OS-II軟件定時器中實現了3類鏈表的維護：
OSTmrTbl[OS_TMR_CFG_MAX]：以數組的形式靜態分配定時器控制塊所需的RAM空間，并存儲所有已建立的定時器控制塊。
OSTmrFreeLiSt：為空閑定時器控制塊鏈表頭指針。空閑態的定時器控制塊(OS_TMR)中，OSTmrnext和OSTmrPrev兩個指針分別指向空閑控制塊的前一個和后一個，組織了空閑控制塊雙向鏈表。建立定時器時，從這個鏈表中搜索空閑定時器控制塊。
OSTmrWheelTbl[OS_TMR_CFG_WHEEL_SIZE]：該數組的每個元素都是已開啟定時器的一個分組，元素中記錄了指向該分組中第一個定時器控制塊的指針，以及定時器控制塊的個數。運行態的定時器控制塊(OS_TMR)中，OSTmrnext和OSTmrPrev兩個指針同樣也組織了所在分組中定時器控制塊的雙向鏈表。定時器管理所需的數據結構示意圖如圖1所示。
2．2 軟件定時器實現原理
宏OS_TMR_CFG_WHEEL_SIZE定義了OSTmr-WheelTbl[]數組的大小，同時這個值也是定時器分組的依據。按照定時器到時值與OS_TMR_CFG_WHEEL_SIZE相除的余數進行分組：不同余數的定時器放在不同分組中；相同余數的定時器處在同一組中，由雙向鏈表連接。這樣，余數值為0～OS_TMR_CFG_WHEEL_SIZE-1的不同定時器控制塊，正好分別對應了數組元素OSTmr-WheelTbl[0]～OSTmrWheelTbl[OS_TMR_CFGWHEEL_SIZE-1]的不同分組。每次時鐘節拍到來時，時鐘數OSTmrTime值加1，然后也進行求余操作，只有余數相同的那組定時器才有可能到時，所以只對該組定時器進行判斷。這種方法比循環判斷所有定時器更高效。隨著時鐘數的累加，處理的分組也由0～OS_TMR_CFG_WHE EL_SIZE-1循環。
信號量喚醒定時器管理任務，計算出當前所要處理的分組后，程序遍歷該分組中的所有控制塊，將當前OSTmr-Time值與定時器控制塊中的到時值相比較。若相等(即到時)，則調用該定時器到時回調函數；若不相等，則判斷該組中下一個定時器控制塊。如此操作，直到該分組鏈表的結尾。定時器管理任務的流程如圖2所示。OS_TMR_CFG_WHEEL_SIZE的取值推薦為2的N次方，以便采用移位操作計算余數，縮短處理時間。
2．3 定時器移除和插入操作
定時器的到時處理函數返回后，都要進行該定時器控制塊在鏈表中的移除和再插入操作。插入前需要重新計算定時器下次到時時所處的分組。計算公式如下：
定時器下次到時的OSTmrTime值=定時器定時值+當前OSTmrTime值
新的分組=定時器下次到時的OSTmrTime值％OS_TMR_CFG_WHEEL_SIZE
3 定時器精度與抖動
在μC／OS-II操作系統中，與定時相關的功能均基于系統的時鐘節拍。系統每秒的時鐘節拍數決定了這個系統能分辨的最小時間，定時值只能為最小時間的倍數。每秒的時鐘節拍數由os_cfg．h．文件中的宏OS_TICKS_PER_SEC定義。對于不同的應用，該時鐘節拍一般在10～100次／s的范圍內選取。其對應的時鐘中斷的時間間隔為100～10 ms，即時間的最小分辨單位為10 ms。處理器處理能力越高，每秒的時鐘節拍數也相應地越大。下面的數據測試中使用了ARM9處理器。最低運行頻率為250 Hz時，時鐘節拍設為200次／s，可進行正常的多任務調度。該測試環境下，最小分辨時間為5 ms。
抖動是指定時器回調函數開始執行的時間與規定的時間相比，或提前或推后的現象。在定時器中抖動總是存在的。下面主要分析2種抖動情況及其對定時精度的影響。第1種抖動情況如圖3所示。
T1：CPU響應時鐘中斷，搜索中斷號，保存中斷現場并跳到時鐘中斷處理程序OSTimTick的時間。
T2：OSTimTick()函數的執行時間。該函數中對任務延時是否到期進行了判斷。
T3：恢復現場，退出中斷并進行任務上下文切換的時間。
T4：定時器管理任務OSTmr_Task()判斷定時器是否到時的時間。
T4之后：定時器到時回調函數開始執行。 在CPU運行頻率固定的情況下T1和T3的執行時間是相對固定的，而且一般為匯編語言實現，運行速度也較快。而T2和T4的時間會隨著任務和軟件定時器數量的增多有所增加。測試時定時器定時值隨機選取。表1中的時間為不同處理器頻率下，定時器個數為1和5時觀測到的最大值。其中，T=T1+T2+T3+T4。
由測試數據可知，若有定時器到時，則經過幾個μs的延時，定時器回調函數就可以執行。與ms級的定時最小分辨時間相比，其抖動對到時準確性的影響是非常小的。隨著處理器頻率的提升和處理能力的加強，這個抖動時間還可以進一步縮小。第2種抖動情況如圖4所示。
當下一個時鐘節拍快到來時(如圖4中A時刻)，一個定時器被開啟了。因為系統能分辨的最小時間即時鐘節拍的間隔時間，所以定時器開啟時記錄的當前時鐘節拍數為1，假設定時器的定時值就是一個時鐘節拍間隔。定時器開啟后，第2個時鐘節拍馬上就到了，由情況1的分析可知，這個定時器的回調函數很快就會被執行。B時刻表示這個定時器回調函數第一次執行。C、D時刻為回調函數的第2次與第3次執行時刻，這兩次到時是比較準確的。
因此，定時器從開啟到回調函數開始執行的時間與定時值相比是有較大抖動的。若此時的時鐘節拍間隔為5 ms，則這個抖動的誤差最大即5 ms。這種情況下的抖動只能通過提高每秒的時鐘節拍數來減小。因此，在數據采集或其他定時器的應用中，要留意定時器開啟后第一次到時的處理，以免進行錯誤的判斷。
4 定時器管理任務對操作系統性能的影響
定時器管理任務的運行使應用程序可建立的任務數減1。該任務要求是系統中的最高優先級，因此每次有時鐘中斷發生它都要運行，必然會消耗掉一定的CPU資源。軟件定時器功能所占用的CPU運行時間(設為M)的計數公式為：
M=定時器管理任務判斷定時器是否到時的時間+定時器回調函數執行時間+定時器控制塊移除
與再插入時間+切換到次低優先級任務的時間
首先，采用μC／OS-II中自帶的統計任務測試定時器管理任務對CPU資源的占用情況。測試時系統中開啟3個任務：定時器管理任務、統計任務和Idle任務。定時器到時回調函數在定時器管理任務中執行，增加了管理任務運行時間。為僅測試系統定時器管理功能的開銷，測試時將定時回調函數置為空操作。因統計任務要求必須在初始化時建立第一個也是唯一的一個任務中調用統計任務初始化函數OSStatInit()，所以需在定時器管理任務中進行必要改動，以保證在統計任務初始化后才開啟定時器的管理功能。測試用定時器在main函數中靜態創建。
測試后發現，當定時器數由1增加到8時，CPU的使用率一直是1％。這說明系統開啟定時器管理功能后，增加的負荷很小。另一方面因為統計任務計算CPU使用率時是整數相除、余數舍棄，這就使得0～(OSIidleCtrMax／100-1)的計數是不能被分辨的，因此統計任務不能準確地反應定時器管理任務對CPU的使用情況。
為了得到更準確的測量結果，采用“處理器占用率”這一指標對管理任務開銷進行測試。
處理器占用率=軟件定時器功能所占用的CPU運行時間(M)／CPU運行時間
當某一時鐘節拍到來時，假設這一時鐘節拍下無定時器到時，即“到時定時器回調函數執行時間”和“定時器控制塊移除與再插入時間”為0。若當前系統中所創建的定時器正好在同一個分組中，則管理任務須對每個定時器的到時值進行比較，此時為無定時器到時時定時器管理任務對CPU的最高占用率。測試中，將定時器的到時值設定為8的倍數加1，在main()函數中靜態創建。使所有定時器控制塊在同一分組中，當OSTime也是8的倍數加1時，就形成了無定時器到時時定時器管理任務的最壞運行情況。
測試環境為：ARM9(400 MHz)，定時器最小分辨時間為5 ms(該值作為計算時的“CPU運行時間”)，硬件計時器的最小分辨時間為0．02μs。讀硬件計時器計算時間，測試結果如表2所列。
由測試數據可知建立定時器數為8時，處理器占用率遠小于1％。每增加一個定時器，定時器管理任務的運行時間約增加6．5μs，處理器的占用率約增加0．01％，任務的切換時間不變。這是在構建的極端情況下測試的，實際應用中的時間要小于這個值。
“定時器控制塊移除與再插入時間”在400 MHz下測試為0．22μs。某一時鐘節拍處理時，若有定時器到時，則最壞情況是這個到時的定時器控制塊在鏈表的最后，只有執行完整個鏈表的判斷后才開始執行該到時定時器的回調函數。假設定時器數為8，且鏈表中最后一個定時器先到時，則該定時器到時的這個鐘節拍下處理器利用率為：(0．34μs+0．22μs+0．82μs+定時器回調函數執行時間)／5 ms=(1．38μs+定時器回調函數執行時間)／5 ms。
結 論
本文對μC／OS-II軟件定時器的算法及抖動問題進行了分析，并在特定平臺上進行了測試，較好地反映出了該定時器的精度和對處理器資源的占用情況。測試結果可信度高，為在μC／OS-II下的軟件定時器應用開發提供了可靠的依據。