1. 概述

在CAN通信学习时我们经常会遇到或者听同事聊到Basic-CAN与Full-CAN，单从字面上很难理解两个名词是什么含义，在实际开发中如何使用？本篇我们就来一起学习下Basic-CAN与Full-CAN到底是什么？及其应用场景。本文框架如下：

2. 基本内容

2.1 什么是Basic-CAN与Full-CAN？

在Autosar官方文档的CanDriver中有如下描述：

即：Basic-CAN与Full-CAN是CAN硬件对象的两种不同类型：
Basic-CAN：一个CAN硬件对象可以处理多个L-PDUs，换句话说就是一个HOH可以处理多个CAN ID的报文，至于这些HOH是如何处理在后面会进一步介绍到；
Full-CAN：一个CAN硬件对象只能处理一个L-PDUs，即一个HOH只能处理一个特定CAN ID的报文。

既然聊到了HOH(Hardware Object Handle)，就顺便再详细介绍下吧，HOH实质就是收/发CAN报文信息存放的一段RAM，根据收发区分HOH还可以进一步划分为HRH与HTH。对于HOH可以根据实际项目需求全部或部分使用，但在一般情况下为了尽可能减少报文阻塞的情况，建议全部使用。

2.2 既生瑜何生亮？

我们知道了什么是Basic-CAN与Full-CAN，那为什么会出现这两种不同类型的CAN呢？是不是只要Basic-CAN或者Full-CAN就能满足工程需求了呢？

可以参考下英飞凌TC39x芯片手册里的一张表格，每个CAN Module里可供缓存的接收报文的Buffer为64个，发送报文buffer大小为32个，在智能网联时代，收发报文数目不断增多，以发送报文为例，如果发送数量超过了32个，且每个报文对应的HOH都配置长Full CAN，势必Buffer大小不够，这就需要部分报文的HOH需要配置为Basic CAN对应FIFO方式。

因此，在实际开发中会将两种搭配使用，至于哪些报文使用Basic，哪些使用Full就是下一章节我们要讲述的内容。

3. 不同报文类型如何选择Basic-CAN与Full-CAN？

一般工程中，我们常用的报文类型有：诊断报文，应用报文，网络管理报文及XCP报文，不同报文有不同特点，例如接收的应用报文我们一般是接收最新的数据，诊断报文则需要以此接收响应，下面就来根据不同报文特点选择对应的收发类型：

应用报文：按发送及接收进一步分析：
对于接收的应用报文，一般不需要缓存，使用最新接收的数据即可，因此配置为Full-CAN。

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

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

网络管理报文：同样按网管报文的接收与发送进行区分：
对于接收类型的网管报文，一个接收节点通常会要求可以接收一段范围的网管报文，因此一般配置成Basic-CAN。

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

XCP报文：对于XCP报文，与诊断报文类似，XCP的CTO报文报文需要顺序执行，推荐配置成Full-CAN类型。