看门狗基础：定时器、硬件与软件、VxWorks中的角色
各位工程师朋友，咱们今天聊聊看门狗。这玩意儿在嵌入式系统里，说它是「最后一道防线」一点不为过。我做了十几年VxWorks开发，见过太多系统跑着跑着就「死」在那儿的案例。嗯，看门狗就是那个在关键时刻拉你一把的「保安」。
看门狗定时器的工作原理
看门狗定时器，说白了就是一个倒计时的计数器。它从某个初始值开始，一直往下减。减到零的时候，就会触发一个复位信号——整个系统重启。
你可能会问：「那它怎么知道系统是正常的？」
答案很简单：系统正常工作时，会定期去「喂狗」。也就是把计数器重新设置回初始值。只要喂狗及时，计数器永远不会减到零。一旦系统卡死，没人喂狗了，计数器归零，复位就来了。
我个人习惯把喂狗操作放在主循环或者关键任务里。这样能确保整个软件栈都在正常工作。如果某个任务卡住了，喂狗任务也就停了，系统自动重启。
核心要点：
- 看门狗是一个硬件计数器，独立于CPU运行
- 系统正常时定期「喂狗」（重置计数器）
- 系统异常时计数器归零，触发系统复位
- 喂狗周期必须小于看门狗超时时间
硬件看门狗 vs 软件看门狗
这里有个常见的误区：很多人觉得软件看门狗和硬件看门狗差不多。其实差别大了去了。
| 特性 | 硬件看门狗 | 软件看门狗 |
|---|---|---|
| 可靠性 | 高，独立于CPU | 低，依赖CPU和OS |
| CPU死机时 | 仍能工作，触发复位 | 失效，无法工作 |
| 实现复杂度 | 需要外部电路或芯片 | 纯软件实现 |
| 灵活性 | 固定超时时间 | 可动态调整 |
| 典型应用 | 工业控制、汽车电子 | 任务监控、死锁检测 |
我在项目中遇到过这样的情况：某次现场设备频繁重启，查了三天才发现是软件看门狗在搞鬼。CPU没死，但某个任务因为资源竞争卡住了，软件看门狗检测不到，反而把正常任务给复位了。从那以后，我对软件看门狗的使用就格外谨慎。
避坑指南：
我曾经在某个项目中只用了软件看门狗，结果CPU硬件故障时系统完全失控。后来我强制要求：所有关键系统必须同时使用硬件看门狗和软件看门狗，形成双重保护。
VxWorks中的看门狗角色
VxWorks提供了非常完善的看门狗机制。它不像某些RTOS那样只是个简单的定时器，而是深度集成在任务调度和中断管理中的。
在VxWorks里，看门狗主要有三个角色：
- 系统级保护：监控整个系统的运行状态，防止死锁或无限循环
- 任务级监控：针对特定任务设置超时，检测任务是否在规定时间内完成
- 外设管理：监控外设响应，比如等待某个外设的应答信号
VxWorks的看门狗API设计得很简洁。我常用的几个函数：
/* 创建看门狗 */
WDOG_ID wdId = wdCreate();
/* 启动看门狗，500个tick后超时 */
wdStart(wdId, 500, (FUNCPTR)watchdogHandler, (int)param);
/* 喂狗：重新启动看门狗 */
wdStart(wdId, 500, (FUNCPTR)watchdogHandler, (int)param);
/* 取消看门狗 */
wdCancel(wdId);
/* 删除看门狗 */
wdDelete(wdId);你想想看，这个设计其实很巧妙。喂狗操作就是重新调用wdStart，而不是单独搞个「feed」函数。我第一次用的时候还觉得奇怪，后来发现这样设计反而更灵活——每次喂狗时可以改变超时时间和回调函数。
个人经验：
我建议把看门狗回调函数写得尽量简单。别在里面做复杂操作，比如申请内存、打印日志什么的。看门狗回调是在中断上下文中执行的，搞复杂了容易出问题。我一般就在回调里设置一个全局标志，然后在任务里检查这个标志。
VxWorks的看门狗还有一个重要特性：它支持多个看门狗同时运行。你可以为每个关键任务分配一个看门狗，也可以为整个系统设置一个全局看门狗。这种分层设计在实际项目中非常实用。
举个例子，我在做通信基站项目时，就用了三层看门狗：
- 第一层：硬件看门狗，监控整个单板
- 第二层：VxWorks系统看门狗，监控主任务循环
- 第三层：任务级看门狗，监控每个协议处理任务
这样设计的好处是：如果某个协议任务卡住了，不会影响其他任务。只有整个系统崩溃时，硬件看门狗才会出手。说白了，就是让看门狗各司其职，互不干扰。
嗯，这里要注意一点：看门狗的超时时间设置很有讲究。设得太短，正常操作都可能触发复位；设得太长，系统卡死了半天才恢复。我一般会留出50%的余量。比如某个任务最长执行时间是100ms，我就把看门狗超时设为150ms。
最后说一句：看门狗不是万能的。它只能解决系统卡死的问题，解决不了逻辑错误。但话说回来，在嵌入式系统里，能把「卡死」这个问题搞定，就已经解决了一大半的可靠性问题。