1、看门狗基础概念
大家好，我是你们的嵌入式系统讲师。今天咱们来聊聊看门狗——这个在嵌入式开发中既基础又关键的话题。
说实话，我刚开始做嵌入式开发那会儿，对看门狗的理解也就停留在「定时器溢出就复位」这个层面。直到有一次，我在一个工业控制项目里，设备在野外运行了三天三夜，突然就死机了。客户急得跳脚，我排查了整整一周，最后发现——嗯，就是看门狗配置出了问题。从那以后，我对这玩意儿就再也不敢马虎了。
什么是看门狗？
看门狗，英文叫 Watchdog Timer，简称 WDT。说白了，它就是一个特殊的定时器。它的任务很简单：盯着你的程序，看它是不是还活着。
你想想看，嵌入式系统经常要在无人值守的环境下运行。比如智能电表、车载控制器、医疗设备。万一程序跑飞了，或者陷入死循环了，谁来把它拉回来？
看门狗就是干这个的。
核心定义：看门狗是一种硬件或软件机制，用于检测系统是否正常运行。如果系统在规定时间内没有「喂狗」（即复位看门狗定时器），看门狗就会触发系统复位或其他恢复操作。
看门狗的工作原理
工作原理其实很简单，我画个流程给你看：
系统启动 → 初始化看门狗 → 设置超时时间
↓
主循环执行任务
↓
定期「喂狗」（复位定时器）
↓
如果超时未喂狗 → 看门狗触发复位
↓
系统重新启动这里有个关键点：喂狗的位置要选对。我见过不少新手，把喂狗放在定时器中断里。结果呢？主程序卡死了，中断还在跑，看门狗永远不超时。系统就这么一直卡着，谁也发现不了问题。
注意：千万不要在定时器中断里喂狗！这是新手最容易犯的错误。喂狗应该放在主循环的关键路径上，确保整个系统的运行逻辑是正常的。
看门狗的超时时间怎么设？这得看你的系统需求。一般来说：
- 快速响应系统：超时时间 10-100ms（比如电机控制）
- 普通嵌入式系统：超时时间 100ms-1s（比如智能家居设备）
- 低功耗系统：超时时间 1s-10s（比如传感器节点）
我个人习惯是：先估算出主循环的最长执行时间，然后乘以 2 到 3 倍作为超时时间。这样既不会误触发，也能及时发现死机。
硬件看门狗 vs 软件看门狗
这个区别很重要。我当年在项目里吃过亏，所以得好好说说。
| 特性 | 硬件看门狗 | 软件看门狗 |
|---|---|---|
| 实现方式 | 独立的硬件芯片或MCU内部外设 | 纯软件实现的定时器 |
| 可靠性 | 高，不受软件故障影响 | 低，软件崩溃时看门狗也可能失效 |
| 功耗 | 相对较高 | 低，可灵活控制 |
| 灵活性 | 固定配置，不易修改 | 可动态调整超时时间 |
| 典型应用 | 工业控制、汽车电子、医疗设备 | 消费电子、原型验证 |
硬件看门狗，说白了就是一个独立于CPU的定时器。就算CPU挂了、程序跑飞了、中断全乱了，它照样能工作。我做过一个车载项目，要求看门狗必须用独立芯片，不能依赖MCU内部外设。为什么？因为MCU内部看门狗在MCU彻底死掉时也可能失效。
软件看门狗呢？它是在操作系统或应用层实现的。比如在Linux里，你可以用 /dev/watchdog 设备节点来实现。优点是灵活，缺点是——你想想看，如果系统已经崩到连看门狗线程都跑不动了，那软件看门狗还有什么用？
我的建议：关键系统一定要用硬件看门狗。软件看门狗只能作为辅助手段。我曾经在一个项目中只用了软件看门狗，结果系统在极端条件下死机，看门狗也跟着「殉职」了。那次教训让我记住了：硬件看门狗才是最后的防线。
实际项目中的选择
那么问题来了：到底该用硬件还是软件看门狗？
我的经验是：
- 安全关键系统（汽车、医疗、工业）：必须用独立硬件看门狗芯片
- 普通嵌入式系统（家电、IoT设备）：用MCU内部硬件看门狗就够了
- 原型验证阶段：可以先上软件看门狗，快速迭代
- Linux/Android系统：硬件看门狗 + 软件看门狗配合使用
这里有个小技巧：很多MCU的硬件看门狗在调试模式下可以暂停。你接上调试器的时候，看门狗不会超时。这个功能在开发阶段特别有用。我习惯在调试阶段把看门狗关掉，等代码稳定了再打开。
关键总结：
- 看门狗是系统的「守护者」，不是「监工」
- 喂狗位置要选在主循环关键路径上
- 硬件看门狗是最后一道防线，软件看门狗是辅助
- 超时时间设置要留有余量，但不能太长
好了，这一章的内容就到这里。下一章我们会深入讲解硬件看门狗的电路设计和驱动实现。到时候我会分享一些具体的代码示例和调试经验。
记住：看门狗不是万能的，但没有看门狗是万万不能的。尤其是在产品化阶段，一个可靠的看门狗方案能帮你省去无数售后烦恼。