arm linux watchdog 看门狗

  目前手上有个项目需要设计看门狗，是arm+CPLD 方式。由于对看门狗要求很高，打算做一个双看门狗，arm CPLD互相为
对方的看门狗。理论上CPLD是不需要看门狗的，还是这么去设计了。接下来对看门狗作一个小的mark。
  看门狗可以分为软看门狗，硬看门狗。也可以分为内部看门狗，外部看门狗。看门狗当然是看某个东西的，具体看什么呢？
可以看某个系统，也可以是看某个程序。理论上看门狗，如果死了，那么就不起作用了，这样是不是需要一个看门狗来看这
个看门狗呢？当然这样你就较真了，乌龟背上的乌龟。看门狗只是大大降低了系统死机的这种情况。废话扯到这里为止吧。

  看门狗-----watchdog。从名字上也能看出来，中外在这一点上是相通的，有专门用来看门的狗。顾名思义，看门狗也是狗，
你是需要喂它的，不喂就造反了，会咬死你。在电子产品中就是这么一个原理，系统要定时喂狗，如果在给时间范围内没有
喂，就会咬死系统，让系统复位。当然系统复位后，一切又得重新开始，回归到原来的状态，还得继续喂狗。原理很简单，
当然细分的话，还是有些不同。

 

软硬看门狗分类

  软看门狗，说白了就是一段定时程序，指定时间内没有得到看守程序的信号，就进行重启。重启也可以分为两种，可以是重
启看守的程序，也可以是重启整个系统。无论是重启程序还是重启系统，在重启的这个过程中，都有一个窗口期，需要考虑这
个窗口期。喂狗最大时间间隔，应该要小于这个窗口期，要不然就需要考虑其他方式。
  硬看门狗。又可以分为是内部看门狗还是外部看门狗。内部看门狗就是有些芯片内部已经自带了看门狗部分，而外部看门狗
就是类似于专门的看门狗芯片，例如MAX813。

软硬看门狗的优缺点
 这个是针对我所常用的arm+linux的情况来分析的，至于其他的上系统的都差不多，不跑系统的MCU也是有类比性的。

基于arm + linux系统下的硬看门狗喂狗

  因为系统启动是需要一定时间的，往往在系统启动过程中，外部看门狗，就已经需要喂狗了，否则系统就重启了，然后就
像一个挣扎的僵尸一样。硬看门狗均需要考虑这个问题。

分为三个阶段。

Bootloader

  cpu 内部看门狗需要配置并且开启，而外部看门狗伴随上电已经开启。bootloader阶段以uboot为例的话，它是有可能停留在
命令行，这个地方是需要考虑喂狗的。另外内核解压也是消耗时间比较大，前后需要喂狗。

kernel

  kernel启动中，CPU内部看门狗驱动还没有加载完，这之间也是需要去考虑喂狗。而外部看门狗，是kernel启动中需要去考虑
喂狗。根文件系统加载后，就开始正式喂狗。当然这也是属于下一部分。

应用程序

  可以开启专门的喂狗定时进程，进行喂狗。

 

linux下有专门的 watchdog框架

  在目录drivers/watchdog下watchdog_dev.c、watchdog_core.c和watchdog_dev.h。没用过，这里mark一下。以后有机会再看看，
也算是内核里面的一个驱动框架。

 

回归到开篇的双看门狗

  当arm部分死掉后，CPLD部分会扮演狗的角色，咬死arm部分，换之亦然。设计时需要考虑两部分相互喂狗的方式。CPLD作为狗
时，需要考虑arm系统部分启动的时间。arm 作为狗时，应用程序需要定时喂狗动作。在这个过程中，两部分都是外部硬件看门狗
的角色。如果两部分刚好同时死掉，这两个狗有可能会一起失效，当然这个概率会很小。