前言

  随着越来越多的应用程序接受和引入串行通信,这就要求对特定应用程序的通信功能分配消息标识符以进行标准化。如果将原来由 11 个标识符位定义的地址范围扩大,则可以更方便地使用 CAN 实现这些应用程序。
  因此,引入了第二种消息格式(扩展格式),它提供了由 29 位标识符定义的更大的地址范围。这将减轻系统设计者在定义结构良好的命名方案方面的负担。不需要扩展格式提供的标识符范围的用户仍然可以依赖传统的 11 位标识符范围(标准格式)。在这种情况下,他们可以使用市场上已有的 CAN 控制器,或者实现了这两种格式的新控制器。
  为了区分 标准格式扩展格式 ,使用了 CAN 消息格式的控制域的第一个保留位 r1(控制域有 r1 和 r0 两个保留位)。 这样做是为了使 CAN 规范 1.2 中的旧的消息格式等同于本规范的新的标准格式。 此外,本规范定义的扩展格式可以和标准格式的消息在同一网络中共存。

CAN2.0 规范由两部分组成

  • Part A 描述 CAN 规范 1.2 中定义的 CAN 消息格式
  • Part B 描述了标准消息格式扩展消息格式

注:根据本规范 Part A 或 根据以前的 CAN 规范设计的 CAN 实现,以及根据本规范的 Part B 设计的 CAN 实现可以相互通信,只要它不使用扩展格式即可。

简介

  CAN2.0 Part A 旨在实现任意两个CAN 网络之间的兼容性。然而,兼容性有不同的方面,例如电气特征和要传输的数据的解释。为了实现设计的透明性和实施的灵活性,CAN2.0 Part A 将 CAN 细分为不同的层:

  • CAN 对象层(the (CAN-) object layer )
  • CAN 传输层(the (CAN-) transfer layer)
  • 物理层(the physical layer)

对象层和传输层包括由 ISO/OSI 模型定义的数据链路层的所有服务和功能。 对象层的范围包括

  • 查找被发送的报文
  • 确定由实际要使用的传输层接收哪一个报文
  • 提供与应用层相关硬件的接口

传输层的范围主要是传输协议,即控制帧、执行仲裁、错误检查、错误信号和故障约束。在传输层内,确定总线是否可用于开始新的传输或者接收是否刚刚开始。此外,一些比特定时的一般特性也被认为是传输层的一部分。

  根据 OSI 参考模型的 CAN 分层体系结构

  • 物理层定义了信号实际传输的方式。 在本规范中,未定义物理层以便允许传输介质和信号级实现针对其应用进行优化
  • 传输层代表 CAN 协议的核心。 它将接收到的消息呈现给对象层,并接受要从对象层传输的消息。 传输层负责比特定时和同步,消息成帧,仲裁,确认,错误检测和信令以及故障限制。
  • 对象层涉及消息过滤以及状态和消息处理。

本规范的范围是定义传输层以及 CAN 协议对周围层的影响

单通道(Single Channel)

  总线是由可携带比特位的单一通道组成。通过此通道可以获得数据的再同步信息。这本技术规范不限制这些实现方法的使用,即未定义物理层。要实现此通道,使用使用单芯线(加上接地)、2 条差分线、光缆等等。

总线值(Bus value)

  总线可以具有两种互补的逻辑值之一:“显性”或“隐性”。 “显性”位和“隐性”位同时传送时,总线的结果值为“显性”。比如,在执行总线的“线与”时,逻辑0 代表“显性”等级,逻辑1 代表“隐性”等级。本技术规范不给出表示这些逻辑电平的物理状态(比如,电压、光)。

比特率

  CAN 的速度在不同系统中可能不同。 但是,在指定的系统中比特率是统一的并且是固定的。

同步

详细说明见另一篇博文

仲裁

  CAN总线上的每个节点往总线上发送数据的同时会同时读取总线上的数据,并与自己发送的数据作对比。每当总线空闲时,任何单元都可以开始发送消息。 如果 2 个或更多单元同时开始发送消息,则使用 IDENTIFIER 通过 逐位仲裁 解决总线访问冲突。 仲裁机制保证信息和时间都不会丢失。 如果同时启动具有相同 IDENTIFIER 的 DATA FRAME 和 REMOTE FRAME,则 DATA FRAME 优先于 REMOTE FRAME。
  仲裁期间,每一个发送器都对发送位的电平与监控的总线电平进行比较。 如果电平相同,则这个单元可以继续发送。 如果发送的是 1 个比特位的隐性电平,而监控视到 1 个比特位的显性电平(见总线值),那么该单元就失去了仲裁,必须退出发送状态。如果在非仲裁期间(仲裁域范围),发现了不匹配的位,则产生错误。

编码规则

  DATA FRAME 或 REMOTE FRAME 中的位字段 START OF FRAME,ARBITRATION FIELD,CONTROL FIELD,DATA FIELD 和 CRC SEQUENCE 都需要通过比特填充的方法编码。 每当发送器在要发送的比特流中检测到相同值的五个连续比特时,则自动在实际发送的比特流中插入一个相反的比特位,这种方法被称为位填充
  DATA FRAME 或 REMOTE FRAME 的剩余位字段 CRC DELIMITER,ACK FIELD 和 END OF FRAME 是固定的格式,不需要填充。 ERROR FRAME 和 OVERLOAD FRAME 也是固定格式,不通过位填充方法编码。
  消息中的比特流根据不归零(Non-Return-to-Zero,NRZ)法进行编码。这意味着在总比特时间内,生成的比特电平要么是“显性”要么是“隐性”。

详细说明见另一篇博文《CAN 总线 之 BOSCH CAN2.0 比特位填充(编码规则)、归零编码(RZ)和不归零编码(NRZ)》

消息传输

  消息即总线上传输的节点的信息。其实就是一些固定长度的不同格式的比特位电平的组合。消息传输由四种不同的帧类型显示和控制:

  • 数据帧(DATA FRAME): 将数据从发送器传送到接收器。
  • 远程帧(REMOTE FRAME): 由总线单元发送,以请求传输使用相同的IDENTIFIER 的 DATA FRAME。
  • 错误帧(ERROR FRAME): 在检测到总线错误时,任何单元都会发送错误帧。
  • 过载帧(OVERLOAD FRAME): 用于在前一个和后一个DATA或REMOTE FRAME之间提供额外的延迟。

DATA FRAME 和 REMOTE FRAME 通过 INTERFRAME SPACE 与前一帧分离。

数据帧(DATA FRAME)

  DATA FRAME 由 7 个不同的位域组成:START OF FRAME、ARBITRATION FIELD、CONTROL FIELD、DATA FIELD、CRC FIELD、ACK FIELD、END OF FRAME。 其中,DATA FIELD 长度可以为 0。帧格式如下图所示:

一个完整的数据帧(忽略位填充的情况下)图示如下:


下面详细介绍一下每一部分。

帧起始(START OF FRAME)

  标志着 DATA FRAME 和 REMOTE FRAME 的开始。它占 1 个比特位,必须为显性电平
  只有在总线空闲时才允许站点开始传输(参见 BUS IDLE)。 所有站必须同步到由首先开始传输的站的 START OF FRAME(参见’HARD SYNCHRONIZATION’)引起的前沿。

仲裁域(ARBITRATION FIELD)

由 IDENTIFIER 和 RTR-BIT 组成。共占 12 个比特位。如下图:

  • 标识符(IDENTIFIER): IDENTIFIER 的 长度为 11 个比特位。 这些位按 ID10 ~ ID0 的顺序发送。 最低有效位是 ID0。7 个最重要的位(ID10 ~ ID4)不能全部为隐性电平
  • RTR 位(RTR BIT): 全称 Remote Transmission Request BIT。占 1 个比特位。在 DATA FRAME 中,RTR BIT 必须是 显性电平。 在 REMOTE FRAME 内 RTR BIT 必须是 隐性电平

在数据帧和具有相同标识符的远程帧同时发送的情况下,由于数据帧标识符之后的 RTR 位是显性,它将赢得仲裁。

控制域(CONTROL FIELD)

  由六个比特位组成。 它包括 DATA LENGTH CODE 和 为未来扩展保留的两位。 保留位必须为显性电平。 接收器在所有组合中接受“显性电平”和“隐性电平”位。

  DATA LENGTH CODE 指示了 DATA FIELD 中的字节数,使用如下的代码指示。该数据长度为4个比特位

从物理上来说,4 位的数据长度代码还可以传输 9-15 的值,但是数据段依旧被限制到 0 ~ 8。部分控制器允许传输或接收大于 8 的 DATA LENGTH CODE 值,但是实际数据长度仍然限制在 8 位。

数据域(DATA FIELD)

  在 DATA FRAME 内要传输的数据。 它可以包含 0 ~ 8 个字节,每个字节包含 8 位,首先传输 MSB。

CRC 域(CRC FIELD)

  由 CRC SEQUENCE 和 CRC DELIMITER 两者组成。共占 16 个比特位(15 + 1)

  • CRC SEQUENCE: 多项式为 X15 + X14 + X10 + X8 + X7 + X4 + X3 + 1。计算范围:帧起始,仲裁字段,控制字段,数据字段(如果存在)。
  • CRC DELIMITER: 必须是一个比特位的隐性电平

应答域(ACK FIELD)

  ACK FIELD 占 2 个比特位,ACK SLOT 和 ACK DELIMITER 各占一个比特位。

  • ACK SLOT: 发送器发送数据时,必须发送隐性电平。当接收器正确接收到数据(已经接收到匹配的 CRC SEQUENCE)后,接收器将 ACK SLOT 置为显性电平,将此情况报告给发送器。
  • ACK DELIMITER: 必须一直是 1 个比特位的隐性电平

帧结束(END OF FRAME)

  每个 DATA FRAME 和 REMOTE FRAME 由一个由 7 个比特位的隐性电平位组成的标志序列分隔。

远程帧(REMOTE FRAME)

  通过发送 REMOTE FRAME,需要数据的节点可以请求另一节点发送相应的 DATA FRAME。 DATA FRAME 和相应的 REMOTE FRAME 由相同的 IDENTIFIER 命名。
  通常,数据传输是在数据源节点(例如传感器)发出数据帧的情况下自主执行的。但是,目标节点也可以通过发送远程帧来从信息源请求数据。
  远程帧由以下 6 个不同的位域组成:START OF FRAME、ARBITRATION FIELD、CONTROL FIELD、CRC FIELD、ACK FIELD、END OF FRAME。格式如下图所示:

  与 DATA FRAME 相反,REMOTE FRAME 的 RTR 位是 1 个比特位的隐性电平。 没有 DATA FIELD。CONTROL FIELD 中的 DATA LENGTH CODE 字段表示所请求的消息的数据长度(可以是0 ~ 8),而不是发送的数据长度。

在数据帧和具有相同标识符的远程帧同时发送的情况下,由于数据帧标识符之后的 RTR 位是显性,它将赢得仲裁。

错误帧(ERROR FRAME)

  CAN 网络具有严格的错误诊断功能,该功能都是直接在 CAN 芯片中集成的,硬件直接处理整个过程。一旦错误被检测,正在传送的数据帧将会立即停止而待总线空闲时再次重发直至发送成功,该过程并不需要 CPU 的干涉除非错误累计该发送器退隐(Bus Off)。
  在发送或者接收报文时,总线上的节点如果检测出了错误,那么该节点就会发送 ERROR FRAME,以通知总线上的其他节点。ERROR FRAME 由 Error Flag 和 Error Del imiter 两个不同的位域组成。长度为 6 ~ 12个比特位的显性电平或者是隐性电平

  • Error Flag: 是不同节点提供的错误标志(ERROR FLAG)的叠加。错误标志分为两种:

    • 主动错误标志(ACTIVE ERROR FLAG): 6 个比特位的显性电平,这将破坏“位填充”原则。由总线上错误状态为“主动错误”的出错的节点传送
    • 被动错误标志(PASSIVE ERROR FLAG): 6 个比特位的隐性电平,由总线上错误状态为“被动错误”的出错的节点传送
  • Error Delimiter: 是错误界定符。8 个比特位的隐性电平。在传输 ERROR FLAG 后,每个站先发送 1 个比特位的隐性电平,然后监视总线,直到它检测到隐性电平 之后它开始传输剩余 7 个比特位的隐性电平

  检测到错误状态的“错误激活”站通过传输 ACTIVE ERROR FLAG 来发出信号。 ERROR FLAG 的形式违反了从 START OF FRAME 到 CRC DELIMITER 应用于所有字段的位填充法(参见CODING)或破坏固定格式 ACK FIELD 或 END OF FRAME 字段。 结果,所有其他站检测到错误状况,并且他们也开始传输错误标记。 因此,实际上可以在总线上监视的“显性”比特序列是由各个站发送的不同ERROR FLAG的叠加产生的。 该序列的总长度在最小值6和最多12位之间变化。
  检测到错误条件的“错误被动”站试图通过传输被动错误标志来发出信号。 “错误被动”站从 PASSIVE ERROR FLAG 开始处等待六个相等极性的连续位。 当检测到这 6 个相等位时,PASSIVE ERROR FLAG 完成。

规范中第 6 个章节专门介绍错误处理
啥是被动错误?啥是主动错误?规范中第 7 个章节专门介绍错误界定!

过载帧(OVERLOAD FRAME)

  当某个节点快要忙死的时候,规范规定节点可以告诉其他节点,我要休息一会!方式就是发送过载帧,但是,过载帧不是你发就能发的。必须得注意时机。
  OVERLOAD FRAME 包含两个位字段 OVERLOAD FLAG 和 OVERLOAD DELIMITER。有两种过载条件可导致过载帧的传输:

  1. 接收器的内部条件,要求延迟下一个数据帧或远程帧。这种情况下只允许在预期的 INTERMISSION 的第一位时间开始发送过载帧
  2. INTERMISSION 期间检测到一个比特位的显性电平。在检测到显性位后一位开始发送过载帧。
      INTERMISSION 由 3 个比特位的隐性电平组成,只有在第 1 个比特位或者第 2 个比特位检测到显性电平,才允许从第三个比特位开始发送过载帧。如果在第 3 个比特位检测到“显性”电平,则其他节点将不会正确解释 OVERLOAD FLAG。而是将这6个“显性”位中的第一个比特位解释为 START OF FRAME。 第六个“显性”位违反了位填充规则导致错误条件

  由于存在多个节点同时过载且过载帧发送有时间差问题,可能出现过载标志叠加。最多可生成两个 OVERLOAD FRAME 以延迟下一个数据帧或远程帧

  • OVERLOAD FLAG: 由 6 个比特位的显性电平组成。OVERLOAD FLAG 的所有形式和错误帧(ERROR FRAME)中主动错误标志的所有形式是一样的。
      由 6 个比特位的显性电平组成的 OVERLOAD FLAG 会破坏 INTERFRAME SPACING 中 INTERMISSION 字段的固定形式。 因此,所有其他站也会检测到 OVERLOAD 条件,并且开始传输过载标志。
  • OVERLOAD DELIMITER: 由 8 个比特位的隐性电平组成。OVERLOAD DELIMITER 与 ERROR DELIMITER 的格式相同。 在传输 OVERLOAD FLAG 后,该站监视总线,直到它检测到从“显性”位到“隐性”位的转换。 此时,每个总线站都已完成发送其 OVERLOAD FLAG,并且所有站都开始传输 7 个及以上的比特位的隐性电平

帧间间隔(INTERFRAME SPACING)

  DATA FRAME 和 REMOTE FRAME 与前面的帧(数据帧、远程帧、错误帧、过载帧)通过一个称为 INTERFRAME SPACING 的位字段分隔开。

重载帧和错误帧之前没有 INTERFRAME SPACING,多个重载帧之间也没有 INTERFRAME SPACING。帧间隔过后,如果无节点发送帧,则总线进入空闲。

对于非“错误被动”或已接收上一条消息的站:

对于已经传输上一条消息的“错误被动”的站:

  • INTERMISSION: 3 个比特位的隐性电平。在 INTERMISSION 期间,不允许任何站发起 DATA FRAME 或 REMOTE FRAME 传输。 唯一可做的就是发出 OVERLOAD 条件。
  • BUS IDLE: 可以是任意长度个比特位的隐性电平。总线被认为是空闲的时候,任何有东西要传输的站都可以访问总线。如果在其他消息传输期间挂起了本消息,那么被挂起的消息必须在 INTERMISSION 的后一个比特位开始传输。总线上检测到的显性电平 的位可被解释为帧的起始。
  • SUSPEND TRANSMISSION: “错误被动”站发送消息后,在开始发送另一条消息或识别总线空闲之前,它会在中断后发送 8 个比特位的隐性电平。如果与此同时另一站开始发送消息(由另一站引起),则此站就作为这个消息的接收者。

接收器/发送器

TRANSMITTER: 发起消息的单元称为该消息的 “TRANSMITTER”。 设备保持 TRANSMITTER 直到总线空闲或设备丢失 ARBITRATION。
  如果在 END OF FRAME 结束之前没有错误,则该消息对发送器有效; 如果消息出现了错误,则将根据优先级自动执行重新传输。 为了能够与其他消息竞争总线访问,一旦总线空闲,就必须重新开始重传。
RECEIVER: 如果一个单元不是该消息的 TRANSMITTER 并且总线不空闲,则该单元被称为消息的 “RECEIVER”。
  如果在 END OF FRAME 的最后一位之前没有错误,则该消息对接收器有效。

参考

  1. 维基百科—— CAN BUS
  2. BOSCH CAN2.0 规范 Part A 部分
  3. https://blog.csdn.net/u012252959/article/details/83054474

CAN 总线 之四 BOSCH CAN2.0 Part A相关推荐

  1. CAN 总线 之六 BOSCH CAN 比特位填充(编码规则)、归零编码(RZ)和不归零编码(NRZ)

    帧格式   在 CAN 总线中,为了确保足够的转换以保持同步,在相同极性的 5 个连续位之后使用位填充.下面以 标准格式来进行说明,先看下面标准格式的帧的图示: 在某些文档中,将 CAN 帧分为以下部 ...

  2. CAN总线(三)——CAN FD协议及其与CAN2.0的异同

    目录 1. CANFD的来历 2.  CANFD与CAN的协议异同 3. CANFD帧结构解析 3.1 帧起始 3.2.仲裁域 3.3 控制域 3.4 数据域 3.5 CRC 3.6 ACK 3.7 ...

  3. 细说汽车电子通信总线之CAN 2.0 总线协议详解

    引言 1. CAN总线发展历史与ISO规范 2. CAN总线主要功能特性 3. CAN 2.0总线协议的物理层电气特性 4. CAN 2.0总线协议消息报文详解 4.1 CAN2.0总线的通信报文帧格 ...

  4. can总线不加末端电阻_细说汽车电子通信总线之CAN 2.0 总线协议详解

    引言 1. CAN总线发展历史与ISO规范 2. CAN总线主要功能特性 3. CAN 2.0总线协议的物理层电气特性 4. CAN 2.0总线协议消息报文详解 4.1 CAN2.0总线的通信报文帧格 ...

  5. CAN2.0和J1939协议的关系

    转发自http://www.cankau.cn/support/help/can-vs-j1939.html 很长时间没搞明白j1939与CAN2.0的关系,这篇文章让我明白了. CAN2.0是一种总 ...

  6. CAN总线(二)——CAN2.0标准与协议分析

    目录 1. CAN 协议的基本概念 2. CAN 协议及标准规格 2.1 ISO 标准化的 CAN 协议 2.2 ISO11898 和 ISO11519-2 的不同点 3. CAN协议 3.1 帧的种 ...

  7. CAN 总线 之七 BOSCH CAN 位时序 和 同步

      CAN 支持 1 kBit/s 至 1000 kBit/s 的比特率.CAN 网络的每个节点都有自己的时钟发生器,通常是石英振荡器. 可以为每个 CAN 节点单独配置比特时间的定时参数(即比特率的 ...

  8. [VPX611]基于 6U VPX 总线架构的SATA3.0 高性能数据存储板

    板卡概述 VPX611 是一款基于6UVPX 总线架构的高性能数据存储板,该板卡采用2 片XilinxKintex-7 系列FPGA 作为主控单元,FPGA 内嵌RAID 控制器,最大支持8 个mSA ...

  9. USB总线-Linux内核USB3.0设备控制器之UDC驱动分析(六)

    1.概述 UDC驱动的接口都定义在drivers/usb/gadget/udc/core.c文件中.USB Function驱动通过调用这些接口匹配及访问USB设备控制器,而底层USB控制器驱动要实现 ...

最新文章

  1. DOS BAT用法简例子
  2. node.js 爬虫中文乱码 处理
  3. app专项测试(稳定性测试、安全性测试)
  4. shell day01 : Shell概述 编写及执行脚本 、 Shell变量
  5. const的使用CC++
  6. java 正则 实例_Java正则表达式实例详解
  7. 【收藏】SonarQube-插件-离线安装PMD+阿里P3C
  8. VTK:可视化之Opacity
  9. linux系统查看进程并杀掉,Linux如何查找8080进程并杀掉该进程
  10. Confluence 插入符号和特殊字符
  11. python 修改文件内容3种方法,Python实现修改文件内容的方法分析
  12. ubuntu系统下载路径(可以收藏免得以后再找)
  13. 电脑代理上网和共享上网
  14. 车型识别API调用对比
  15. Anaconda安装报错(Failed to create Anaconda menus)
  16. 基因组选择的几个概念
  17. 武汉的二本计算机学校有哪些,武汉二本大学有哪些学校
  18. 面试 - 阿里华为资深HR面试套路全揭晓
  19. 2020软件测试工程师面试题汇总(内含答案)-看完BATJ面试官对你竖起大拇指!
  20. symbian字体使用方法汇总

热门文章

  1. 腾讯面试后续 | 掘金技术征文
  2. Django框架----Object Relational Mapping(ORM)
  3. Dynamic AX ERP 4.0 数据导出(上)
  4. Mockito对final类型和方法的支持(三):免配置的inline mock making
  5. C#综合揭秘——细说多线程(上)
  6. 学习资源之4:Linux
  7. matlab仿真计算代码代写,matlab/simulink程序代写
  8. 前端趋势榜:上周最有意思、又实用的 10 大 Web 项目 - 210821
  9. k8s拉取私有仓库镜像:通过config.json文件或命令行来创建secret(docker-registry)
  10. centos7.x 64位 rpm安装JDK8