AUTOSAR CAN报文接收流程详解：从函数调用关系到实战避坑指南

1次阅读

共计 1739 个字符，预计需要花费 5 分钟才能阅读完成。

刚接触 AUTOSAR 开发时，最让人头疼的就是 CAN 通信配置。各模块之间像黑盒子一样，函数调用关系不透明，调试时经常遇到这些问题：

明明硬件能收到 CAN 报文，但应用层就是收不到信号
改了 DBC 文件后，某些信号突然解析异常
高负载时丢包严重，却找不到性能瓶颈在哪

这些问题往往要花几天时间查文档、看源码才能定位。今天我们就来拆解这个 ” 黑盒子 ”，看看 CAN 报文究竟是怎样从线缆传递到应用代码的。

flowchart LR
    A[CAN 控制器] -->| 硬件中断 | B(CanIf)
    B -->|CanIf_RxIndication| C(PduR)
    C -->|PduR_RxIndication| D(Com)
    D -->|Com_ReceiveSignal| E[Application]

硬件触发阶段
CAN 控制器收到报文后触发中断
CanDrv 将原始数据存入硬件 Buffer

CanIf 层处理

/* CanIf_RxIndication 典型实现 */
void CanIf_RxIndication(
    uint8 ControllerId,
    uint32 CanId,
    uint8 CanDlc,
    const uint8 *CanSdu)
{PduR_CanIfRxIndication(ControllerId, CanId, CanSdu);
}

参数说明：
- CanSdu：原始报文数据（不含 ID 和 DLC）
- CanId：包含标准 / 扩展帧标识
PduR 路由转发
根据 CAN ID 匹配路由表

调用 Com 模块的接收接口：

PduR_ComRxIndication(
    uint8 RxPduId,
    const PduInfoType *PduInfoPtr)

Com 模块信号提取
解包 DBC 定义的信号布局

调用应用注册的回调函数：

Com_ReceiveSignal(SignalId, &signalValue);

对比项	Event 模式	Polling 模式
触发条件	报文到达立即处理	主循环定期检查
实时性	高	依赖轮询周期
CPU 占用	中断上下文开销大	无额外中断开销
典型应用场景	安全关键信号（如刹车信号）	非关键信号（如仪表显示）

/* Com 配置示例 */
const Com_ConfigType ComConfiguration = {
    .ComSignal = {
        {
            .ComHandleId = 0x1001,
            .ComSignalType = COM_SIGNAL_TYPE_UINT16,
            .ComSignalEndianness = COM_LITTLE_ENDIAN,
            .ComSignalInitValue = 0,
            .ComTransferProperty = TRIGGERED_WITHOUT_REPEAT
        }
    },
    .ComIPdu = {
        {
            .ComIPduHandleId = 0x2001,
            .ComIPduDirection = RECEIVE,
            .ComIPduSignalRef = &ComConfiguration.ComSignal[0]
        }
    }
};

问题现象	可能原因	解决方案
信号值跳变	DBC 的起始位 / 长度配置错误	用 CANdb++ 验证字节序
偶发性丢包	Rx Buffer 大小不足	调整 CanIfMaxRxPduCfg 配置
报文延迟超 1ms	Com 模块调度周期设置过长	缩小 Com_MainFunction 周期
回调函数未触发	ComSignalProcessing 未启用	检查 Com 配置中的处理模式