CAN和CANFD协议简介（下）

前篇内容请点击查看：

RA MCU CAN和CANFD IP介绍

CAN和CANFD协议简介（上）

2. CAN协议

2.2 协议层

前文讲述了CAN的物理层标准，约定了电气特性，以下介绍的协议层则规定了通讯逻辑。

2.2.1 帧的种类

通信是通过以下5种类型的帧进行的。

• 数据帧

• 遥控帧

• 错误帧

• 过载帧

• 帧间隔

在这些帧当中，数据帧和遥控帧由用户设定，其他的帧由CAN的硬件部分完成。

另外，数据帧和遥控帧有标准格式和扩展格式两种格式。标准格式有11位的ID，扩展格式具有29位ID。

各种帧的用途如下表所示。

2.2.2 数据帧

数据帧把消息从发送单元传到接收单元，是用户使用的最基本的帧。数据帧由7个段构成。

(1) 帧起始：表示数据帧开始。

(2) 仲裁段：表示该帧优先级的段。

(3) 控制段：表示数据的字节数及保留位。

(4) 数据段：数据本身，可传送0～8个字节。

(5) CRC段：检查帧的传送错误的段。

(6) ACK段：正常接收确认段。

(7) 帧结束：表示数据帧结束。

2.2.3 遥控帧

接收单元向发送单元请求消息所用的帧。遥控帧由6 个段组成，也可以说是没有数据段的数据帧。

(1) 帧起始（SOF）：表示帧的开始。

(2) 仲裁段：表示该帧优先级的段。请求具有同样ID的数据帧。

(3) 控制段：表示所请求数据的字节数及保留位。

(4) CRC段：检查帧的传送错误的段。

(5) ACK段：正常接收确认段。

(6) 帧结束：表示遥控帧结束。

关于遥控帧和数据帧：

• 数据帧和遥控帧有何不同

遥控帧没有数据段，仲裁段的RTR位为隐性电平。

没有数据段的数据帧和遥控帧可通过RTR位区别开来。

• 遥控帧没有数据段，数据长度码该如何表示？

遥控帧的数据长度码以所请求数据帧的数据长度码表示。

• 没有数据段的数据帧有何用途？

可用于各单元的定期连接确认/应答、或仲裁段本身带有实质性信息的情况下。

2.2.4 错误帧

在收发信中发现错误时用于通知错误的帧。错误帧由错误标志和错误间隔符构成，错误帧的发送是由CAN的硬件部分来完成的。

(1) 错误标志：错误标志包括有效错误标志和无效错误标志两种。

• 有效错误标志：6位显性电平。

• 无效错误标志：6位隐性电平。

(2) 错误间隔符：错误间隔符由8位隐性电平构成。

注

1. 有效错误标志：处于错误有效态的单元检出错误时传送的错误标志。

2. 无效错误标志：处于错误无效态的单元检出错误时传送的错误标志。

3. 错误标志的重合：由连接到总线上的各单元的错误检出时间不同，错误标志会发生重合，最长可延续到12位。

2.2.5 过载帧

过载帧是用于接收单元通知其尚未完成准备所用的帧。过载帧由过载标志和过载间隔符构成。

(1) 过载标志：6位显性电平。过载标志的构成与有效错误标志的构成相同。

(2) 过载间隔符：8个隐性位。过载间隔符的构成与错误间隔符的构成相同。

注

1. 过载帧的重合：与错误标志一样依据发生时序不同过载标志也会发生重合，最长可延迟到12位。

2.2.6 帧间隔

帧间隔用于分隔数据帧或遥控帧。数据帧或遥控帧前插入帧间隔可将本帧与前面发送的任何帧（数据帧、遥控帧、错误帧、过载帧）分开。但是，过载帧和错误帧前不能插入帧间隔。

(1) 间隔：3位隐性电平。在“间隔”期检测到显性电平时，一定要发送过载帧。然而，在间隔期的第3位出现的显性电平被认为是SOF，此时不发送过载帧。

(2) 总线空闲：隐性电平，无长度限制（0位亦可）。本状态为总线处于空闲中，要发送的单元可开始发送消息。

(3) 延迟传送（发送暂时停止）：8个隐性电平。处于错误无效态的单元在发送完一个消息后的帧间隔中必须包含的段。

2.2.7 优先级的仲裁

在总线空闲态，最先开始发送消息的单元获得通信权。

多个单元同时开始传送时，各发送单元从仲裁段的第一位开始进行仲裁。位电平第一次出现不同而且位电平为显性的单元获得通信权发送。仲裁失败的单元在下一个位开始进入接收状态。

仲裁的过程如下图所示：

(1) 数据帧和遥控帧的优先级

具有同样ID的数据帧和遥控帧在总线上竞争时，仲裁段的最后一位（RTR）为显性电平的数据帧具有优先权，可继续通信。

(2) 标准格式和扩展格式的优先级

具有相同基本ID的标准格式与扩展格式的数据帧或遥控帧在总线上竞争时，由于标准格式的RTR位为显性电平，具有更高的优先权，可进行发送。

2.2.8 错误的种类

错误共有5种。有时数种错误同时发生。

• 位错误

• 填充错误

• CRC错误

• 格式错误

• ACK错误

错误的种类、错误的内容、出错的帧和检出错误的单元如下表所示。

2.2.9 位时序

一个位可分为4段。

• 同步段(SS: Synchronization Segment)

• 传播时间段(PTS: Propagation Time Segment)

• 相位缓冲段1(PBS1: Phase Buffer Segment 1)

• 相位缓冲段2(PBS2: Phase Buffer Segment 2)

这些段由最小时间单位Tq(Time Quantum)构成。

消息中的1位被分为4个段，每个段又由若干个Tq构成，这称为位时序。

消息中的1位由多少个Tq构成、每个段又由多少个Tq构成、这些是可以任意设定的。通过设定位时序，总线上数个单元可以以相同的时序对消息采样，可以设定采样点。采样点设置在PBS1的结束处，以此时检测到的总线上的电平值作为该位的电平值。

各段的用途和Tq数如下表所示。

1位的构成如下图所示。

2.2.10 取得同步的方法

CAN 协议的通信方法为非归零NRZ(Non-Return to Zero)方式。每个位上没有开始或终了的同步信号。发送单元以与位时序同步的方式开始发送数据。接收单元根据总线上电平的变化进行同步接收信号。

但是，发送单元和接收单元存在的时钟频率误差及传送路径上的（电缆、驱动器等）相位延迟会引起同步偏差。因此接收单元通过强制同步、再同步的方法调整时序进行接收。

2.2.11 强制同步

接收单元在总线空闲状态检出帧起始时进行的同步调整。检出从隐性电平到显性电平的边沿时被认为是SS段，与SJW无关。

2.2.12 再同步

在接收过程中根据总线上的电平变化进行的同步。

检出边沿（总线上的电平跳变）时，对照误差值并且根据SJW值延长PBS1段，或缩短PBS2段，以配合同步。但如果发生了超出SJW值的误差，按照SJW值作修正。

2.2.13 同步规则

强制同步和再同步遵从如下规则。

(1) 1 位中只进行一次同步调整（两次采样点间）。

(2) 只有当边沿后的总线电平与边沿前一个总线采样值不同时，该沿才能用于同步。

(3) 一旦检测到隐性电平到显性电平的边沿，如果满足条件(1)、(2)须进行同步。

(4) 帧间隔(“间隔”的第1位除去)中检测到隐性电平到显性电平的边沿时，须进行强制同步。

(5) 其他所有的隐性电平到显性电平的边沿，须进行再同步。

(6) 发送单元观测到自身输出的显性电平有延迟时不进行再同步。

2.3 CANFD框架

CAN FD可以理解成CAN协议的升级版，只升级了协议，物理层未改变。

CAN FD协议引入了经过调整的CAN数据帧，以实现额外的数据字节和灵活的比特率。

下面我们比较一个11位的传统CAN帧与一个11位的CAN FD帧（同时也支持29位）：

下面我们一步一步地讨论这些差异：

RTR与r1(RRS)：传统CAN中使用了远程传输请求Remote Transmission Request（RTR）来识别数据帧和相应的远程帧。但在CAN FD中，不支持远程帧，远程请求替换（r1）始终是显性（0）。

在CAN-FD帧中，在控制字段中添加了三个新位（FDF、BRS、ESI位）：

• 扩展数据长度 Extended Data Length （EDL）：隐性表示帧为CAN-FD，否则该位为显性（称为R0）在CAN 2.0帧中。在传统CAN格式的帧中，所对应传输的是位R0而不是EDL。

• 比特率切换 Bit Rate Switch（BRS）：指示是否启用两个比特率。如果是隐性，则比特率从仲裁阶段的标准比特率切换到数据阶段的预配置交替比特率。如果是显性，则不切换比特率。

• 错误状态指示器 Error State Indicator（ESI）：表示发送节点状态，指示节点处于错误活动模式还是错误被动模式。

DLC：像在传统CAN中一样，CAN FD DLC是4位，表示帧中数据字节的数量。下表显示了这两种协议如何始终使用多达8个数据字节的DLC。为了维持4位DLC，CAN FD使用从9到15的其余7个值来表示所使用的数据字节数（12、16、20、24、32、48、64）。

CRC：传统CAN中的循环冗余校验（CRC）为15位，而在CAN FD中为17位（最多16个数据字节）或21位（20-64个数据字节）。在传统CAN中，CRC中可以包含0到3个填充位，而在CAN FD中，总是有四个固定填充位以提高通信可靠性。

总结起来，CAN和CANFD协议是一种常用于汽车和工业领域的通信协议。CAN协议是一种高效可靠的串行通信协议，而CANFD协议在保持CAN协议基本特性的基础上增强了数据传输速率和数据长度。这两种协议都在车辆电子系统中扮演着重要的角色，实现了车内各个电子设备之间的可靠通信。

更多内容，您可复制下方网址到浏览器中打开进入瑞萨中文论坛查看：

https://community-ja.renesas.com/zh/forums-groups/mcu-mpu/