Autosar FULL CAN和qBasic CAN的区别

lidenghui

一、Full CAN和Basic CAN

1.1 Basic CAN

在AUTOSAR（Automotive Open System Architecture）中，Basic-CAN与Full-CAN是两种不同的CAN通信模式，它们主要区别在于硬件对象（Hardware Object Handle，简称HOH）的处理能力和缓存机制。

先来看看官方文档的描述：Basic-CAN允许一个硬件对象HOH处理多个L-PDUs，而FULL CAN只允许处理一个L-PDUs



Basic-CAN

1，多个CAN ID处理能力：Basic-CAN允许一个硬件对象（HOH，Hardware Object Handle）处理多个L-PDUs（Logical Protocol Data Units），即它可以处理一段范围内的CAN ID的报文。

2，FIFO机制：Basic-CAN通常与FIFO（First In, First Out）缓存机制结合使用，这意味着接收到的报文按照到达的顺序被存储，并且按照这个顺序被处理。

3，适用场景：由于Basic-CAN适合处理大量不同ID的报文，它通常用于网络管理报文和诊断报文，这些报文类型需要按照顺序处理，且数据不能被覆盖
1.2 Full CAN

1，单个CAN ID处理能力：Full-CAN模式下，一个硬件对象只能处理一个特定的L-PDU，即一个HOH只能处理一个特定的CAN ID的报文。

2，专用缓存区：Full-CAN模式下，每个CAN ID通常会有一个专用的缓存区，这样可以保证报文不会因新报文的到达而被覆盖。

3，适用场景：Full-CAN适用于应用报文和标定报文，这些报文类型通常不需要缓存，而是使用最新接收的数据。对于发送的报文，如果上层需要发送的报文数量少于底层硬件缓存区数量，可以配置为Full-CAN
二、HOH介绍

HOH实质就是收/发CAN报文信息存放的一段RAM，也就是常说的邮箱（mailbox）根据收发区分HOH还可以进一步划分为HRH与HTH。对于HOH可以根据实际项目需求全部或部分使用，但在一般情况下为了尽可能减少报文阻塞的情况，建议全部使用。



三、实际使用场景

实际项目中我们常用的报文类型有：诊断报文，应用报文，网络管理报文及XCP报文。

应用报文：

对于接收的应用报文，一般不需要缓存，使用最新接收的数据即可，因此配置为Full-CAN。

对于发送的应用报文，为减少仲裁导致的报文发送阻塞，优先选择都配置成Full-CAN，但需要底层硬件缓存区数量多于Com发送应用报文数量。例如：底层发送硬件缓存区数量为32，如节点需要发送的应用报文数量为38，即无法将这38个应用报文都配置为Full-CAN。一般的解决办法就是将发送周期短且重要的应用报文配置成Full-CAN，其他长周期应用报文配置为Basic-CAN。

诊断报文：由于诊断报文的请求及响应需按顺序处理，且数据不能被覆盖，一般将诊断报文配置为Basic-CAN，即共用Buffer，先进先出（FIFO）；

网络管理报文：同样按网络管理报文的接收与发送进行区分：

对于接收类型的网络管理报文，一个接收节点通常会要求可以接收一段范围的网管报文，因此一般配置成Basic-CAN。

对于发送类型的网络管理报文，由于单个节点的发送的网络管理报文是唯一的，在资源充足的情况下，推荐配置成Full-CAN，资源不够情况下配置成Basic-CAN也是可以的；

XCP报文：对于XCP报文，与诊断报文类似，XCP的报文需要顺序执行，推荐配置成Full-CAN类型
四、问题案例分析

问题背景：一个周期100ms的车身报文，ID为0x200，理论上是每100ms收到一帧报文，实际接收到此车身报文的时间是3.2s

问题分析：配置成了Basic CAN类型，使用FIFO模式，且depth为32，中断接收。所以只有当32 FIFO满了的时候，才会触发接收终端，32 * 100 = 3.2s

解决方案：把depth改成1即可，每收到一次就会触发一次接收中断，这样接收报文的周期就没问题了。

最后，如果觉得有帮助，希望你能一键三连(分享，点赞，在看)，你们的认可是我持续输出的动力，感激不尽






点击关注☝️我们