【AUTOSAR-CAN】CAN的 “BasicCAN架构” 和 “FullCAN架构”

（将本文讨论的 “BasicCAN” 和 “FullCAN” 称为 ”BasicCAN架构“ 和 ”FullCAN架构”，具体原因后面解释）

1.“BasicCAN架构” 和 “FullCAN架构”

CAN的Basic和Full类型，在配置Can的时候，这个配置项困扰了我很久。

摘自 Specification of CAN Transceiver Driver 4.0.3

https://www.autosar.org/fileadmin/user_upload/standards/classic/4-0/AUTOSAR_SWS_CANDriver.pdf

Basic：一个Hardware Object可以处理多个L-PDU

Full：一个Hardware Object只可以处理一个L-PDU

这个参数只会被CanIf使用，用于配置FilterMask和ID。

查了一圈，资料不算多，这个Basic和Full常常会让人和 CAN2.0A 和 CAN2.0B 混淆，然后在这个网站找到了比较靠谱的解释。

http://www.can-wiki.info/doku.php?id=can_faq:can_faq_basic_full

最开始只有一种CAN Controller，它被设计成了具有一定数量的报文buffer的形式。比如已经作古的Intel 82526（有5个message buffer），以及他的继任者82527拥有15个message buffer。于是飞利浦想着降低成本，就有了只有两个接收buffer和一个发送buffer的82C200，当然也有部分掩码过滤。为了区分这两种CanController，有些人开始叫最开始的为 “FullCAN架构” ，后来的低成本为 “BasicCAN架构” 。

对于 “FullCAN架构” 还是 “BasicCAN架构” 其实在式样上没有一个明确的定义，取决于生产商。“FullCAN架构” 应该被叫做 “DPRAM” 架构，而 “BasicCAN架构” 则应该被称作“FIFO”架构。并且应当注意“FullCAN”并不是“BasicCAN”的某种完全版本

原初的82527的实现后来被西门子用在了他们的控制器里，现在可以在C505C/C515C/C164/C167中找到身影。

新的CanController（BasicCan的那个）扩展了基础功能，比如扩展到了32个buffer，可以用于实现FullCan模式，或者对于几个message相对拥有了较大的FIFO，比如飞利浦的SJA1000的PeliCAN，实现了BasicCAN模式（~实在是太绕了，SJA1000本身有一个BasicCAN模式，是和PeliCAN相对的，结果这个PeliCAN才是”BasicCAN架构“~）。对于大多数的控制器是融合了上面的两种CanController的。他们大多数是以FullCAN来实现的，但是也可以用其中的部分Buffer来实现BasicCAN架构。

 于是就常常会问道，那种CANController更好

“FullCAN”和“BasicCAN”是两种不同的CANController的架构。“FullCAN架构”通常有多于一个的message buffer。可以以这种方式对接收寄存器进行编程，只有一个特定的消息（或一组）传递到该Buffer中。但大多数的实现并不会缓存接收队列的message，意味着后续的message通过接受过滤后会替换之前的，而之前的就会被丢失。如果两个ID相同但是数据不同的message要以很快的速度发送，那么CPU就必须快速的发送出去避免新的message的覆盖

典型的“BasicCAN架构”控制器（飞利浦的SJA1000）本身具有接收队列，而没有缓存区

那种架构更好，取决于应用场合。如果只是用少数的message，并且小于所具有的message buffer的话，也许“FullCAN架构”更好。较新的CPU具有两种CANController。另一方面，如果你想看到所有的报文，则FIFO模式的CANController则更好。
 

大意就是，这个Basic和Full是针对CAN Controller的缓存架构来说的，而 CAN2.0A 和 CAN2.0B 是CAN的通信协议。

"BasicCAN架构“的主要特征是以FIFO的方式buffer特定ID的报文，可以缓存一定的历史报文。

”FullCAN架构“的主要特征是，一个Buffer对应一个ID的报文，而且新的报文会覆盖旧的报文，并不会缓存。

可以看到只有一个Transmit Buffer和FIFO类型的Recieve Buffer。对于CPU的负担来说稍重 

有多个message Object Buffer的存在，对于CPU的负担来说稍低。

2.回归问题

那么根据实际的项目来看，一般的Com报文都会被要求配置成Full，而诊断的报文不论接收都要配置成Basic模式，然后NM网络管理的报文，接受的要配置成Basic，而发送则是Full和Basic都可以。

结合架构上的区别来看，可能对于一般的Com报文，并不需要历史报文的保留。所以对于某一个ID的报文并不需要buffer它。

而诊断的报文则是遵循诊断的一个要求，首先诊断的报文以接收为例，是只有一个ID，然后基于UDS的协议在这一个ID的报文里做文章，所以如果采用”FullCAN“的新报文覆盖旧报文的架构的话明显是不合理的，而且（具体我还得查证）UDS是有要求接收到的报文都要处理不能丢弃的。

另一方面，网络管理的报文，对于接受来说其实是一个报文区间，”FullCAN“对此也并不合理。而发送目前是配置成了Full，因为对于发送来说就一个特定的ID的报文。理应是Full。

 

3.CAN的各种分类

Classical CAN		CAN-FD
CAN 2.0A	CAN 2.0B	不同于Classical CAN的另一个东西
8Byte数据场，只支持“11bit”的ID，称为标准模式	8Byte数据场可以是“11bit”的标准模式，也可以是“29bit”，的扩展模式	最大64Byte的数据场