3、硬件看门狗配置：QNX下硬件看门狗的初始化、超时时间设置、喂狗操作
好，我们直接进入正题。硬件看门狗这东西，说白了就是一个独立于CPU的定时器。你必须在它溢出之前“喂”它一次，否则它就认为系统挂了，直接给你来个硬件复位。
在QNX下操作硬件看门狗，跟裸机开发最大的区别在于：你不能直接去踩物理地址。QNX是微内核，硬件资源由系统统一管理。你得通过驱动或者内存映射来操作。
3.1 硬件看门狗的初始化
我个人习惯把初始化分成三步：获取设备句柄、配置参数、启动定时器。这里以常见的i.MX6平台的看门狗为例。
首先，你得打开看门狗设备。在QNX下，硬件看门狗通常暴露为/dev/watchdog节点。代码很简单：
#include <fcntl.h>
#include <devctl.h>
#include <sys/watchdog.h>
int fd = open("/dev/watchdog", O_RDWR);
if (fd == -1) {
// 我曾经遇到过驱动没加载的情况，返回的是ENOENT
// 这时候别慌，先检查一下io-pkt或slogger是否占用了这个设备
perror("open watchdog failed");
return -1;
}
嗯，这里要注意：打开设备后，看门狗可能就已经开始跑了。有些硬件设计就是这样，一上电默认就启动。所以你的初始化动作要快。
接下来是配置参数。QNX提供了devctl()接口来下发控制命令。常用的命令有：
| 命令宏 | 功能说明 |
|---|---|
WDIOC_SETTIMEOUT |
设置超时时间（单位：秒） |
WDIOC_GETTIMEOUT |
读取当前超时设置 |
WDIOC_KEEPALIVE |
喂狗操作 |
WDIOC_SETOPTIONS |
启用/禁用看门狗 |
初始化时，我建议先设置超时时间，再启用看门狗。顺序反了可能会有风险。代码示例：
int timeout = 30; // 30秒超时
if (devctl(fd, WDIOC_SETTIMEOUT, &timeout, sizeof(timeout), NULL) != EOK) {
perror("set timeout failed");
close(fd);
return -1;
}
int options = WDIOS_ENABLECARD;
if (devctl(fd, WDIOC_SETOPTIONS, &options, sizeof(options), NULL) != EOK) {
perror("enable watchdog failed");
close(fd);
return -1;
}
3.2 超时时间设置的艺术
超时时间设多少合适？这不是拍脑袋决定的。你想想看，设太短，正常业务稍微卡顿一下就复位了；设太长，系统真挂了要等半天才恢复。
我个人总结了一个经验公式：
超时时间 = 最大喂狗间隔 × 2 + 安全余量
这里的“最大喂狗间隔”是指你的喂狗线程最长可能多久才执行一次。比如你的喂狗线程每5秒跑一次，但偶尔被高优先级任务抢占，可能延迟到8秒。那么超时时间建议设为：8 × 2 + 4 = 20秒。
为什么是2倍？因为要留出至少一次重试的机会。万一第一次喂狗失败了（比如系统短暂卡顿），还有第二次机会。
实际设置时，QNX的驱动可能只支持特定的时间值。比如有些硬件只支持2的幂次方：1、2、4、8、16、32秒。你可以用WDIOC_GETTIMEOUT来查询实际生效的值：
int actual_timeout = 0;
devctl(fd, WDIOC_GETTIMEOUT, &actual_timeout, sizeof(actual_timeout), NULL);
printf("Actual watchdog timeout: %d seconds\n", actual_timeout);
3.3 喂狗操作的正确姿势
喂狗，说白了就是告诉看门狗：“我还活着，别复位我。” 在QNX下，喂狗操作通过WDIOC_KEEPALIVE命令实现：
if (devctl(fd, WDIOC_KEEPALIVE, NULL, 0, NULL) != EOK) {
// 喂狗失败，这通常意味着设备已经出问题了
// 我建议这里记录日志，但不要阻塞
fprintf(stderr, "Watchdog keepalive failed!\n");
}
喂狗的位置很关键。我见过有人把喂狗放在主循环里，结果主循环卡死了，喂狗还在继续——系统永远不会复位。这完全失去了看门狗的意义。
正确的做法是：喂狗线程应该监控系统的健康状态。比如：
- 检查关键任务是否在正常运行
- 检查内存使用是否正常
- 检查通信链路是否通畅
- 只有所有检查都通过，才执行喂狗
代码示例：
void *watchdog_thread(void *arg) {
while (1) {
// 先做健康检查
if (check_task_alive() && check_memory_ok() && check_comm_ok()) {
// 一切正常，喂狗
devctl(fd, WDIOC_KEEPALIVE, NULL, 0, NULL);
} else {
// 系统异常，故意不喂狗，让看门狗复位
fprintf(stderr, "System unhealthy, let watchdog reset...\n");
}
sleep(5); // 每5秒检查一次
}
return NULL;
}
3.4 实际项目中的注意事项
最后，分享几个我在项目中踩过的坑：
- 多进程喂狗冲突： 如果多个进程同时打开
/dev/watchdog，最后一个关闭设备的进程会关闭看门狗。我建议只让一个专门的守护进程管理看门狗。 - 调试时禁用看门狗： 在gdb调试时，看门狗会不断复位系统。可以在启动脚本中加一个环境变量来控制是否启用看门狗。
- 看门狗关闭后的状态： 有些硬件关闭看门狗后，必须重新上电才能再次启用。所以不要频繁开关。
嗯，硬件看门狗的配置其实不难，难的是想清楚“什么时候该喂，什么时候不该喂”。这个度把握好了，你的系统就稳了。