1 引言
当前Vxworks系统中应用通常使用taskDelay()来控制某个任务的调度周期，比如在某一个任务的中间添加一个taskDelay(sysClkRateGet())，表示其周期为1s周期任务。实际上当前这种周期任务的设计方式忽略了该任务本身处理所执行的时间，那么其调度周期实际就是“任务处理时间”+“taskDelay时间”+“任务被抢占/中断时间”。其中带来的影响因素主要有两个方面：即执行时间和抢占/中断时间。
为了解决上述问题，提出一种强周期执行任务的方式。周期任务是指每隔相等的时间间隔就必须就绪的任务；两次任务就绪的时间间隔称为任务的周期；周期任务通常都具有硬时限。
2 多任务环境
taskDelay()实际是使任务主动放弃CPU，进入延时态，直到延时结束后加入就绪队列继续等待CPU。从就绪状态的任务中，依据一定筛选方法选择一个任务使其取得CPU所有权，在处理器上运行，这种过程称为任务调度。
VxWorks提供看门狗定时器机制。看门狗定时器主要完成对计算机系统的正常工作进行监控。若在一定的时间内未进行喂狗操作，看门狗会告警。
看门狗首先通过wdCreate()来进行创建。然后可以通过调用wdStart()启动该看门狗定时器，看门狗定时器启动时需要将定时器延时的系统时钟tick数、调用的处理程序和需要给处理程序传入的参数传递给wdStart，当指定的tick数到达时，处理程序被调用。
3 软件设计与实现
3.1 实验平台设计
为了充分验证本设计，以Windows NT + Vxworks6.9平台进行仿真验证。考虑到实验精度问题，设置其1个tick是1毫秒时间；调度策略默认优先级抢占策略，不开启时间片轮转策略。
3.2 软件实现
3.2.1 纯延时法
当前应用中使用taskDelay()来控制某个任务的调度周期，称之为“纯延时法”，通过记录前后两次的系统tick可以知道其调度周期，软件设计流程如图2所示。
图2 获取调度周期流程1
单个用户任务的情况下，通过taskDelay实现了一个100tick的周期任务，进行5次试验，每次跑3000个周期，即5分钟。数据如表1所示。记录了每次试验中100tick到109tick的次数，未统计100tick以下情况，实际不可能出现。其中偏移率计算计算公式为：偏移率 = |实际值-预期值|/预期值*100%。
表1 实验1数据
为了测得高优先级仿真抢占环境下的数据，增加一个更高优先级的任务，重复实验1，可以得到表2。
表2 实验2数据
从表1和表2中可以得出结论，通过taskDelay()函数并不能得到准确的调度周期，其实际周期肯定会大于Delay的时间；并且相对较高优先级的任务越多，其偏离率越高，周期越不准。
3.2.2 修正延时法
基于之前的分析，尝试计算出实际执行时间，并从Delay时间中扣除这部分时间。设计流程如图2所示，称之为“修正延时法”。
图2 修正延时流程图
按照实验1的方式跑3000个周期，即5分钟，得到表3数据。由于存在修正这种“取长补短”的方式，因此存在周期小于100的可能性，最终达到平均周期100tick的要求。其偏离率仅0.029，效果明显好于纯延时法。
表3 实验3数据
3.2.3 定时挂起-恢复法
修正延时法中任务Delay到了之后，是通过系统调度程序控制，将其加入就绪队列，具有不确定性。尝试通过系统看门狗定时器来人为控制其任务的挂起和恢复状态。
为了验证看门狗定时器的准确性，设计实验参考图2。实验数据见表4。
表4 看门狗定时器数据
可以看出实际看门狗定时器是相当准的。这种精确也为定时挂起-恢复法提供了基础。
尝试通过wdStart来控制任务的resume和suspend状态，而不是通过taskDelay。其软件设计流程如图3所示。为了维护周期任务的核心——周期，通过中断来人为控制任务的状态转换。任务启动时，同时启动看门狗定时器控制器周期。任务执行完有效代码后，立即切换为挂起状态。定时器时间到，立刻查看当前任务状态，如果是挂起说明执行完成，恢复任务进入就绪态；如果非挂起，说明任务未完成，处于就绪态（等同于执行态），此时输出超时日志提示用户，需要考虑本任务周期设计的合理性或其他异常。最后重新启动看门狗计时等待触发下一次中断。其中虚线框中目的是输出调用周期，实际代码中不会编写。看门狗定时器所触发的函数属于中断函数，其中不能进行printf打印，否则会报错。通过LogMsg()打印时提示用户当前环境处于中断中。
图3 定时挂起-恢复法流程图
重复试验3，跑3000个周期，即5分钟，得到表5数据。偏离率为0.033%，与修正延时法相当。
表5 实验5数据
3.2.4 多种方法的比较
经过以上实验明显可知，“延时修正法”和“定时挂起-恢复法”由于“纯延时法”。以下对“延时修正法”和“定时挂起-恢复法”进行比较。
将两者实验数据进行比较，得到如图5效果，结合图形和数据可以看出，两者的偏离率近乎相等。但是实验5更加集中于100tick：100tick±2tick的频次高于实验3。
图5 数据比较
抛开100tick±2tick的数据，比较差异大于2tick的情况，趋势线见图7。显然试验5中的数据，更加趋近于接近100tick的周期（与X轴更为贴近）。
图7 偏离比较
现在考虑“修正延时法”的方式为什么存在这种差距。试考虑以下情况，在图7虚线处被中断或者被高优先级任务抢占，此时taskDelay()的时间将被提高，也就是周期被拉长了，这种瞬时超时也是不被允许的。
图7 延时修正法缺陷
实际上“1：被抢占/中断”的可能性略小，但是“2：被抢占/中断”是比较大的。taskDelay延时时间到之后进入的是就绪队列，此时可能已经有同等级优先级任务处于队列中，队首的任务优先获得CPU进入执行态。因此延时时间到之后不会被立刻执行，因此lastTick的时间被拉大，此时修正延时法周期出现延长。
4 结论与展望
虽然天脉环境下已经提供了周期任务API供使用，但是目前仍有大量的Vxworks项目需要维护。本文从当前实现方式下出现的问题出发，分析其内在原理和本质，提出并实现了一种硬周期任务的实现方式，并基于PC平台进行了仿真验证。实验证明，该实现方式有效且具有实践性，具有推广价值。
目前实现的方案仅考虑了任务的启动，暂未考虑任务的停止、删除等情况；本文将执行时间和调度周期等同了，在执行时间超出调度周期时才给出提示；实际在设计软件时，执行时间应该远小于调度周期，否则发生过载时系统将不能准确运行。本文未考虑多核系统下的异常情况，后续可以在型号任务中进行测试和完善。
5 参考文献
1 ACoreOS机载嵌入式实时操作系统程序员手册V1.1.
2 vxworks_application_programmers_guide_6.9
3 vxworks_kernel_programmers_guide_6.9