多任务系统看门狗的实现

　　该结构体包括被监视的任务号taskID，用来模拟“喂狗”的变量CurCnt、LastCnt(具体含义见下文)，看门狗状态标志RunState用来控制当前任务是否接受监视。

　　被监视的任务Task1~Taskn调用自定义函数CreateWatchDog(int taskid)来创建看门狗，被监视任务一段时间内要求“喂狗”，调用ResetWatchDog(int taskid)，这个“喂狗”动作实质就是对看门狗定时器结构体中的变量CurCnt加1操作。TaskMonitor大部分时间处于延时状态，假设硬件看门狗定时是2秒，监视任务可以延时1.5秒，接着对创建的看门狗定时器组一一检验，延时前保存CurCnt的当前值到LastCnt，延时后比较CurCnt与LastCnt是否相等，都不相等系统才是正常的。需要注意的是CurCnt和LastCnt数据字节数太小，而“喂狗”过于频繁，可能出现CurCnt加1操作达到一个循环而与LastCnt相等。

　　如果有任意一组的CurCnt等于LastCnt，认为对应接受监视的任务没有“喂狗”动作，也就检测到该任务出现故障需要重启，这时候TaskMonitor不对硬件看门狗定时器清零，或者延时很长的时间，比如10秒，足以使得系统重启。反之，系统正常，Task1~Taskn定期对TaskMonitor“喂狗”，TaskMonitor又定期对硬件看门狗“喂狗”，系统就得不到复位。还有一点，被监视任务可以通过调用PauseWatchDog(int taskid)来取消对应的看门狗，实际上就是对STRUCT_WATCH_DOG结构体中的RunState操作，该标志体现看门狗有效与否。

　 这种方式可监视的最大任务数由STRUCT_WATCH_DOG结构数据的个数决定。程序中应该有一个变量记录当前已创建的看门狗数，判断被监视任务Task1~Taskn是否“喂狗”只需比较CurCnt与LastCnt的值n次。

图3：系统复位逻辑图。

　　硬件看门狗监视TaskMonitor任务，TaskMonitor任务又监视其他的被监视任务Task1~Taskn，形成这样一种链条。这种方式系统的故障图表示如图3所示。被监视任务Task1~Taskn及TaskMonitor都是或的关系，因此被监视的任一任务发生故障，硬件电路看门狗就能复位。

　　为实现多任务系统的看门狗监视功能额外增加了TaskMonitor任务，这个任务占用执行时间多少也是一个重要问题。假设TaskMonitor任务一个监视周期延时1.5秒，此外需要执行保存当前计数值，判断是否“喂狗”等语句，它的CPU占用时间是很小的。用一个具体的试验证实，使用50M工作频率的CPU(S3C4510)，移植vxWorks操作系统，cache不使能条件下监视10个任务，每个监视周期占用220~240微秒。可见该任务绝大多数时间都处于任务延时状态。

　　被监视任务可能有获取消息、等待一个信号量等的语句，往往这个消息、信号量的等待是无限期的等待。这就需要将这类语句作一些修改。比
如在vxWorks中将一次无期限的获取信号量操作

　　semTake(semID, WAIT_FOREVER); // WAIT_FOREVER为无限时间等待

　　分解为

　　do

　　{

　　ResetWatchDog; // “喂狗”操作

　　}while(semTake(semID, sysClkRateGet( )) != OK); // 1s内的等待信号量操作

　　多次的时间范围内的获取信号量操作，这样才能保证及时“喂狗”。

　　另外需要注意的是系统中是否有的任务优先级比TaskMonitor高并且长时间处于执行状态，TaskMonitor长时间得不到调度，使得看门狗错误复位。良好的任务划分，配置是不应该出现这种高优先级任务长期执行状况的。