（将本文讨论的 “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的数据场

【AUTOSAR-CAN】CAN的 “BasicCAN架构” 和 “FullCAN架构”相关推荐

php和架构,结构和架构的区别是什么？
叫项目结构还是项目架构呢,叫服务器结构还是叫服务器架构呢,有点晕啊,因为项目依赖的其它项目比较多,我是叫他项目结构呢还是叫项目架构呢,因为写周报,我写的对项目结构有所了解,听的有点别扭啊. 回复内容: ...
Android架构篇-4 架构模式MVVM
Android架构篇-4 架构模式MVVM MVVM原理 #mermaid-svg-CJmTYPxP5GkKNMic .label{font-family:'trebuchet ms', verdan ...
iOS架构篇-4 架构模式MVVM
iOS架构篇-4 架构模式MVVM MVVM原理 MVVM 登录例子 View: ViewModel: Model: 如果觉得可以就点个
企业架构研究总结（39）——TOGAF架构能力框架之架构委员会和架构合规性
3. 架构委员会正如前面所说,一个用来对架构治理策略的实现进行监督的跨组织的架构委员会是架构治理策略成功的主要要素之一.架构委员会应该能够代表所有主要干系人的需求,并且通常还需要对整个架构的审查及维 ...
一文了解四种软件架构：Serverless架构、微服务架构、分布式架构、单体架构
如果一个软件开发人员,不了解软件架构的演进,会制约技术的选型和开发人员的生存.晋升空间.这里我列举了目前主要的四种软件架构以及他们的优缺点,希望能够帮助软件开发人员拓展知识面. 一.单体架构单体架构 ...
【从单体架构到分布式架构】（二）请求增多，单点变集群(1)：负载均衡
这是我的第 47 篇原创文章作者 l 会点代码的大叔(CodeDaShu) 上一个章节,我们搭建了一个最简单的单体服务项目,单体架构就是把所有的功能都放在一个工程项目中. 但是当访问量不断增加,我们只 ...
你居然还不知道Mysql存储引擎InnoDB分为内存架构、磁盘架构？
作者:陌北有棵树,Java人,架构师社区合伙人! 关于MySQL对于后端程序员的重要性不言而喻,而InnoDB也已经是MySQL默认的存储引擎.作为我们每天打交道的存储引擎,我们对它可能需要对它有更多 ...
CS架构和BS架构的发展趋势即在图像处理软件中的应用
趋势:总体来讲有融合的趋势,你中有我,我中有你.前后端分离的技术大行其道,前端更像是把原来桌面上的工作搬到浏览器中实现. websocket能像桌面一样工作: javascript的语法增加了clas ...
一文看懂Java微服务架构，WEB2.0，垂直架构，分布式架构，微服务架构
Java微服务架构目录: 了解开发环境&生成环境 WEB1.0 & WEB2.0 垂直架构分布式架构微服务架构 1.了解开发环境&生产环境 1.1 开发环境平时在写代码 ...

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

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

2.回归问题

3.CAN的各种分类

【AUTOSAR-CAN】CAN的 “BasicCAN架构” 和 “FullCAN架构”相关推荐

最新文章

热门文章