3、CAN驱动（CanDrv）配置：从硬件单元到实战避坑
好，咱们进入CAN驱动配置的正题。说实话，CAN驱动是整个通信栈里最贴近硬件的模块，也是我早期做项目时踩坑最多的地方。你想想看，如果底层驱动没配好，上层再怎么折腾也是白搭。今天我就把CanDrv模块的核心功能、硬件单元配置，还有中断与轮询模式的选择，掰开了揉碎了讲清楚。
3.1 CanDrv模块到底在干什么？
CanDrv，全称是CAN Driver，它直接操作CAN控制器硬件。说白了，它的任务就是：把上层要发的报文塞进硬件发送缓冲区，把硬件收到的报文取出来交给上层。听起来简单吧？但细节里全是魔鬼。
我个人习惯把CanDrv比作一个「快递收发室」。上层应用是寄件人和收件人，硬件CAN控制器是快递车。CanDrv负责打包、拆包、排队、通知。没有它，你的CAN报文就卡在软件和硬件之间，进退两难。
核心功能清单：
- 初始化与去初始化：上电后把CAN控制器配置好，下电前干净地关闭。
- 报文发送：将L-PDU（协议数据单元）写入硬件发送缓冲区，并触发发送。
- 报文接收：从硬件接收缓冲区读取报文，并通知上层。
- 错误处理：监控总线错误、状态变化，必要时触发回调。
- 唤醒与休眠：支持网络管理相关的低功耗模式。
嗯，这里要注意：CanDrv不负责报文过滤和路由，那是CanIf（CAN接口层）的事。CanDrv只管收发，不管「该不该收」。职责边界一定要清晰，否则后面调试起来会疯掉。
3.2 硬件单元配置：HOH、HTH、HRH到底是什么？
这三个缩写，我当年刚接触AUTOSAR时看得一头雾水。后来在项目里亲手配了一遍才明白，它们其实就是硬件资源的抽象。
3.2.1 HOH（Hardware Object Handle）
HOH是一个抽象句柄，代表一个硬件对象。每个HOH对应CAN控制器里的一个硬件缓冲区（或一组缓冲区）。你可以把它理解成「快递柜的一个格子」。每个格子有自己的编号、方向和属性。
HOH本身不直接收发数据，它只是一个「把手」。真正干活的是HTH和HRH。
3.2.2 HTH（Hardware Transmit Handle）
HTH是发送句柄。每个HTH绑定到一个具体的硬件发送缓冲区。配置HTH时，你需要指定：
- 它使用哪个CAN控制器（CanController）
- 它对应哪个硬件缓冲区索引
- 它支持哪些CAN ID（标准帧/扩展帧）
- 它的发送优先级策略（比如：按ID优先级、按FIFO顺序）
我的经验： 我在一个项目中遇到过，发送高优先级报文时总是被低优先级报文阻塞。查了半天，发现是HTH配置成了FIFO模式。改成按ID优先级后，问题立刻解决。所以，如果你的系统对实时性要求高，记得把关键报文的HTH配成「基于优先级」模式。
3.2.3 HRH（Hardware Receive Handle）
HRH是接收句柄。每个HRH绑定到一个硬件接收缓冲区（或一组缓冲区）。配置HRH时，关键参数包括：
- 接收缓冲区深度（深度越大，越不容易丢帧，但占用RAM也多）
- 接收过滤规则（比如：只接收特定ID范围的报文）
- 接收中断使能（是否在收到报文时触发中断）
我曾经犯过一个低级错误：把HRH的接收缓冲区深度配成了1。结果在总线负载率超过30%时，频繁丢帧。后来改成深度4，世界清净了。你想想看，如果总线上一秒来几百帧，你只有一个缓冲区，那肯定来不及取走就被覆盖了。
3.3 中断模式 vs 轮询模式：怎么选？
这是CanDrv配置里最纠结的选择之一。我见过不少工程师在这个问题上反复横跳。咱们直接上对比表：
| 对比项 | 中断模式 | 轮询模式 |
|---|---|---|
| CPU占用率 | 低（只在有事件时响应） | 高（需要不断查询状态） |
| 实时性 | 高（事件触发，立即响应） | 中等（取决于轮询周期） |
| 代码复杂度 | 较高（需要处理中断嵌套、临界区） | 较低（顺序执行，逻辑简单） |
| 适用场景 | 高负载、多报文、实时性要求高的系统 | 低负载、简单系统、或中断资源紧张时 |
| 调试难度 | 较高（中断时序问题难复现） | 较低（执行流可预测） |
我个人习惯是：能中断就中断。为什么？因为轮询模式有个致命问题——你永远不知道「轮询间隔」设多少才合适。设短了，CPU空转；设长了，丢帧。我在一个项目里用轮询模式，轮询周期设了1ms，结果总线负载一上来，CPU占用率直接飙到40%以上。后来改成中断模式，CPU占用率降到5%以下。
注意： 中断模式也不是万能的。如果你的MCU中断资源有限，或者CAN报文频率极高（比如每10微秒一帧），中断频繁触发可能导致系统「中断风暴」，反而拖垮CPU。这种情况下，可以考虑混合模式：接收用中断，发送用轮询。或者使用FIFO深度较大的硬件缓冲区，配合中断批量处理。
3.4 实战配置示例（伪代码）
下面是一个典型的CanDrv配置片段，展示HTH和HRH的配置思路。注意，这不是完整的AUTOSAR XML配置，而是我习惯在代码注释里写的「配置备忘录」：
/*
* CanDrv配置示例（基于某款Infineon TC3xx MCU）
* 假设：CAN模块0，波特率500kbps
*/
/* 发送句柄配置 */
CanDrvHthConfigType HthConfig[2] = {
{
.CanController = CanController_0,
.HwBufferIndex = 0, /* 硬件发送缓冲区0 */
.CanIdType = CAN_ID_TYPE_STANDARD,
.TxPriority = CAN_TX_PRIORITY_BY_ID, /* 按ID优先级发送 */
.TxInterruptEnabled = TRUE /* 发送完成触发中断 */
},
{
.CanController = CanController_0,
.HwBufferIndex = 1,
.CanIdType = CAN_ID_TYPE_EXTENDED,
.TxPriority = CAN_TX_PRIORITY_FIFO,
.TxInterruptEnabled = FALSE /* 这个用轮询检查 */
}
};
/* 接收句柄配置 */
CanDrvHrhConfigType HrhConfig[3] = {
{
.CanController = CanController_0,
.HwBufferIndex = 0,
.RxBufferDepth = 4, /* 深度4，防止丢帧 */
.RxFilterId = 0x100,
.RxFilterMask = 0x7FF, /* 只接收ID=0x100的报文 */
.RxInterruptEnabled = TRUE
},
{
.CanController = CanController_0,
.HwBufferIndex = 1,
.RxBufferDepth = 2,
.RxFilterId = 0x200,
.RxFilterMask = 0x700, /* 接收ID范围0x200~0x2FF */
.RxInterruptEnabled = TRUE
},
{
.CanController = CanController_0,
.HwBufferIndex = 2,
.RxBufferDepth = 1,
.RxFilterId = 0x000,
.RxFilterMask = 0x000, /* 接收所有报文（用于调试） */
.RxInterruptEnabled = FALSE /* 调试用，轮询读取 */
}
};看到没？同一个CAN控制器，可以同时存在中断模式和轮询模式的句柄。这就是AUTOSAR的灵活性。但要注意：同一个硬件缓冲区不能同时配成中断和轮询，那会乱套。
3.5 避坑指南：我踩过的三个坑
最后，分享几个我亲身经历的血泪教训：
- 中断优先级配错导致死锁：我曾经把CAN接收中断优先级配得比系统滴答定时器还高。结果CAN中断里调用了延时函数，而延时函数依赖滴答中断...嗯，系统直接卡死。解决方案：CAN中断优先级不要高于OS的调度中断。
- HTH发送完成标志未清除：有一次发送完报文后，硬件发送完成标志位没在中断服务函数里清除。结果第二次发送时，硬件以为还在发送中，直接返回「发送忙」。排查了两天才发现。所以，中断服务函数里一定要记得清标志位。
- HRH过滤掩码算错：我想过滤ID范围0x100~0x1FF，结果掩码算错了，导致0x200的报文也进来了。后来我养成了一个习惯：配完过滤规则后，先用示波器抓一下总线，确认只有目标ID能通过。
好了，关于CanDrv配置的核心内容就这些。记住：硬件单元配置是骨架，中断/轮询选择是灵魂。骨架歪了，灵魂再好也白搭。下一章咱们聊聊CanIf层，看看怎么把底层的收发能力封装成更友好的接口。