wdCreate函数详解：看门狗的诞生记
好，咱们今天来聊聊看门狗创建的核心函数——wdCreate。说实话，这个函数我用了十几年，每次看到它都觉得挺亲切的。它就像看门狗的「出生证明」，没有它，后面的一切都无从谈起。
函数原型：长什么样？
先看原型，其实特别简单：
WDOG_ID wdCreate(void)嗯，你没看错，就一个参数都没有。我当时第一次看到这个函数时也愣了一下——创建看门狗居然不需要任何配置？后来才明白，VxWorks的设计哲学是「先创建，后配置」。你想想看，就像你买了一只小狗，先把它抱回家，再慢慢教它怎么干活。
参数说明：真的没有参数吗？
严格来说，wdCreate确实没有显式参数。但这里有个隐藏的「潜规则」——它依赖系统内核的默认配置。我个人习惯在调用前先确认一下系统内存池的状态，尤其是堆空间是否充足。
为什么会这样？因为看门狗创建时，内核会从系统堆中分配一块内存。如果堆空间不足，创建就会失败。我在项目中遇到过好几次这种情况，尤其是在内存紧张的嵌入式设备上。
返回值：成功还是失败？
返回值类型是 WDOG_ID，本质上是一个指针。看这张表就清楚了：
| 返回值 | 含义 | 说明 |
|---|---|---|
| 非 NULL | 创建成功 | 返回看门狗对象的唯一标识符 |
| NULL | 创建失败 | 内存不足或系统资源耗尽 |
这里我要特别强调一下：永远不要假设创建一定成功。我曾经见过一个同事，代码里直接用了 wdCreate() 的返回值，连检查都没做。结果系统跑了三天，突然看门狗失效了，整个系统死在那里。排查了半天，发现是某次创建失败了，但后续代码还在用那个 NULL 指针操作看门狗。
内存分配机制：看门狗到底占了多少内存？
好，这是今天的重点。看门狗创建时，内核到底做了什么？说白了，就是三件事：
- 从系统堆中分配一块内存——这块内存大小由内核内部定义，不同版本略有差异
- 初始化看门狗控制块——设置初始状态为「未启动」
- 返回控制块指针——也就是我们拿到的 WDOG_ID
具体的内存布局，我画个简图帮你理解：
看门狗控制块 (WDOG_OBJ)
├── 状态标志 (4字节) // 是否已启动、是否已到期等
├── 定时器值 (4字节) // 当前剩余 tick 数
├── 回调函数指针 (4字节) // 到期时要执行的函数
├── 回调参数 (4字节) // 传给回调函数的参数
└── 链表指针 (8字节) // 用于挂接到系统定时器链表
总计：约 24 字节嗯，你没看错，一个看门狗对象大概只占 24 字节左右。但这里有个坑——实际占用可能更大。为什么？因为内存对齐！在 32 位系统上，每个成员都要对齐到 4 字节边界。在 64 位系统上，指针要 8 字节对齐。所以实际占用可能在 32 到 48 字节之间。
创建后的状态：刚出生的看门狗
创建成功后，看门狗处于「待命」状态。它不会立即开始计时，也不会触发任何回调。你需要调用 wdStart 来启动它。这个设计其实很合理——你想想看，如果创建完就开始计时，那配置都来不及做。
我记得有一次做项目，需要同时管理多个看门狗。我先把它们全部创建好，存到一个数组里，然后根据不同的业务场景分别启动。这种「先创建、后配置、再启动」的模式，在复杂系统中特别实用。
常见错误与避坑指南
最后，我总结几个常见的坑：
- 忘记检查返回值——这个前面说过了，再强调一遍
- 重复创建——有些人会在循环里反复调用 wdCreate，导致内存泄漏
- 创建后不删除——看门狗不用了，记得调用 wdDelete 释放内存
- 在中断中创建——绝对不要！wdCreate 会分配内存，而中断中不能做内存操作
核心要点总结：
- wdCreate 无参数，返回 WDOG_ID 或 NULL
- 每次创建消耗约 24-48 字节堆内存
- 创建后必须检查返回值
- 创建后看门狗处于待命状态，需调用 wdStart 启动
- 禁止在中断服务程序中调用 wdCreate
好了，关于 wdCreate 就讲这么多。下一节咱们聊聊 wdStart——怎么让看门狗真正跑起来。到时候我会分享一个我踩过的坑，跟定时器精度有关，挺有意思的。