1. 看门狗基础概念
大家好，我是你们的嵌入式系统讲师。今天咱们聊聊看门狗——这个在嵌入式系统里看似简单、实则暗藏玄机的基础模块。
说实话，我最早接触看门狗是在做车载控制器的时候。那会儿刚入行，觉得这玩意儿不就是个定时器嘛，有啥好研究的？结果后来在项目里栽了个跟头，才真正理解了它的重要性。
什么是看门狗？
看门狗，英文叫 Watchdog Timer，简称 WDT。说白了，它就是一个特殊的计数器。
这个计数器会一直往下数。数到零的时候，它就认为系统出问题了——然后强制复位整个系统。
正常工作时，软件需要定期去"喂狗"，也就是把计数器重新设置回初始值。只要喂狗及时，计数器就不会归零，系统也就不会复位。
核心逻辑： 如果系统正常运行，它会定期喂狗 → 看门狗不触发 → 系统继续运行。如果系统卡死或跑飞，没人喂狗 → 看门狗超时 → 系统复位。
你想想看，这就像养了一只真狗。你得按时喂它，它才不叫。你不喂，它就汪汪叫——只不过这里的"叫"是直接重启系统。
看门狗的作用
看门狗到底能干啥？我归纳了三个核心作用：
- 检测系统死锁 —— 当程序陷入死循环或等待某个资源时，看门狗能及时把系统拉回来。
- 防止程序跑飞 —— 在强电磁干扰环境下，程序指针可能跳到未知地址。看门狗是最后一道防线。
- 保障系统可用性 —— 对于无人值守的设备（比如基站、车载ECU），看门狗能实现自动恢复。
我记得有一次做工业控制器的项目，现场环境电磁干扰特别严重。程序偶尔会跑飞，但概率很低，测试时根本复现不了。后来加了硬件看门狗，问题就解决了。嗯，这就是看门狗的典型应用场景。
注意： 看门狗不是万能的。它只能检测到"系统没有按时喂狗"这种故障。如果系统虽然卡死了，但喂狗线程还在跑——那看门狗也救不了你。我曾经就踩过这个坑，后面会详细讲。
硬件看门狗 vs 软件看门狗
很多初学者会问：看门狗到底用硬件实现还是软件实现？我的回答是：看情况。
先看个对比表格：
| 特性 | 硬件看门狗 | 软件看门狗 |
|---|---|---|
| 实现方式 | 独立芯片或MCU内部外设 | 操作系统定时器 + 任务监控 |
| 可靠性 | 高，独立于CPU运行 | 低，依赖CPU和OS正常 |
| 复位能力 | 直接硬件复位 | 通常只能软件复位 |
| 灵活性 | 低，配置固定 | 高，可动态调整 |
| 典型场景 | 汽车、工业、医疗 | 消费电子、开发调试 |
硬件看门狗，说白了就是一个独立的定时器芯片，或者集成在MCU内部。它不依赖CPU内核——就算CPU彻底挂了，它照样能工作。
我个人的习惯是：在量产产品中，必须用硬件看门狗。为什么？因为软件看门狗在CPU死机时自己也会死掉，那就没意义了。
软件看门狗，则是基于操作系统定时器实现的。在QNX系统里，我们可以用TimerCreate()创建一个周期性定时器，然后在定时器回调里检查各个任务是否正常。
举个例子：
// QNX 软件看门狗示例
#include <sys/neutrino.h>
#include <time.h>
// 看门狗任务列表
typedef struct {
char name[32];
uint64_t last_feed_time;
int timeout_ms;
} watchdog_task_t;
// 检查所有任务是否按时喂狗
void watchdog_check(void) {
uint64_t now = ClockCycles();
for (int i = 0; i < num_tasks; i++) {
uint64_t elapsed = (now - tasks[i].last_feed_time) /
(SYSPAGE_ENTRY(qtime)->cycles_per_sec / 1000);
if (elapsed > tasks[i].timeout_ms) {
// 任务超时，记录日志并尝试恢复
fprintf(stderr, "WATCHDOG: Task %s timeout!\n", tasks[i].name);
// 这里可以触发系统重启
}
}
}你看，软件看门狗的好处是灵活——你可以监控多个任务，每个任务可以有不同的超时时间。但它的致命弱点是：如果操作系统本身崩溃了，这个看门狗也就失效了。
我的建议： 在QNX系统中，我通常采用"硬件看门狗 + 软件看门狗"的双重策略。硬件看门狗负责兜底，防止系统完全死机；软件看门狗负责精细监控，检测各个任务是否健康。两者配合，效果最好。
实际项目中的选择
到底用哪种看门狗？我给大家一个简单的判断标准：
- 如果你的产品需要过功能安全认证（比如ISO 26262），必须用硬件看门狗。
- 如果只是开发调试阶段，软件看门狗就够用了。
- 如果是关键系统（比如自动驾驶域控制器），两者都要上。
我曾经在一个项目里只用了软件看门狗，结果现场出现了CPU stall（CPU停滞）的情况。软件看门狗自己都跑不起来了，系统彻底死在那里。从那以后，凡是量产项目，我必加硬件看门狗。
好了，这一章我们讲清楚了看门狗的基本概念。下一章我会深入讲解QNX系统里看门狗的具体实现和配置方法。到时候咱们再聊。