μC／OS—II实时操作系统中任务延时的研究与改进

摘要：通过介绍μC／0S—II实时操作系统中的任务延时功能，分析了系统中的任务延时的优缺点。针对任务延时占用处理器时间与任务总数有关和扫描各个任务占用大量处理器时间的问题，对操作系统中的任务延时机制进行改进。改进后的操作系统在基于第二代Cortex—M3内核的LPC1768处理器上测试，通过软件仿真，得出此方法可以提高系统的实时性，降低系统的额外开销。
关键词：μC／OS—II；任务延时；Cortex—M3；软件仿真

引言
    μC／OS—II是一种源代码公开、结构小巧、具有可剥夺实时内核的实时操作系统。绝大部分代码是用C语言编写的，便于移植到各种内核上。μC／OS—II使用时钟节拍完成任务的延时功能，每个时钟对所有的任务控制块进行扫描。时钟节拍率越高，系统的额外负荷就越重，而且会随着任务总数的增加而增加。
    本文详细分析μC／OS—II中的任务延时功能，对任务延时作适当改进。新创建一个任务延时链表，把需要延时的任务链接到延时列表中，这样每个时钟节拍只对延时任务的控制块进行扫描即可，由此降低了系统负荷，而且系统的开销不会随着任务总数的增加而增加，而仅仅与同时延时的任务数有关。

1 μC／OS—II任务延时
    μC／OS—II系统中任务延时是时间管理功能的主要部分，而在μC／OS—II 2．81及以后的版本中，增加了软件定时器功能。不管是任务延时还是软件定时器，都需要一个硬件产生一个周期中断，也就是时钟节拍。
    μC／OS—II系统的时钟节拍的频率一般在10～100 Hz之间，时钟节拍率越高，系统的额外负荷就越重，影响系统的实时性。任务延时是在时钟节拍中断函数中实现的，时钟节拍中断函数调用时钟节拍函数OSTimeTick()，此函数的工作主要是扫描每一个任务控制块中的时间延时项OSTCBDly，完成任务的延时。由于OSTimeTick()要对每个任务都进行一遍同样的工作，因此它的运行时间和任务数的多少成正比。如果任务数比较多的话(现在μC／OS—II可以支持256个任务，而基于Cortex-M3内核可以支持1024个任务)，函数OSTimeTick()占用大量的系统时间。
    本文使用的操作系统版本为μC／OS—II 2．86，此版本中与任务延时相关的函数包括：
    ①与任务延时设置相关的函数——任务延时函数OSTimeDly()与OSTimeDlyHMSM()，位于time．c文件中，用于任务自身调用，无条件的挂起自己延时一段时间；请求资源函数OS_FlagBlock()(请求事件标志)、OSMboxPend()(请求邮箱)、OSMutexPend()(请求互斥量)、OSQPend()(请求消息队列)、OSSemPend()(请求信号量)等，当资源请求不成功时，任务延时挂起；还有一个挂起其他任务的函数OSTaskResume()，但没有挂起其他函数一段时间的函数。
    ②与任务恢复有关的函数——恢复任务延时函数OSTimeDlyResume()，恢复因资源不满足而挂起任务的函数OS_EventTaskRdy()、OS_Fla-gTaskRdy()，把等待列表中的占用位清除，清任务延时值；任务删除函数OSTaskDel()、任务恢复函数OSTaskResume()等。
    ③时钟节拍处理函数OSTimeTick()，用于处理任务延时。

2 任务延时的改进
    首先在uCOS_II．H头文件中定义任务延时链表OSTCBDlyList，延时任务总数变量OSTCBDlyNum，由于记录延时任务数。设置任务延时，首先把任务从任务链表中删除，然后加入都任务延时链表OSTCBDlyList中，最后OSTCBDlyNum加1；延时结束或任务恢复时，任务控制块从任务延时链表中删除，加入任务链表；删除任务时，首先判断任务是否处于延时中，再决定从哪个链表中删除。
2．1 修改与任务延时设置相关的函数
    与任务延时设置相关函数中，在其代码OSTCBCur->OSTCBDly=ticks(或timeout)后面加入延时设定函数函数OSTCBDlySet()，如OSTimeDly()函数修改成如下形式：

    函数OSTCBDlySet()的形参为需要任务延时的控制块，函数的伪代码如下所示：
[!--empirenews.page--]

2．2 从任务延时链表中删除任务控制块
    当任务延时完成、任务延时恢复、任务恢复、任务删除时，需要把任务从任务延时链表中删除。使用函数OSTCBDlyDel()，此函数无返回，形参有两个：第一个为任务控制块指针，第二个为操作类型opt，函数原型为void OSTCBDlyDel(OS_TCB*ptcb，INT8U opt)。opt的取值为：OS_Dly_OPT_NONE(正常执行，从任务延时链表删除，加入任务链表)，OS_Dly_OPT_DEL(把任务从任务延时链表删除，OSTaskDel()函数使用)。函数OSTCBDlyDel的流程如图1所示。

    在函数OSTimeDlyResume()、OS_EventTaskRdy()、OS_FlagTaskRdy()以及OSTaskResume()中，在其代码ptcb->OSTCBDly=0后面(下一行)加入0STCBDlyDel(ptcb，OS_Dly_OPT_NONE)。然后在时钟节拍处理函数OSTime Tick()中作适当修改，修改后的伪代码如下：
[!--empirenews.page--]

     对于任务删除函数OSTCBDlyDel()，首先判断任务控制块中的任务延时值是否为0，如果不等于0，调用函数OSTCBDlyDel(ptcb，OS_Dly_ OPT_DEL)，把任务从任务延时链表中删除；如果等于0，把任务从任务链表中删除。最后，把任务控制块回收到空闲任务链表中。

3 实验测试
3．1 测试环境
    本次实验使用软件开发环境Keil4，把μC／OS—II操作系统移植到基于Cortex—M3内核的LPC1768处理器上。对实时操作系统μC／OS—II 2．86进行改进，并对改进后的操作系统进行软件仿真测试。
    ARM Cortex—M3内核采用3级流水线和哈佛结构，带独立的本地指令和数据总线以及用于外设的稍微低性能的第三条总线，还包含一个支持随机跳转的内部预取指单元。LPC1700系列微控制器主要用于处理要求高度集成和低功耗的嵌入式应用，最高工作频率可达100 MHz。内部有高达512 KB的Flash存储器、64KB的数据存储器，片内外设包括以太网MAC、USB主机／从机／OTG接口、8通道的通用DMA控制器、4个UART、2条CAN通道、2个SSP控制器、SPI接口、3个I2C接口、2输入和2输出的I2S接口、8通道的12位ADC、10位DAC、电机控制PWM、正交编码器接口、4个通用定时器、6输出的通用PWM、带独立电池供电的超低功耗RTC等众多功能，方便系统的开发，节约成本。
    本次测试为：在μC／OS—II中创建25个用户任务，其中的10个任务延时一段时间(for循环延时)，并发送信号量，已激活等待此信号量的任务，而后调用函数OSTimeDly()，任务延时。而另外15个任务无限期等待另外几个任务的信号量。Keil4的软件仿真中，LPC1768的外部时钟设定为22．1184 MHz。
3．2 实验结果
    下面通过Keil4软件仿真中的Performance Analyzer功能，观察μC／OS—II原操作系统与改进后的操作中函数OSTime Tick()的运行时间。性能测评图如图2、图3所示。

    可以看出，改进后OSTimeTick()函数的系统占用率只有原先的50％，当然在实际使用环境中，改进后OSTimeTick()函数的系统占用率与系统中延时任务的多少、系统的运行速度等因素有关，不可能降低这么多，至少从理论上与仿真测试中可以验证此方法可以降低系统的额外开销，提高系统的实时性。

结语
    随着技术的进步，处理器芯片的内存不断增大，运行速度不断提高，而且应用系统设计越来越复杂，系统需要运行越来越多的任务，时钟节拍处理函数将占用大量的处理器时间，影响系统的实时性。通过本文对原操作系统中任务延时机制的改进与优化，使时钟节拍处理函数的运行时间仅与同时延时的任务数有关。通过Keil4开发环境下的软件仿真可以看出，改进后系统开销大大降低。