另外，在uCOS_II．h文件中增加宏定义，用于表示任务时间片被用完这种状态：
    #define OS_STAT_TS_USEUP 0x40
2．2 相关函数的修改
    对0S_TCBInit()、OSTimeTick()、OSTimeD1y()、OS_EventTaskWait()、OS_EventTaskRdy()这5个函数的修改，是在μC／OS—II基础上实现时间片调度法的关键。下面将一一对这几个函数的修改部分进行说明。
    在初始化任务控制块的函数0S_TCBInit()中，笔者添加以下代码让新创建的任务处于时间片就绪表中，并根据任务优先级对任务的时间片大小进行初始化。

    0STimeTick()函数在每个时钟滴答被调用，在时间片调度过程中起到了递减时间片计数器的作用。当计数器为0时，进行任务切换或是重新给各个任务分配时间片并开始新一轮调度。
    OSTimeDly()函数的作用是将任务延时一定的时间。这种情况下，应该把该任务从时间片调度表中清除。
    当某个任务须等待一个事件的发生时，信号量、互斥型信号量、邮箱及消息队列会通过相应的PEND函数调用函数OS_EventTaskwait()，使当前任务从就绪任务表中脱离就绪态，此时还需把当前任务从时问片调度表中清除。笔者在OS_EventTaskWait()函数中添加了以下代码：

   

   
    相应地，当某个事件发生了，信号量、互斥型信号量、邮箱及消息队列会通过相应的POST函数调用OS_Even—tTaskRdy()，从等待任务队列中使最高优先级任务脱离等待状态，此时还需要把该任务添加到时间片调度表中。笔者在0S_EventTaskRdy()函数中添加了以下代码：
    OSTSSGrp |=bity；
    OSTSSTbl[y]|=bitx；

3 应用实例
    笔者首先把μC／0S—II移植到开发板上(MCU是意法半导体生产的基于ARM7TDMI核的STR730)，然后如2小节所述对相关部分的源代码进行修改，接下来将优先级调度法和基于μC／0S—II的时间片调度法进行比较。为此分别建立了2个任务Task_TimeConsuming()、Task_Audio()，任务的优先级分别是5、6。

    由于模拟的耗时任务Task_TimeConsuming()是个死循环且没有调用OSTimeDly()函数，其优先级又比Task_Audio()高，如果完全按照优先级调度，系统不会有声音输出，因为负责声音控制的任务Task_Audio一直得不到运行。而如果按照时间片调度(在os_cfg．h中增加#defineOS_TASK_TIME_SLICE_EN 1)，则声音输出正常，通过仿真器在Task_Audio()中设置断点，程序会很快停止在断点处。进一步地，依次在Task_TimeConsuming()和Task_Audio()函数体中设置断点，分别记录两次PC指针停止在断点处时看门狗计数器的值WDG_Counterl和WDG_Counter2，可以利用WDG_Counter1和WDG_Counter2的差值估算出任务Task_Audio前后两次被调度的时间间隔(忽略任务在切换过程中的耗时)。经过多次计算，这个时间间隔值的范围在58～59 ms，而任务Task_TimeConsuming的时间片理论值=64一Prio=64—5=59 ms，实验值与理论值是非常吻合的。
    当然，这只是简单的验证实验。严格的测试还需要兼顾信号量、互斥型信号量、邮箱及消息队列相应的PEND、POST函数以及0STimeDly()函数调用。鉴于篇幅关系，这里就不再赘述了。

结 语
    笔者已经成功地把这种基于μC／0S—II的时间片调度法运用到车载信息娱乐系统的开发中。实践证明，对于含有耗时任务的系统，尤其是在需要严格控制耗时任务运行时间长度的场合，该调度算法会有一定的便捷性，也能保证系统的实时响应，而且整个算法只改动了μC／OS—II中的少量代码；还可以根据实际需要调整各个任务的时间片大小，体现出了算法的实用性与灵活性。