1. 看门狗基础概念：什么是看门狗、硬件看门狗 vs 软件看门狗、看门狗在嵌入式系统中的角色

1.1 什么是看门狗？一个最简单的比喻

看门狗，说白了就是一个「定时炸弹」。

你想想看，嵌入式系统跑在无人值守的环境里——车载ECU、工业控制器、医疗设备。万一程序跑飞了、死循环了、或者某个中断卡死了，谁来管？

看门狗就是干这个的。它是个独立的计时器，你得定期去「喂狗」——也就是复位这个计时器。如果你在规定时间内没去喂，看门狗就认为系统出问题了，直接触发系统复位。

我在项目中遇到过最典型的场景：一个电机控制板，跑着跑着突然不转了。查了两天，发现是某个中断服务程序里有个while循环没加超时保护。嗯，从那以后，我每个项目第一件事就是先把看门狗搭起来。

1.2 硬件看门狗 vs 软件看门狗

很多人以为看门狗就是硬件上那个芯片。其实不然。看门狗分两种：硬件看门狗和软件看门狗。它们各有各的脾气。

特性	硬件看门狗	软件看门狗
独立性	完全独立于CPU，即使CPU挂了也能工作	依赖CPU和操作系统，CPU挂了它也跟着挂
可靠性	极高，不受软件故障影响	较低，软件本身可能出问题
灵活性	固定超时时间，通常不可编程	可灵活配置超时、触发条件、回调函数
成本	需要额外硬件，增加BOM成本	纯软件实现，零硬件成本
典型应用	汽车电子、医疗设备、航空航天	消费电子、IoT设备、原型开发

1.3 硬件看门狗：我为什么离不开它

我个人习惯，在QNX系统上做产品级项目，一定会配硬件看门狗。为什么？

你想想看，软件看门狗跑在操作系统里。如果操作系统本身崩溃了——比如内核panic、内存越界导致系统挂死——软件看门狗还能工作吗？不能。它自己都死了。

硬件看门狗就不一样。它是个独立的芯片，有自己的时钟源、自己的计数器。哪怕CPU烧了、电源纹波大了、晶振停了，只要硬件看门狗还有电，它就能在超时后拉低复位引脚。

我记得有一次调试一个QNX系统，遇到了一个极其诡异的问题：系统运行几小时后随机死机。用软件看门狗根本抓不到，因为死机的时候软件看门狗也停了。后来换了硬件看门狗，每次死机后都能自动复位，配合系统日志，终于定位到是某个驱动在特定条件下触发了总线错误。

1.4 软件看门狗：灵活但别太依赖

软件看门狗，说白了就是个定时器中断。你在代码里启动一个定时器，设置超时时间，然后在主循环里定期重置它。如果定时器触发了，说明主循环卡住了。

QNX系统里实现软件看门狗其实很简单：

// QNX 软件看门狗示例
#include <sys/siginfo.h>
#include <time.h>

timer_t wd_timer;
struct sigevent event;
struct itimerspec timer_spec;

// 看门狗超时处理函数
void watchdog_handler(union sigval val) {
    // 记录错误日志
    syslog(LOG_ERR, "Watchdog timeout! System will reset.");
    
    // 尝试优雅关闭
    // 如果失败，硬件看门狗会兜底
    exit(EXIT_FAILURE);
}

// 初始化软件看门狗
void watchdog_init(int timeout_sec) {
    event.sigev_notify = SIGEV_THREAD;
    event.sigev_notify_function = watchdog_handler;
    event.sigev_value.sival_ptr = NULL;
    
    timer_create(CLOCK_MONOTONIC, &event, &wd_timer);
    
    timer_spec.it_value.tv_sec = timeout_sec;
    timer_spec.it_value.tv_nsec = 0;
    timer_spec.it_interval.tv_sec = 0;
    timer_spec.it_interval.tv_nsec = 0;
    
    timer_settime(wd_timer, 0, &timer_spec, NULL);
}

// 喂狗函数
void watchdog_feed(void) {
    timer_settime(wd_timer, 0, &timer_spec, NULL);
}

这段代码看起来挺漂亮对吧？但我要泼盆冷水——软件看门狗有个致命弱点：它依赖CPU和操作系统。如果CPU进入了死循环，或者中断被屏蔽了，这个定时器中断根本不会触发。

1.5 看门狗在嵌入式系统中的角色

看门狗在嵌入式系统里扮演什么角色？我总结了三个核心角色：

1. 最后一道防线：当所有软件保护机制都失效时，看门狗是唯一能拉回系统的机制。它不跟你讲道理，超时就复位。
2. 系统健康监测器：通过喂狗的位置和频率，你可以判断系统是否在正常运行。比如在QNX里，我习惯在多个关键线程里分别喂狗，哪个线程卡住了都能检测到。
3. 故障恢复加速器：没有看门狗，系统死机后可能需要人工重启。有了看门狗，几秒钟内就能自动恢复。这对无人值守系统来说太重要了。

你想想看，一个车载ECU如果死机了，司机不可能停车去拔电池吧？看门狗就是那个默默帮你擦屁股的角色。

1.6 什么时候该用哪种看门狗？

我个人习惯是这样判断的：

• 原型开发阶段：只用软件看门狗就够了，方便调试，改起来快。
• 产品级项目：硬件看门狗 + 软件看门狗双保险。硬件看门狗负责兜底，软件看门狗负责精细监控。
• 功能安全项目：必须用硬件看门狗，而且要按照安全标准的要求设计喂狗策略。比如ISO 26262里要求看门狗本身也要有诊断覆盖。
• 低功耗设备：注意看门狗的功耗。有些硬件看门狗在休眠模式下也能工作，但会额外耗电。这时候可以考虑在休眠前关闭看门狗，醒来后再重新初始化。

好了，这一章我们聊了看门狗的基本概念。下一章我会深入讲QNX系统里看门狗的具体实现，包括怎么配置硬件看门狗、怎么设计喂狗策略、以及那些我在项目里踩过的坑。到时候见。