参考官方文档，11.8章节：Watchdog Timer。
一、看门狗使用中断方式
采用这种方式时，可以在中断中自己写代码，比如保存工作状态，然后软重启系统。
采用软重启模式，实际是引导MCU从头开始执行程序，MCU所有状态并不进行复位，所以不会自动写MCUSR标记，所以需要自己想办法在重启后如何判断是看门狗执行的重启。
二、看门狗使用重启方式
这里有个巨大的坑！
使用Adruino_Mini的Bootloader时，一旦因为看门狗重启，将进入无限重启死循环！
造成这个原因，是因为如果MCUSR的WDE位为1，则WDTCSR的WDE位为1。在看门狗导致重启前，MCUSR的WDE位会被自动标记为1。当系统重启后，MCUSR不会自动清理，所以WDTCSR的WDE位也为1。而上重启时，看门狗定时器被重置为0000也就是16ms，所以进入无线重启死循环模式。
但是Adruino-UNO不存在此问题，不知是芯片原因，还是Bootloader中做了处理。
网上资料说因为时间问题，看门狗重启后的定时为16ms，而Arduino-Mini的熔丝位设置为启动延时65ms，所以即使在setup()开头做了清理看门狗的动作也没用，因为程序执行不到，所以应该将熔丝位设置到4.1ms。但是实际测试如果采用SPI直接烧入程序，而不用Bootloader，无论熔丝位设置启动延时多久，都能正常执行setup()中的清理动作，不会造成无限重启。还有资料说加入一些代码可以处理此问题，但是实际测试无效。
此时测试代码如下：
然后找到一个issues，看来这是一个远古的问题了，大概意思说因为Pro Mini停产，所以这个问题不打算修复了，解决办法就是换用别的Bootlodaer，比如Optiboot或者MiniCore。其中Optiboot不知道因为稳定还是作者懒，最后版本停留在了2018年，但是Optiboot已经成为了UNO的官方默认Bootloader，应该实力还不错吧。而MiniCore是一个新锐，直到写这篇文章任然在更新。经过测试两个Bootloader确实都解决了看门狗的问题。
三、看门狗使用中断&重启方式
在这种模式下，看门狗会先执行一次中断，然后在一个超时周期后执行重启。
四、看门狗时间设置
文章评论