Autosar CAN开发02(应用报文接收流程-中断方式,CAN/CANIF/PDUR/COM/RTE)

使用Verctor工具链生成的代码中,底层COM接收应用报文的流程如下:

CAN控制器有Basic CAN和Full CAN两种模式,上图为FullCAN模式中断接收的的应用报文接收流程。

接收报文时,硬件把接收到的报文放到硬件寄存器中,并触发CAN接收中断,在CAN层把硬件寄存器的报文数据读取到CAN层变量中,并把该CAN层变量指针传至CANIF层,在CANIF层进行报文ID滤波和报文字节长度滤波(在Vector的Configurator工具中会配好需要接收的报文ID及对应的报文字节长度,接收到未配置的报文时,则会在CANIF层中过滤掉,不再进行上传)。当确定时需要接收的报文后,继续讲指针传至PDUR,PDUR再向上传递指针至COM层,并在COM层把接收的报文信号进行解析,存放到对应的报文信号变量中,最后供ASW(应用层)使用。

此流程图只是应用报文的接收流程图。另外还有网管报文、诊断报文等,这些报文并不是按照应用报文的流程走。


 返回目录:

Autosar BSW 开发笔记(目录)-优快云博客

### AUTOSAR CAN 报文收发配置 PdUR 示例 #### 配置背景说明 在AUTOSAR架构下,PduR(Protocol Data Unit Router)作为协议数据单元路由器,在不同模块之间负责消息的传递。对于CAN报文的发送和接收流程而言,PduR起到了至关重要的作用。 #### 创建必要的接口函数声明 为了实现基于PduRCAN报文传输功能,需先定义相应的API接口: ```c Std_ReturnType CanIf_Transmit(PduIdType canIfTxPduId, const PduInfoType* pduInfoPtr); void CanIf_SetDynamicTxBuffer(const uint8 bufferIndex, const PduLengthType length); ``` 这些接口用于触发底层驱动程序执行实际的数据交换操作[^1]。 #### 定义静态PDUs并关联至上下层实体 当涉及到具体的信号处理逻辑时,则要预先设定好各个层次间交互所使用的固定长度的消息体——即Static PDUs,并将其映射到对应的上/下游组件实例之上;例如,可将来自应用层的应用特定信息打包成一个名为`AppToCanTP`类型的PDU对象,再经由PduR转发给位于物理介质上的控制器节点进行下一步解析或组装工作。 #### 实现发送路径中的回调机制 每当高层请求发起一次新的通信会话之后,系统内部便会调用预注册好的事件响应处理器来通知当前状态变化情况;此时开发者可以利用这一特性编写自定义业务规则以满足项目需求: ```c static void App_TpTransmitConfirmation(PduIdType id, Std_ReturnType result){ /* 处理确认结果 */ } ``` 上述代码片段展示了如何捕捉到来自Transport Layer发出的通知信号后采取适当措施的方式方法[^2]。 #### 接收方向的设计思路概述 针对入站流量部分,同样遵循类似的模式构建起完整的链路关系图谱:从最外侧感知外界输入直至最终抵达目标应用程序之前经历了一系列复杂的转换过程。期间涉及到了诸如过滤器设置、错误检测以及重传策略等多个方面考量因素的影响。 ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值