μC／OS-II软件定时器的分析与测试

由测试数据可知，若有定时器到时，则经过几个μ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下的软件定时器应用开发提供了可靠的依据。