有硬件看门狗和软件看门狗。硬件看门狗使用定时器电路，其定时输出连接到电路的复位端。该程序在一定的时间范围内清除计时器(俗称喂狗).因此，当程序正常工作时，定时器可以溢出和复位信号can 不会被生成。如果程序失败且看门狗未在计时周期内复位，看门狗定时器溢出产生复位信号并重启系统。软件看门狗原理上也是一样，只是把硬件电路上的定时器换成了处理器内部的定时器，可以简化硬件电路的设计，但不如硬件定时器可靠。例如，如果系统的内部计时器出现故障，则无法检测到它。当然，有两个定时器互相监控，不仅增加了系统开销，还会不能解决所有问题，比如中断系统故障导致的定时器中断故障。
看门狗本身并不是用来解决系统问题的。调试过程中发现的故障，要由设计自己检查和纠正。watchdog的目的是在没有任何干预的情况下，自动恢复系统的正常工作状态，因为程序潜在错误、不良环境干扰等一些因素导致系统崩溃。看门狗可以完全避免故障造成的损失，毕竟从发现故障到系统复位恢复正常这段时间是闲置的。同时，一些系统还需要在复位前保护现场数据，并在重启后恢复现场数据，这也可能需要硬件和软件开销。
图1: (a)多任务系统看门狗示意图；(b)相应的看门狗复位逻辑图
在单任务系统中，看门狗如上所述工作，这很容易实现。在多任务系统中，情况稍微复杂一些。如果每个任务都像单任务系统那样完成，如图1(a)所示，只要一个任务正常工作并且喂狗通常，看门狗定时器不会溢出。除非所有任务都失败，否则看门狗定时器会溢出并复位，如图1(b)所示。
往往我们需要的是，只要有任务失败，系统就会复位。或者选择几个重点任务进行监控。如果一个任务出错，系统将复位，如图2(a)所示，相应的看门狗复位逻辑如图2(b)所示。
在多任务系统中，通过创建一个监控任务TaskMonitor，其优先级高于被监控的任务组Task1、Task2.Taskn。TaskMonitor在Task1~Taskn正常工作状态下，在一定时间内清零硬件看门狗定时器。如果被监控任务组中有一个Task_x失败，TaskMonitor不会清除看门狗定时器，从而达到当被监控任务失败时系统自动重启的目的。另外，当TaskMonitor本身出现故障时，看门狗定时器不能及时清零，看门狗可以自动复位重启。接下来要解决的问题是：监控任务如何有效的监控被监控任务组？
图2: (a)多任务系统看门狗示意图；(b)正确的看门狗复位逻辑图
在TaskMonitor中定义一组结构来模拟看门狗定时器组，
typedef结构
{
UINT32 CurCnt，LastCnt
BOOL运行状态；
int taskID
} STRUCT _ WATCH _ DOG
这个结构包括被监控的任务号taskID，它用于模拟喂狗(具体含义见下文)，看门狗状态标志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 喂狗，只需要比较n次CurCnt和LastCnt的值。
图3:系统复位逻辑图。
硬件看门狗监控TaskMonitor任务，TaskMonitor任务又监控其他被监控的Task1~Taskn 1 ~ Task KN，形成这样一个链条。这个平方系统的故障图如图3所示。被监控的Task1 ~ Taskn 1 ~ Task和TaskMonitor是or关系，所以如果任何一个被监控的任务失败，硬件电路看门狗可以复位。
为了实现多任务系统的看门狗监控功能，增加了TaskMonitor任务，这个任务需要多少执行时间也是一个重要的问题。假设TaskMonitor任务的一个监控周期延迟1.5秒，其他语句如保存当前计数值和判断是否喂狗需要执行，它的CPU占用时间很小。一个具体的实验证明，在使用50M工作频率的CPU(S3C4510)并移植vxWorks操作系统的情况下，可以在不启用cache的情况下监控10个任务，每个监控周期需要220~240微秒。可以看出，这个任务大部分时间处于任务延迟状态。
被监控的任务可能具有诸如获取消息、等待信号量等语句。通常，等待这个消息和信号量是一种无限期的等待。这需要对此类声明进行一些修改。比如在vxWorks中，会有一个不确定的信号量获取操作。
SEM take(semi，WAIT _ FOREVER)；//WAIT_FOREVER是无限的等待时间。
分解成
做
{
ResetWatchDog//喂狗操作
} while(SEM take(semi，sysClkRateGet())！=OK)；//等待信号量操作1秒
多次获取时间范围内的信号量操作，以保证及时喂狗。
另外，还要注意系统中是否有一些任务的优先级高于TaskMonitor，并且长时间处于执行状态。TaskMonitor可以长时间调度，导致看门狗复位不正确。良好的任务划分和配置不应该导致这种高优先级任务的长期执行。
标签：任务系统狗