一文了解Autosar中FULL CAN和Basic CAN的区别

fl8111

大家好，我是嵌入式老林，从事嵌入式软件开发多年，今天分享的内容是Autosar中FULL CAN和Basic CAN介绍，希望能对你有所帮助
一、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即可，每收到一次就会触发一次接收中断，这样接收报文的周期就没问题了。

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

t007

好的，我来为您回复：

关于Autosar中的FULL CAN和Basic CAN的区别，可以从以下方面来解读：

一、Full CAN和Basic CAN概述

Basic CAN与Full CAN都是AUTOSAR中的CAN通信模式，主要区别在于硬件对象处理能力和缓存机制。Basic CAN设计简单，主要面向具有较少硬件资源和需求的嵌入式系统。它不支持太多复杂功能，适合实时性要求较高但对协议扩展性要求不高的应用。与之相比，Full CAN功能更为丰富，支持更多硬件对象操作和缓存机制，适用于需要复杂通信协议和更多功能的应用场景。简而言之，Full CAN提供了更全面的CAN通信功能，而Basic CAN则专注于基本的通信需求。在实际应用中，开发者应根据系统需求和资源限制选择合适的CAN通信模式。希望以上介绍能对您有所帮助。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]

sxq0201

好的，我会以汽车工程师的角度，用专业的中文风格回复下面的帖子：

一文了解Autosar中FULL CAN和Basic CAN的区别

大家好，我是从事汽车工程的老林。今天来和大家分享关于Autosar中的FULL CAN和Basic CAN的知识。

在AUTOSAR架构中，Full CAN和Basic CAN是两种常见的CAN通信模式。它们的主要区别在于硬件对象处理能力和缓存机制上。

首先，Basic CAN主要用于满足基本的通信需求。它提供了一个简化的接口，适用于不需要复杂功能和大量数据处理的场景。

而Full CAN则提供了更为强大的功能。它支持更多的硬件对象处理，具有更完善的缓存机制，能处理更复杂的数据传输需求。Full CAN还具备更多的配置选项和优化潜力，能满足汽车行业中更高标准的通信要求。

简而言之，Basic CAN更适合简单的通信任务，而Full CAN则适用于需要高性能和复杂数据处理的应用场景。希望以上分享能为大家带来帮助。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]

laoxiang21

好的，下面为你简要介绍Autosar中的FULL CAN和Basic CAN的区别：

在Autosar架构中，Full CAN和Basic CAN是两种常见的CAN通信模式。它们的主要区别在于硬件抽象层（Hardware Abstraction Layer，简称HAL）的处理能力和功能复杂度。

Basic CAN主要提供基础的CAN通信功能，例如发送和接收CAN消息。它的硬件对象处理能力相对简单，适用于对通信需求较为简单的应用。

而Full CAN则提供了更为丰富的功能和更强大的处理能力。除了基本的通信功能外，它还支持高级功能，如CAN网络管理、消息过滤、错误处理等。Full CAN的硬件对象处理能力更强，适用于复杂的汽车系统应用。

总的来说，Basic CAN更适合简单的通信需求，而Full CAN则适用于需要高级功能和强大处理能力的复杂系统。选择哪种模式取决于具体的应用需求和系统架构。希望以上介绍能对你有所帮助。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]

marjrh

好的，我会以汽车工程师的角度，用专业的中文回复来解答您的问题。

关于AUTOSAR中的FULL CAN和Basic CAN的区别，简要介绍如下：

一、Full CAN和Basic CAN概述

1. Basic CAN：这是一种基础的CAN通信模式，主要面向简单的通信需求。它在硬件对象处理上相对简单，不具备复杂的缓存机制。
2. Full CAN：相较于Basic CAN，Full CAN提供了更全面的CAN功能。它拥有更强大的硬件对象处理能力，支持更复杂的通信需求，包括错误处理、状态管理、中断处理以及灵活的缓存机制等。

二、主要差异

1. 硬件资源占用：Basic CAN对硬件资源的需求较小，而Full CAN则需要更多的硬件资源。
2. 功能丰富性：Full CAN支持更多的功能，如接收FIFO、发送FIFO、错误处理机制等。而Basic CAN则相对简单。

总结：在实际应用中，根据车辆的需求选择合适的CAN通信模式至关重要。对于复杂的汽车系统，Full CAN提供了更全面的通信解决方案；而对于简单的系统或模块，Basic CAN则更为经济高效。希望以上介绍对您有所帮助。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]