嵌入式系统看门狗的使用随着32 位微控制器在嵌入式产品中的广泛应用,嵌入式操作系统也逐渐被大量应用。

由于嵌入式操作系统的使用, 大大降低了复杂应用系统中软件开发的工作量, 使得嵌入式软件能够采用现代的软件开发技术进行代码编写和调试, 从而也提高了软件的质量。

但在嵌入式应用中, CPU 必须可靠工作, 即使因为某种原因进入一个错误状态, 系统也应该可自动恢复。

看门狗的用途就是使微控制器在进入错误状态后的一定时间内复位。

看门狗的基本原理
所谓“看门狗”是指在系统设计中通过软件或硬件方式在一定的周期内监控系统的运行状况。

如果在规定时间内没有收到来自系统的触发信号, 则系统会强制复位, 以保证系统在受到干扰时仍然能够维持正常的工作状态。

它主要有寄存器、定时器和看门狗模等部件构成, 其内部结构如图1 所示。

图1、看门狗内部结构
在这里看门狗的原理我想大家都已经比较熟悉，我不再罗嗦
关于看门狗在前后台运行的程序（无OS）上使用很简单，我们只需要定时的去喂狗就可以。

但是对于使用的嵌入式操作系统的软件我们上面的简单喂狗方式就行不通了。

原因是系统是会执行任务调度的。

每一个任务在运行时就相当于一个前后台系统。

任一时刻只会有一个任务获得CPU的支配权而运行。

这样就要求我们必须在每一个任务中都要执行喂狗动作。

这样一来虽然达到了及时喂狗而不至于让系统复位的目的，但是如果有一个任务现在异常而不能运行的话，或者是两个任务因为资源问题发生死锁，系统其它的任务还会继续喂狗。

这样应用程序虽然出了问题，但是系统依然在按正常运行。

所以在OS中使用看门狗就变得复杂起来。

下面我说一下我是如何在OS中使用看门狗的。

以uCOS-II在STM32的平台上使用为例首先我为每一个任务分配一个软件看门狗计数器。

这样就形成了软件看门狗计数器队列。

这个队列在系统中使用的是全局变量（关于全局变量的使用可以看我上面一篇的“谈谈在UCOS中使用全局变量”一文）。

，设置一个优先级别最高的任务作为监视器，以监视各应用任务是否正常运行，该监视器即为软件看门狗．该任务对其他任务都设定一个计时器，每个被监视的任务在设定的时间内对软件看门狗中相应的定时器定时清零，即“喂软狗”．在其他任务都正常工作的情况下，软件看门狗对内置硬件看门狗定时器周期性清零，即“喂狗”．若某个任务出现故障，则该任务在设置的时间内对软件看门狗不“喂软狗”，此时与之对应的定时器溢出，软件看门狗发送指令，把该任务的堆栈地址指到其起始
地址，重启该任务．当在设定的次数内不能有效启动，则监视器任务延时 “ 喂狗”，内置硬件看门狗计数器溢出，自动重启系统．另外，当监视器任务本身或系统硬件出现故障时，不能及时对硬件看门狗定时器清零，则重启系统．
监控软件狗的任务原理图如下：
12345 系统的实现过程
本软件看门狗通过检查各应用任务是否在规定的时间内对其 “ 喂软狗”来确定各任务的运行状态，硬件看门狗通过检查软件看门狗是否在规定的时间内对其 “ 喂狗”来实现对监视器任务的监视．通过微 处理器的定时器中断机制，为每个任务分配计时单元和运行标志．系统具体的执行操作如下：
1 )系统中某任务空闲时，以小于 “ 喂软狗”设定的时间间隔为周期，周期性地 “ 喂软狗”．
2 )在该任务执行时，预计执行所需的最长耗时，并用稍大于该最大耗时的时问间隔设置监视器中与 其对应的定时器参数，同时中断周期性 “ 喂软狗”模块，启动监视器任务中的定时器倒计数．当该任务正常执行完毕时，发送信号 “ 喂软狗”，对定时器清零，复位该任务供下次使用，同时恢复周期性 “ 喂软狗”模块 ．
3 )当任务出现异常时，不能在设定的时间间隔内完成该任务，不能对软件看门狗及时清零，使得监 视器中相应的定时器溢出，监视器任务通过内核服务发送指令，把该任务的堆栈地址指到其起始地址，重启该任务，累计其复位次数，同时把该任务的计时器清零．如果在设定的次数内不能够有效启动该任务，软件看门狗则延时喂内置硬件看门狗，内置看门狗计数器溢出，自动重启系统．当系统主程序出现问题或者系统硬件出问题时，软件按看门狗
也延迟“喂狗”，重新启动系统，以确保系统长时间稳定运行．这个方法已经成功运行于我的项目，再次分享出来。

方便大家的使用。