|
- UID
- 872238
|
3 应用实例
笔者首先把μC/OSII移植到开发板上（MCU是意法半导体生产的基于arm7TDMI核的STR730[3]），然后如2小节所述对相关部分的源代码进行修改，接下来将优先级调度法和基于μC/OSII的时间片调度法进行比较。为此分别建立了2个任务Task_TimeConsuming()、Task_Audio()，任务的优先级分别是5、6。
由于模拟的耗时任务Task_TimeConsuming()是个死循环且没有调用OSTimeDly()函数，其优先级又比Task_Audio()高，如果完全按照优先级调度，系统不会有声音输出，因为负责声音控制的任务Task_Audio一直得不到运行。而如果按照时间片调度（在os_cfg.h中增加#define OS_TASK_TIME_SLICE_EN 1），则声音输出正常，通过仿真器在Task_Audio()中设置断点，程序会很快停止在断点处。进一步地，依次在Task_TimeConsuming()和Task_Audio()函数体中设置断点，分别记录两次PC指针停止在断点处时看门狗计数器的值WDG_Counter1和WDG_Counter2，可以利用WDG_Counter1和WDG_Counter2的差值估算出任务Task_Audio前后两次被调度的时间间隔（忽略任务在切换过程中的耗时）。经过多次计算，这个时间间隔值的范围在58～59ms，而任务Task_TimeConsuming的时间片理论值＝64－Prio=64－5=59 ms，实验值与理论值是非常吻合的。
当然，这只是简单的验证实验。严格的测试还需要兼顾信号量、互斥型信号量、邮箱及消息队列相应的PEND、POST函数以及OSTimeDly()函数调用。鉴于篇幅关系，这里就不再赘述了。
结语
笔者已经成功地把这种基于μC/OSII的时间片调度法运用到车载信息娱乐系统的开发中。实践证明，对于含有耗时任务的系统，尤其是在需要严格控制耗时任务运行时间长度的场合，该调度算法会有一定的便捷性，也能保证系统的实时响应，而且整个算法只改动了μC/OSII中的少量代码；还可以根据实际需要调整各个任务的时间片大小，体现出了算法的实用性与灵活性。 |
|
