1、看门狗基础：看门狗定时器原理、硬件看门狗 vs 软件看门狗、喂狗机制与超时处理
各位同学，咱们今天聊聊看门狗。说实话，这玩意儿在嵌入式系统里，就像你家门上的锁——平时感觉不到它的存在，但一旦出了问题，它就是最后一道防线。
我记得刚入行那会儿，带我的老工程师跟我说过一句话：「没有看门狗的系统，就像在悬崖边跳舞还不系安全绳。」当时我不太理解，直到后来自己踩了坑……嗯，咱们慢慢聊。
1.1 看门狗定时器原理
看门狗定时器，英文叫 Watchdog Timer，简称 WDT。说白了，它就是一个会倒计时的计数器。
它的工作逻辑特别简单：
- 启动时，你给它设一个初始值，比如 1 秒
- 它就开始从 1 秒往 0 倒数
- 如果倒数到 0，它就认为系统「死」了，然后触发复位
- 你要做的，就是在它倒数到 0 之前，重新给它赋值——这就是「喂狗」
你想想看，这像不像你养了一只狗？你得定期喂它，不然它就叫（复位）。
核心要点：看门狗的本质是一个独立于 CPU 运行的硬件定时器。它不依赖主程序的状态，只依赖你是否按时喂它。
我在项目中遇到过一种情况：系统跑着跑着突然死机了，但看门狗没触发。后来一查，原来是看门狗的时钟源被误配置了。嗯，这种低级错误，犯过一次就再也不会忘了。
1.2 硬件看门狗 vs 软件看门狗
很多新手会问：看门狗是不是就是软件里写个定时器？
不是的。这里要分清楚：硬件看门狗和软件看门狗，完全是两码事。
| 对比项 | 硬件看门狗 | 软件看门狗 |
|---|---|---|
| 实现方式 | 芯片内部独立硬件模块 | 软件定时器或任务监控 |
| 可靠性 | 高，不受软件崩溃影响 | 低，软件崩溃时可能失效 |
| 独立性 | 完全独立于 CPU 内核 | 依赖 CPU 和操作系统 |
| 复位能力 | 直接触发硬件复位 | 只能软件复位，可能失败 |
| 典型应用 | 工业控制、汽车电子 | 辅助监控、任务超时检测 |
我个人习惯是：硬件看门狗做最后防线，软件看门狗做日常监控。两者配合使用，效果最好。
注意：千万不要只用软件看门狗！我曾经见过一个产品，软件看门狗跑得好好的，结果一次内存越界导致整个任务调度器挂了，软件看门狗也跟着「殉情」了。硬件看门狗才是真正靠得住的。
1.3 喂狗机制与超时处理
喂狗，就是给看门狗定时器重新赋值。但怎么喂、在哪里喂、多久喂一次，这里面门道很多。
常见的喂狗方式有三种：
- 主循环喂狗：在 main 函数的 while(1) 里喂。最简单，但问题也最多。
- 任务级喂狗：在 RTOS 的每个任务里喂。更精细，但实现复杂。
- 多级喂狗：结合硬件和软件，分层次喂。我个人最推荐这种方式。
咱们看一个简单的喂狗代码示例：
// 硬件看门狗初始化
void WDT_Init(void) {
// 设置超时时间为 2 秒
WDT_Config(WDT_TIMEOUT_2S);
WDT_Enable();
}
// 主循环喂狗
void main(void) {
WDT_Init();
while(1) {
// 执行关键任务
Task_Process();
// 喂狗——必须在 2 秒内执行到这里
WDT_Feed();
// 非关键任务
NonCritical_Task();
}
}经验之谈：喂狗的位置很讲究。我建议把喂狗放在关键路径的最后一步，而不是一开始。为什么？因为如果一开始就喂狗，后面代码卡死了，看门狗也检测不到。
超时处理，就是看门狗触发后会发生什么。通常有两种模式：
- 复位模式：直接复位整个系统。这是最常用的方式。
- 中断模式：先触发中断，让你有机会记录错误信息，然后再复位。
我个人强烈建议使用中断模式。为什么？因为你可以把死机前的现场信息保存下来，方便事后分析。
避坑指南：我曾经在一个项目中，看门狗超时后直接复位，结果产品在现场反复重启，客户都疯了。后来加上中断模式，在复位前把错误日志写到 EEPROM 里，才发现是一个传感器驱动里的死循环。如果没有日志，这种偶发问题根本查不出来。
最后说一个很多人忽略的点：喂狗的时间余量。假设看门狗超时时间是 2 秒，你最好在 1.5 秒以内就喂一次。留出 0.5 秒的余量，应对系统偶尔的卡顿。我一般按 70% 的阈值来设计——超时时间 2 秒，喂狗周期 1.4 秒。
嗯，看门狗的基础知识就这些。记住一句话：看门狗不是万能的，但没有看门狗是万万不能的。下一节咱们聊聊看门狗在 RTOS 中的具体应用，那才是真正考验设计能力的地方。