一、看门狗基础概念：什么是看门狗、看门狗的历史由来、看门狗在嵌入式系统中的角色
1.1 什么是看门狗？一个最朴素的比喻
看门狗，英文叫 Watchdog Timer（WDT）。
说白了，它就是一个计时器。但这个计时器很特别——它不干别的，就盯着你的程序有没有「死掉」。
我经常跟刚入行的同事这么解释：
你养了一条狗，这条狗每隔一段时间就要你喂它一次。如果你按时喂了，它就安安静静待着。但如果你超过时间没喂它，它就会「汪汪叫」——在嵌入式系统里，这个「汪汪叫」就是复位整个系统。
嗯，这个比喻虽然糙了点，但道理是通的。
看门狗的核心逻辑就三句话：
- 启动后开始计时——狗开始饿了
- 程序定期「喂狗」——你按时喂它
- 超时未喂则复位——狗叫了，系统重启
核心要点：看门狗不是用来「防止」故障的，而是用来「检测并恢复」故障的。它不解决 bug，它解决的是「程序卡死了怎么办」这个问题。
1.2 看门狗的历史由来——从太空到你的电路板
看门狗这个概念，其实最早是从航天领域来的。
我记得看过一份早期的资料，讲的是上世纪六七十年代，NASA 在做阿波罗计划的时候，就遇到了一个头疼的问题：计算机在太空中偶尔会因为宇宙射线干扰而「死机」。那时候没有互联网，没有远程重启，宇航员也不可能手动去按复位键。
怎么办？
工程师们想了一个办法：加一个独立的计时器，让计算机定期「签到」。如果计算机超过一定时间没签到，就说明它出问题了，计时器就自动触发复位信号。
这就是看门狗的雏形。
后来这个技术慢慢下放到工业控制、汽车电子、消费电子领域。到了 80 年代，单片机厂商开始把看门狗集成到芯片内部。到今天，几乎所有的 MCU 都内置了看门狗模块。
一个小故事：我早年做工业控制器的时候，遇到过一台设备在客户现场每隔几小时就死机一次。查了三天没找到原因，最后发现是看门狗没开。开了之后，虽然死机还在发生，但系统能在 200 毫秒内自动恢复，客户再也没投诉过。你看，有时候解决问题不一定要消灭 bug，让系统能「自愈」也是一种思路。
1.3 看门狗在嵌入式系统中的角色
看门狗在嵌入式系统里，扮演的角色其实很明确——最后一道防线。
你想想看，嵌入式系统跟 PC 不一样。PC 死机了，用户可以按 Ctrl+Alt+Del，可以按电源键重启。但嵌入式设备呢？
- 一个智能电表装在户外电线杆上，死机了谁去重启？
- 一个汽车 ECU 在高速行驶时死机了，驾驶员能手动复位吗？
- 一个医疗监护仪在手术中死机了，后果是什么？
所以，看门狗在嵌入式系统里的角色，我总结为三个层次：
| 层次 | 角色 | 说明 |
|---|---|---|
| 第一层 | 故障检测器 | 检测程序是否跑飞、死循环、卡死 |
| 第二层 | 自动恢复器 | 检测到故障后自动复位系统 |
| 第三层 | 安全兜底 | 其他保护机制失效时的最后保障 |
我曾经在一个项目中遇到过这样的情况：产品已经量产了，突然有客户反馈设备偶尔会「死机」。我们分析日志发现，是某个极端条件下触发了内存越界，导致主循环跳飞了。代码里虽然有各种异常处理，但那个场景恰好绕过了所有保护。
最后怎么解决的？
不是改代码——因为那个 bug 复现概率极低，改代码风险太大。我们直接在下一版固件里把看门狗的超时时间从 1 秒改成了 500 毫秒。从此再没有死机反馈。
你看，这就是看门狗的角色——它不完美，但它能在你所有保护措施都失效的时候，帮你兜底。
1.4 看门狗的分类
从实现方式上，看门狗大致分两类：
- 硬件看门狗：独立于 CPU 的硬件模块，通常是一个外部芯片或 MCU 内部集成的独立定时器。即使 CPU 内核挂了，它依然能工作。
- 软件看门狗：用软件实现的定时器，依赖 CPU 和操作系统。如果 CPU 彻底死掉，软件看门狗也救不了你。
注意：我个人习惯在关键产品上同时使用硬件看门狗和软件看门狗。硬件看门狗保底，软件看门狗做更精细的监控。这叫「纵深防御」，别把所有鸡蛋放在一个篮子里。
1.5 看门狗的工作流程
看门狗的工作流程其实很简单，我画了一张图帮你理解：
这张图里，绿色和蓝色是正常流程，红色是异常流程。正常运行时，程序在主循环里定期「喂狗」，看门狗计数器不断被清零。一旦程序卡死，喂狗动作停止，计数器溢出，系统复位。
1.6 一个简单的喂狗代码示例
拿 STM32 举个例子，看门狗的使用其实就几个 API：
// 初始化看门狗，超时时间设为 1 秒
void Watchdog_Init(void)
{
// 使能看门狗
IWDG_Enable();
// 设置预分频器，这里设为 64 分频
IWDG_SetPrescaler(IWDG_Prescaler_64);
// 设置重装载值，配合预分频算出 1 秒超时
IWDG_SetReload(1250); // 40kHz / 64 * 1250 ≈ 1 秒
// 喂狗一次，启动计数
IWDG_ReloadCounter();
}
// 喂狗函数，在主循环中调用
void Watchdog_Feed(void)
{
IWDG_ReloadCounter();
}
// 主循环
int main(void)
{
Watchdog_Init();
while(1)
{
// 执行任务...
DoTask1();
DoTask2();
// 喂狗
Watchdog_Feed();
// 继续执行...
DoTask3();
}
}一个小建议：喂狗的位置很讲究。别放在中断里喂，也别放在循环开头就喂。我习惯放在主循环的「关键路径」上——确保所有重要任务都执行完了，再喂狗。这样如果某个任务卡住了，喂狗动作也会卡住，看门狗就能及时复位。
1.7 看门狗能解决什么？不能解决什么？
这个问题很重要，我专门列个表说清楚：
| 能解决的 | 不能解决的 |
|---|---|
| 程序跑飞（PC 指针跳到非法地址） | 硬件永久性损坏（晶振坏了，看门狗也救不了） |
| 死循环（while 卡住出不来） | 数据逻辑错误（程序正常运行但算错了结果） |
| 任务调度卡死（RTOS 里某个任务挂起） | 电源不稳定导致的间歇性故障 |
| 堆栈溢出导致的异常 | 看门狗本身失效（硬件损坏或配置错误） |
说白了，看门狗解决的是「程序不跑了」的问题，解决不了「程序跑错了」的问题。
但话说回来，在嵌入式系统里，「程序不跑了」往往比「程序跑错了」更致命。程序跑错了至少还在运行，还有机会通过其他机制纠正。程序不跑了，那就是彻底罢工。
我的经验：做产品设计时，我一般把看门狗当作「最后一道防线」来用。前面该做的保护——输入校验、状态机设计、异常处理——一样都不能少。看门狗不是偷懒的借口，它是你所有保护措施都失效时的救命稻草。
1.8 小结
这一章我们聊了看门狗的基本概念。总结下来就几点：
- 看门狗是一个独立运行的计时器，用来检测程序是否卡死
- 它起源于航天领域，后来普及到所有嵌入式系统
- 它的角色是「最后一道防线」，不是「第一道防线」
- 硬件看门狗和软件看门狗各有优劣，关键产品建议两者都用
- 喂狗的位置和时机很重要，别放在中断里喂
嗯，基础概念就这些。下一章我们会深入聊看门狗的具体配置参数——超时时间怎么选、喂狗周期怎么定、不同应用场景下该怎么权衡。这些东西在实际项目中踩坑最多，到时候我会把我在几个项目里遇到的真实案例拿出来讲。