μC／OS-II軟件定時器的分析與測試

引 言

μC/OS-II操作系統(tǒng)是建立在微內(nèi)核基礎上的實時操作系統(tǒng)，搶占式多任務、微內(nèi)核、移植性好等特點，使其在諸多領域都有較好的應用。

在μC/OS-II 2.83及其以后的版本中，一個較大的變化就是增加了對軟件定時器的支持。這使得μC/OS實時操作系統(tǒng)的功能更加完善，在其上的應用程序開發(fā)與移植也更加方便。在實時操作系統(tǒng)中一個好的軟件定時器實現(xiàn)要求有較高的精度、較小的處理器開銷，且占用較少的存儲器資源。本文在對μC/OS-II定時器算法分析的基礎上，對定時精度和處理器占用情況進行了分析與測試，其結果在實時系統(tǒng)的設計與應用中具有借鑒意義。

1 定時器實現(xiàn)架構

在μC/OS-II操作系統(tǒng)內(nèi)部，任務的延時功能及軟件定時器功能，都需要底層有一個硬件的計數(shù)器支持。硬件計數(shù)器以固定的頻率遞減，計數(shù)到0時，觸發(fā)時鐘中斷。這個特定的周期性的中斷稱為“時鐘節(jié)拍”。每當有時鐘節(jié)拍到來時，系統(tǒng)在保存現(xiàn)場和中斷嵌套計數(shù)加1后都會跳到時鐘節(jié)拍函數(shù) OSTimTick()中，進行軟件計數(shù)器加1和遍歷任務控制塊，以判斷任務延時是否到時。

μC/OS-II中并未在 OSTim Tick()中進行定時器到時判斷與處理，而是創(chuàng)建了一個高于應用程序中所有其他任務優(yōu)先級的定時器管理任務OSTmr_Task()，在這個任務中進行定時器的到時判斷和處理。時鐘節(jié)拍函數(shù)通過信號量給這個高優(yōu)先級任務發(fā)信號。這種方法縮短了中斷服務程序的執(zhí)行時間，但也使得定時器到時處理函數(shù)的響應受到中斷退出時恢復現(xiàn)場和任務切換的影響。軟件定時器功能實現(xiàn)代碼存放在tmr.c文件中，移植時需只需在os_cfg.h文件中使能定時器和設定定時器的相關參數(shù)。

2 μC/OS-II的軟件定時器算法分析

μC/OS-II中軟件定時器的實現(xiàn)方法是，將定時器按定時時間分組，使得每次時鐘節(jié)拍到來時只對部分定時器進行比較操作，縮短了每次處理的時間。但這就需要動態(tài)地維護一個定時器組。定時器組的維護只是在每次定時器到時時才發(fā)生，而且定時器從組中移除和再插入操作不需要排序。這是一種比較高效的算法，減少了維護所需的操作時間。

2.1 定時器管理所需的數(shù)據(jù)結構

一旦定時器被建立，一個定時器控制塊(OS_TMR)就被賦值了。定時器控制塊是定時器管理的基本單元，包含定時器的名稱、定時時間、在鏈表中的位置、使用狀態(tài)、使用方式，以及到時回調(diào)函數(shù)及其參數(shù)等基本信息。

在μC/OS-II軟件定時器中實現(xiàn)了3類鏈表的維護：

OSTmrTbl[OS_TMR_CFG_MAX]：以數(shù)組的形式靜態(tài)分配定時器控制塊所需的RAM空間，并存儲所有已建立的定時器控制塊。

OSTmrFreeLiSt：為空閑定時器控制塊鏈表頭指針?？臻e態(tài)的定時器控制塊(OS_TMR)中，OSTmrnext和OSTmrPrev兩個指針分別指向空閑控制塊的前一個和后一個，組織了空閑控制塊雙向鏈表。建立定時器時，從這個鏈表中搜索空閑定時器控制塊。

OSTmrWheelTbl[OS_TMR_CFG_WHEEL_SIZE]：該數(shù)組的每個元素都是已開啟定時器的一個分組，元素中記錄了指向該分組中第一個定時器控制塊的指針，以及定時器控制塊的個數(shù)。運行態(tài)的定時器控制塊(OS_TMR)中，OSTmrnext和OSTmrPrev兩個指針同樣也組織了所在分組中定時器控制塊的雙向鏈表。定時器管理所需的數(shù)據(jù)結構示意圖如圖1所示。

2.2 軟件定時器實現(xiàn)原理

宏OS_TMR_CFG_WHEEL_SIZE定義了OSTmr-WheelTbl[]數(shù)組的大小，同時這個值也是定時器分組的依據(jù)。按照定時器到時值與 OS_TMR_CFG_WHEEL_SIZE相除的余數(shù)進行分組：不同余數(shù)的定時器放在不同分組中;相同余數(shù)的定時器處在同一組中，由雙向鏈表連接。這樣，余數(shù)值為0～OS_TMR_CFG_WHEEL_SIZE-1的不同定時器控制塊，正好分別對應了數(shù)組元素OSTmr- WheelTbl[0]～OSTmrWheelTbl[OS_TMR_CFGWHEEL_SIZE-1]的不同分組。每次時鐘節(jié)拍到來時，時鐘數(shù) OSTmrTime值加1，然后也進行求余操作，只有余數(shù)相同的那組定時器才有可能到時，所以只對該組定時器進行判斷。這種方法比循環(huán)判斷所有定時器更高效。隨著時鐘數(shù)的累加，處理的分組也由0～OS_TMR_CFG_WHE EL_SIZE-1循環(huán)。

信號量喚醒定時器管理任務，計算出當前所要處理的分組后，程序遍歷該分組中的所有控制塊，將當前OSTmr-Time值與定時器控制塊中的到時值相比較。若相等(即到時)，則調(diào)用該定時器到時回調(diào)函數(shù);若不相等，則判斷該組中下一個定時器控制塊。如此操作，直到該分組鏈表的結尾。定時器管理任務的流程如圖 2所示。OS_TMR_CFG_WHEEL_SIZE的取值推薦為2的N次方，以便采用移位操作計算余數(shù)，縮短處理時間。

2.3 定時器移除和插入操作

定時器的到時處理函數(shù)返回后，都要進行該定時器控制塊在鏈表中的移除和再插入操作。插入前需要重新計算定時器下次到時時所處的分組。計算公式如下：

定時器下次到時的OSTmrTime值=定時器定時值+當前OSTmrTime值

新的分組=定時器下次到時的OSTmrTime值%OS_TMR_CFG_WHEEL_SIZE

3 定時器精度與抖動

在μC/OS-II操作系統(tǒng)中，與定時相關的功能均基于系統(tǒng)的時鐘節(jié)拍。系統(tǒng)每秒的時鐘節(jié)拍數(shù)決定了這個系統(tǒng)能分辨的最小時間，定時值只能為最小時間的倍數(shù)。每秒的時鐘節(jié)拍數(shù)由os_cfg.h.文件中的宏OS_TICKS_PER_SEC定義。對于不同的應用，該時鐘節(jié)拍一般在10～100次/s的范圍內(nèi)選取。其對應的時鐘中斷的時間間隔為100～10 ms，即時間的最小分辨單位為10 ms。處理器處理能力越高，每秒的時鐘節(jié)拍數(shù)也相應地越大。下面的數(shù)據(jù)測試中使用了ARM9處理器。最低運行頻率為250 Hz時，時鐘節(jié)拍設為200次/s，可進行正常的多任務調(diào)度。該測試環(huán)境下，最小分辨時間為5 ms。[!--empirenews.page--]

抖動是指定時器回調(diào)函數(shù)開始執(zhí)行的時間與規(guī)定的時間相比，或提前或推后的現(xiàn)象。在定時器中抖動總是存在的。下面主要分析2種抖動情況及其對定時精度的影響。第1種抖動情況如圖3所示。

T1：CPU響應時鐘中斷，搜索中斷號，保存中斷現(xiàn)場并跳到時鐘中斷處理程序OSTimTick的時間。

T2：OSTimTick()函數(shù)的執(zhí)行時間。該函數(shù)中對任務延時是否到期進行了判斷。

T3：恢復現(xiàn)場，退出中斷并進行任務上下文切換的時間。

T4：定時器管理任務OSTmr_Task()判斷定時器是否到時的時間。

T4之后：定時器到時回調(diào)函數(shù)開始執(zhí)行。

在CPU運行頻率固定的情況下T1和T3的執(zhí)行時間是相對固定的，而且一般為匯編語言實現(xiàn)，運行速度也較快。而T2和T4的時間會隨著任務和軟件定時器數(shù)量的增多有所增加。測試時定時器定時值隨機選取。表1中的時間為不同處理器頻率下，定時器個數(shù)為1和5時觀測到的最大值。其中，T=T1+T2+T3+T4。

由測試數(shù)據(jù)可知，若有定時器到時，則經(jīng)過幾個μs的延時，定時器回調(diào)函數(shù)就可以執(zhí)行。與ms級的定時最小分辨時間相比，其抖動對到時準確性的影響是非常小的。隨著處理器頻率的提升和處理能力的加強，這個抖動時間還可以進一步縮小。第2種抖動情況如圖4所示。

當下一個時鐘節(jié)拍快到來時(如圖4中A時刻)，一個定時器被開啟了。因為系統(tǒng)能分辨的最小時間即時鐘節(jié)拍的間隔時間，所以定時器開啟時記錄的當前時鐘節(jié)拍數(shù)為1，假設定時器的定時值就是一個時鐘節(jié)拍間隔。定時器開啟后，第2個時鐘節(jié)拍馬上就到了，由情況1的分析可知，這個定時器的回調(diào)函數(shù)很快就會被執(zhí)行。 B時刻表示這個定時器回調(diào)函數(shù)第一次執(zhí)行。C、D時刻為回調(diào)函數(shù)的第2次與第3次執(zhí)行時刻，這兩次到時是比較準確的。

因此，定時器從開啟到回調(diào)函數(shù)開始執(zhí)行的時間與定時值相比是有較大抖動的。若此時的時鐘節(jié)拍間隔為5 ms，則這個抖動的誤差最大即5 ms。這種情況下的抖動只能通過提高每秒的時鐘節(jié)拍數(shù)來減小。因此，在數(shù)據(jù)采集或其他定時器的應用中，要留意定時器開啟后第一次到時的處理，以免進行錯誤的判斷。

4 定時器管理任務對操作系統(tǒng)性能的影響

定時器管理任務的運行使應用程序可建立的任務數(shù)減1。該任務要求是系統(tǒng)中的最高優(yōu)先級，因此每次有時鐘中斷發(fā)生它都要運行，必然會消耗掉一定的CPU資源。軟件定時器功能所占用的CPU運行時間(設為M)的計數(shù)公式為：

M=定時器管理任務判斷定時器是否到時的時間+定時器回調(diào)函數(shù)執(zhí)行時間+定時器控制塊移除與再插入時間+切換到次低優(yōu)先級任務的時間

首先，采用μC/OS-II中自帶的統(tǒng)計任務測試定時器管理任務對CPU資源的占用情況。測試時系統(tǒng)中開啟3個任務：定時器管理任務、統(tǒng)計任務和Idle 任務。定時器到時回調(diào)函數(shù)在定時器管理任務中執(zhí)行，增加了管理任務運行時間。為僅測試系統(tǒng)定時器管理功能的開銷，測試時將定時回調(diào)函數(shù)置為空操作。因統(tǒng)計任務要求必須在初始化時建立第一個也是唯一的一個任務中調(diào)用統(tǒng)計任務初始化函數(shù)OSStatInit()，所以需在定時器管理任務中進行必要改動，以保證在統(tǒng)計任務初始化后才開啟定時器的管理功能。測試用定時器在main函數(shù)中靜態(tài)創(chuàng)建。

測試后發(fā)現(xiàn)，當定時器數(shù)由1增加到8時，CPU的使用率一直是1%。這說明系統(tǒng)開啟定時器管理功能后，增加的負荷很小。另一方面因為統(tǒng)計任務計算CPU使用率時是整數(shù)相除、余數(shù)舍棄，這就使得0～(OSIidleCtrMax/100-1)的計數(shù)是不能被分辨的，因此統(tǒng)計任務不能準確地反應定時器管理任務對CPU的使用情況。

為了得到更準確的測量結果，采用“處理器占用率”這一指標對管理任務開銷進行測試。

處理器占用率=軟件定時器功能所占用的CPU運行時間(M)/CPU運行時間

當某一時鐘節(jié)拍到來時，假設這一時鐘節(jié)拍下無定時器到時，即“到時定時器回調(diào)函數(shù)執(zhí)行時間”和“定時器控制塊移除與再插入時間”為0。若當前系統(tǒng)中所創(chuàng)建的定時器正好在同一個分組中，則管理任務須對每個定時器的到時值進行比較，此時為無定時器到時時定時器管理任務對CPU的最高占用率。測試中，將定時器的到時值設定為8的倍數(shù)加1，在main()函數(shù)中靜態(tài)創(chuàng)建。使所有定時器控制塊在同一分組中，當OSTime也是8的倍數(shù)加1時，就形成了無定時器到時時定時器管理任務的最壞運行情況。

測試環(huán)境為：ARM9(400 MHz)，定時器最小分辨時間為5 ms(該值作為計算時的“CPU運行時間”)，硬件計時器的最小分辨時間為0.02μs。讀硬件計時器計算時間，測試結果如表2所列。

由測試數(shù)據(jù)可知建立定時器數(shù)為8時，處理器占用率遠小于1%。每增加一個定時器，定時器管理任務的運行時間約增加6.5μs，處理器的占用率約增加0.01%，任務的切換時間不變。這是在構建的極端情況下測試的，實際應用中的時間要小于這個值。

“定時器控制塊移除與再插入時間”在400 MHz下測試為0.22μs。某一時鐘節(jié)拍處理時，若有定時器到時，則最壞情況是這個到時的定時器控制塊在鏈表的最后，只有執(zhí)行完整個鏈表的判斷后才開始執(zhí)行該到時定時器的回調(diào)函數(shù)。假設定時器數(shù)為8，且鏈表中最后一個定時器先到時，則該定時器到時的這個鐘節(jié)拍下處理器利用率為： (0.34μs+0.22μs+0.82μs+定時器回調(diào)函數(shù)執(zhí)行時間)/5 ms=(1.38μs+定時器回調(diào)函數(shù)執(zhí)行時間)/5 ms。[!--empirenews.page--]

結 論

本文對μC/OS-II軟件定時器的算法及抖動問題進行了分析，并在特定平臺上進行了測試，較好地反映出了該定時器的精度和對處理器資源的占用情況。測試結果可信度高，為在μC/OS-II下的軟件定時器應用開發(fā)提供了可靠的依據(jù)。