由測試數據可知，若有定時器到時，則經過幾個μ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下的軟件定時器應用開發提供了可靠的依據。