一 : 关于软件硬件看门狗

看门狗Watch Dog是一个很重要的资源，他能够有效的防止系统进入死循环或者程序跑飞。（www.61k.com]

工作原理：在系统运行以后也就启动了看门狗的计数器，看门狗就开始自动计数，如果到了一定的时间还不去清看门狗，那么看门狗计数器就会溢出从而引起看门狗中断，造成系统复位。

看门狗是类似与硬件保护卡之类.保护硬盘数据的.

是单片机一个复位芯片,在单片机遇到异常情况之下自动复位!~~

看门狗电路是用来看着你的CPU的，作用是不让你的程序丢失。

看门狗实际上是一个计数器，一般给看门狗一个大数，程序开始运行后看门狗开始倒计数。如果程序运行正常，过一段时间CPU应发出指令让看门狗复位，重新开始倒计数。如果看门狗减到0就认为程序没有正常工作，强制整个系统复位。

一般是为了程序进入死循环或死机！有的单片机不需外加看门狗电路（PIC）。

看门狗定时器对微控制器提供了独立的保护系统.当系统出现故障时,在可选的超时周期之后,看门狗将以RESET信号作出响应.像x25045就可选超时周期为1.4秒,600毫秒,200毫秒三种.当你的程序死机时,x25045就会使单片机复位.

硬件看门狗WatchDog

是一个自我保护装置.他时刻监视系统的运行.一旦系统运行不正常.看门狗会复位系统.实际上看门狗是一个计时器.你要让这个计时器置零前给她一个信号.让他重新计时.这样起到一个监视系统运行的作用.

一般很多MCU带有这个电路。但是你可以不使用它。这样在上电的时候禁止他。如果你要使用watchdog，那么你的系统就必须每隔一段时间给这个电路一个信号。

如果你说的是软件看门狗，那么它的意思是：你可以创建一个看门狗，创建后开始计时，如果中间不被取消什么的，一段时间之后--这个时间通常都可以有你自己指定--它就会触发，而且你可以指定看门狗触发时执行一个你自己提供的看门狗函数。

那么它的使用就可以是这样的：为了确认程序会不会走到某个地方，你可以先创建一个看门狗，然后在要确认的地方调用一个取消看门狗计时的函数，如果程序确实走到了那个地方，看门狗被取消，那么看门狗函数就不会被执行；如果看门狗函数被执行了，说明程序没有走到该处，表明出现了什么错误。这就是看门狗的使用。

motorola

61阅读提醒您本文地址：

二 : 硬件看门狗

您当前的位置：首页 > 基础知识 > 单片机 > 单片机看门狗针对单片机的看门狗来源： 作者：关键字：单片机 看门狗 系统软件"看门狗"的设计思路：1.看门狗定时器T0的设置。（www.61k.com］在初始化程序块中设置T0的工作方式，并开启中断和计数功能。系统Fosc=12 MHz，T0为16位计数器，最大计数值为(2的16次方)-1=65 535，T0输入计数频率是.Fosc/12，溢出周期为(65 535+1)/1=65 536(μs)。2.计算主控程序循环一次的耗时。考虑系统各功能模块及其循环次数，本系统主控制程序的运行时间约为16.6 ms。系统设置"看门狗"定时器T0定时30 ms(T0的初值为65 536-30 000=35 536)。主控程序的每次循环都将刷新T0的初值。如程序进入"死循环"而T0的初值在30 ms内未被刷新，这时"看门狗"定时器T0将溢出并申请中断。3.设计T0溢出所对应的中断服务程序。此子程序只须一条指令，即在T0对应的中断向量地址(000BH)写入"无条件转移"命令，把计算机拖回整个程序的第一行，对单片机重新进行初始化并获得正确的执行顺序基本原理看门狗,又叫 watchdog timer,是一个定时器电路, 一般有一个输入,叫喂狗(kicking the dog or service the dog),一个输出到MCU的RST端,MCU正常工作的时候,每隔一段时间输出一个信号到喂狗端,给 WDT 清零,如果超过规定的时间不喂狗,(一般在程序跑飞时),WDT 定时超过,就会给出一个复位信号到MCU,使MCU复位. 防止MCU死机. 看门狗的作用就是可防止程序跑飞。也可以防止程序在线运行时候出现死循环。工作原理：在系统运行以后也就启动了看门狗的计数器，看门狗就开始自动计数，如果到了一定的时间还不去清看门狗，那么看门狗计数器就会溢出从而引起看门狗中断，造成系统复位。所以在使用有看门狗的芯片时要注意清看门狗。硬件看门狗硬件看门狗是利用了一个定时器，来监控主程序的运行，也就是说在主程序的运行过程中，我们要在定时时间到之前对定时器进行复位如果出现死循环，或者说PC指针不能回来。那么定时时间到后就会使单片机复位。常用的WDT芯片如MAX813 ,5045, IMP 813等,价格4~10元不等.软件看门狗软件看门狗技术的原理和这差不多，只不过是用软件的方法实现，我们还是以51系列来讲，我们知道在51单片机中有两个定时器，我们就可以用这两个定时器来对主程序的运行进行监控。我们可以对T0设定一定的定时时间，当产生定时中断的时候对一个变量进行赋值，而这个变量在主程序运行的开始已经有了一个初值，在这里我们要设定的定时值要小于主程序的运行时间，这样在主程序的尾部对变量的值进行判断，如果值发生了预期的变化，就说明T0中断正

硬件看门狗 硬件看门狗

常，如果没有发生变化则使程序复位。(www.61k.com）对于T1我们用来监控主程序的运行，我们给T1设定一定的定时时间，在主程序中对其进行复位，如果不能在一定的时间里对其进行复位，T1 的定时中断就会使单片机复位。在这里T1的定时时间要设的大于主程序的运行时间，给主程序留有一定的的余量。而T1的中断正常与否我们再由T0定时中断子程序来监视。这样就够成了一个循环，T0监视T1，T1监视主程序，主程序又来监视T0，从而保证系统的稳定运行。看门狗使用注意大多数51 系列单片机都有看门狗,当看门狗没有被定时清零时,将引起复位。这可防止程序跑飞。也可以防止程序在线运行时候出现死循环。设计者必须清楚看门狗的溢出时间以决定在合适的时候，清看门狗。清看门狗也不能太过频繁否则会造成资源浪费。程序正常运行时，软件每隔一定的时间(小于定时器的溢出周期)给定时器置数，即可预防溢出中断而引起的误复位。

三 : 软件看门狗和硬件看门狗

看门狗分硬件看门狗和软件看门狗。（www.61k.com）硬件看门狗是利用一个定时器电路，其定时输出连接到电路的复位端，程序在一定时间范围内对定时器清零(俗称“喂狗”)，因此程序正常工作时，定时器总不能溢出，也就不能产生复位信号。如果程序出现故障，不在定时周期内复位看门狗，就使得看门狗定时器溢出产生复位信号并重启系统。软件看门狗原理上一样，只是将硬件电路上的定时器用处理器的内部定时器代替，这样可以简化硬件电路设计，但在可靠性方面不如硬件定时器，比如系统内部定时器自身发生故障就无法检测到。当然也有通过双定时器相互监视，这不仅加大系统开销，也不能解决全部问题，比如中断系统故障导致定时器中断失效。

看门狗本身不是用来解决系统出现的问题，在调试过程中发现的故障应该要查改设计本身的错误。加入看门狗目的是对一些程序潜在错误和恶劣环境干扰等因素导致系统死机而在无人干预情况下自动恢复系统正常工作状态。看门狗也不能完全避免故障造成的损失，毕竟从发现故障到系统复位恢复正常这段时间内怠工。同时一些系统也需要复位前保护现场数据，重启后恢复现场数据，这可能也需要一笔软硬件的开销。

图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) 正确的看门狗复位逻辑图。[www.61k.com］

接下来需要解决一个问题是：监视任务如何有效监视被监视的任务群。

在TaskMonitor中定义一组结构体来模拟看门狗定时器组，

typedef struct

{

UINT32 CurCnt, LastCnt;

BOOL RunState;

int taskID;

} STRUCT_WATCH_DOG;

该结构体包括被监视的任务号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结构数据的个数决定。[www.61k.com）程序中应该有一个变量记录当前已创建的看门狗数，判断被监视任务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内的等待信号量操作

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

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

本文标题：硬件看门狗-关于软件硬件看门狗
本文地址： http://www.61k.com/1113291.html