2. 硬件看门狗 vs 软件看门狗:两种实现方式的优缺点对比,在制氧机中的选型建议

说到看门狗,很多工程师第一反应就是「加个外部芯片」。但实际项目中,我见过不少用软件看门狗翻车的案例,也见过硬件看门狗被配置错导致系统反复重启的尴尬。今天咱们就掰开揉碎,把这两种方案在制氧机场景下聊透。

2.1 硬件看门狗:可靠但「死板」

硬件看门狗,说白了就是一个独立的外部芯片。它不依赖主控MCU的内部资源,有自己的时钟源和计数器。你只需要定期「喂狗」,它就不复位你。

核心特点:独立运行,不受主控死机影响。

优点

  • 绝对可靠:即使MCU的时钟挂了、内核跑飞了、甚至电源出现短暂波动,硬件看门狗依然能正常工作。我在项目中遇到过MCU内部振荡器失效的情况,软件看门狗直接罢工,但硬件看门狗稳稳地把系统拉了回来。
  • 响应快:硬件看门狗的超时时间可以做到毫秒级甚至微秒级。对于制氧机这种需要快速响应的设备,这一点很关键。
  • 不占CPU资源:喂狗只需要一个GPIO引脚,几乎不消耗主控的计算能力。

缺点

  • 成本增加:多一颗芯片,BOM成本就上去了。对于量产产品,每分钱都要精打细算。
  • 灵活性差:一旦焊上去,超时时间就固定了。想改?换电阻电容,甚至换芯片。
  • 占用PCB空间:制氧机内部空间本来就紧凑,再加一个芯片,布局布线都头疼。

2.2 软件看门狗:灵活但「脆弱」

软件看门狗,是利用MCU内部定时器实现的。它和主程序共享同一个时钟源,本质上是一个「自监控」机制。

注意:软件看门狗依赖MCU正常工作。如果MCU的时钟挂了,它也跟着完蛋。

优点

  • 零成本:不需要额外硬件,只要MCU有定时器就能实现。对于成本敏感的产品,这是巨大优势。
  • 配置灵活:超时时间、喂狗位置都可以在代码里动态调整。我习惯在调试阶段把超时设长一点,方便单步调试。
  • 易于升级:固件更新时,可以顺便优化看门狗策略,不用动硬件。

缺点

  • 不可靠:如果MCU跑飞但定时器中断还能响应,软件看门狗可能「假活」。我曾经遇到过一种情况:程序陷入死循环,但定时器中断依然能触发,导致看门狗被「假喂」,系统一直卡在错误状态。
  • 占用资源:定时器中断会消耗CPU时间,对于实时性要求高的控制环路,可能会有影响。
  • 启动阶段脆弱:MCU刚上电时,时钟还没稳定,软件看门狗可能无法正常工作。

2.3 制氧机场景下的选型建议

制氧机不是普通消费电子,它涉及患者生命安全。我个人建议:不要二选一,而是组合使用

场景 推荐方案 理由
核心控制(氧气浓度、流量) 硬件看门狗 必须绝对可靠,任何死机都可能导致氧气浓度异常
人机交互(屏幕、按键) 软件看门狗 这部分出问题不会危及生命,软件看门狗足够
通信模块(WiFi、蓝牙) 软件看门狗 通信卡死可以重连,不需要硬件复位
安全关键路径(报警、阀门) 硬件看门狗 + 独立监控 双重保障,我曾经见过硬件看门狗被误配置导致报警失效的案例

我的实战经验:在制氧机项目中,我通常用硬件看门狗做「最后一道防线」,超时时间设为3秒。软件看门狗做「日常监控」,超时时间设为500ms。这样既保证了可靠性,又不会因为频繁复位影响用户体验。

2.4 避坑指南

这里分享几个我踩过的坑:

  • 喂狗位置别乱放:我曾经把喂狗放在定时器中断里,结果主程序死循环了,中断还在跑,看门狗被「假喂」。正确的做法是:喂狗放在主循环的关键路径上,确保整个系统都在正常工作。
  • 硬件看门狗也要配置对:有些硬件看门狗芯片有「使能引脚」,如果没拉对电平,看门狗可能根本没工作。我见过一个同事,焊了芯片但忘了配置使能脚,结果看门狗全程「睡觉」。
  • 注意启动时序:MCU上电后,要尽快初始化硬件看门狗。如果初始化代码里有死循环,看门狗还没启动,系统就卡死了。我的习惯是:在main函数的第一行就初始化看门狗。
  • 软件看门狗要分级:不要只设一个超时时间。我习惯设两个级别:第一级是警告(比如1秒没喂狗,记录日志),第二级才是复位(比如3秒没喂狗,强制重启)。这样既能发现问题,又不会丢失现场信息。

2.5 代码示例:混合看门狗实现

下面是一个简单的混合看门狗实现框架,供你参考:

// 硬件看门狗初始化(假设使用外部芯片 TPS3823)
void hw_watchdog_init(void) {
    // 配置GPIO为输出,用于喂狗
    GPIO_Init(WDT_PIN, GPIO_MODE_OUTPUT);
    // 硬件看门狗上电后自动开始计时,超时时间由外部电阻决定
}

// 喂硬件看门狗
void hw_watchdog_feed(void) {
    GPIO_Toggle(WDT_PIN);  // 给一个脉冲
}

// 软件看门狗初始化(使用MCU内部定时器)
void sw_watchdog_init(uint32_t timeout_ms) {
    TIMER_Init(WDT_TIMER, timeout_ms);
    TIMER_EnableInterrupt(WDT_TIMER);
    TIMER_Start(WDT_TIMER);
}

// 喂软件看门狗
void sw_watchdog_feed(void) {
    TIMER_Reset(WDT_TIMER);  // 重置计数器
}

// 主循环
void main_loop(void) {
    while(1) {
        // 关键任务处理
        process_oxygen_control();
        process_safety_check();
        
        // 喂狗
        hw_watchdog_feed();   // 硬件看门狗
        sw_watchdog_feed();   // 软件看门狗
        
        // 非关键任务
        process_display();
        process_communication();
    }
}

// 软件看门狗中断处理
void sw_watchdog_isr(void) {
    // 第一级:记录日志
    log_error("Software watchdog timeout!");
    
    // 第二级:尝试恢复
    if (timeout_count > 2) {
        // 多次超时,执行复位
        system_reset();
    }
    timeout_count++;
}

重要提醒:代码中的喂狗位置只是示例。实际项目中,喂狗一定要放在所有关键任务之后,确保这些任务都正常执行了。我见过有人把喂狗放在循环开头,结果后面的任务卡死了,看门狗还被正常喂着。

好了,关于硬件看门狗和软件看门狗的对比就聊到这里。记住一句话:硬件看门狗保命,软件看门狗保体验。在制氧机这种安全关键设备上,两者缺一不可。