CAN总线-ACK应答机制分析

1：应答场定义

应答场长度为 2 个位，包含应答间隙（ACK SLOT）和应答界定符（ACK DELIMITER）。在应答场里，发送站发送两个“隐性”位。当接收器正确地接收到有效的报文，接收器就会在应答间隙（ACK SLOT）期间（发送 ACK 信号）向发送器发送一“显性”的位以示应答。

2：ACK应答机制浅析

CAN的发送是个双向互动过程，发送节点在发送数据的同时会对总线上数据进行回读以及Ack Slot场的判定；接收节点在发送节点发送过程中需及时确认报文正确性并令总线上ACK SLOT位置 “显性”，以告知发送节点数据正常接收；

CAN是一种基于广播的通讯方式，为了保证总线上的每一个节点都能正确的接收到报文，报文的发送者要求每一个接收节点在报文发送结束前，也就是ACK SLOT 的时间内，作出应答，即在ACK段上，要求接收节点在报文正确性的基础上及时发送一个“显性”位。发送者在发送的同时会监视总线上的数据，如果与发送的数据不一致，则表示发送失败或自己失去仲裁，立即停止发送或转入接收模式。由于发送者在发送数据的同时会向ACK段连续写入2个隐性位，如果发送者在回读过程中监控到ACK SLOT 位为“显性”位，则说明接收者已正确接收；如果发送者在回读过程中监控到ACK SLOT 位为“隐性”位，则说明没有节点正确接收该报文，则发送者会检测到这个隐性位而知道发送失败，此条报文需要重发。

多节点接收工况下若出现仅单节点正确接收，那么又会出现什么情况呢? 由于某节点正常接收，基于线与机制总线上ACK SLOT 位必定为“显性”，隐性失效，从而可以说明：ACK场是用于确定报文被至少一个节点正确接收。该工况下就无法基于ACK场进行判断，但会触发错误帧相关机制，立即开始发送一个错误帧，则接下去总线上的信号就是这个错误帧，其它的节点和发送者也都会收到这个错误帧，那所有的节点都知道出错了，接收者会丢掉此次消息，而发送者会试图重发此次消息。
3：ACK应答机制框图

补充：1 通道表征发送节点的 TX；2 通道表征发送节点的 RX；3 通道表征接收节点的 TX；4通道表征接收节点的 RX；

CAN总线-错误处理机制分析

在工作中提及CAN错误大家首先会想到的是Busoff故障，但是大家考虑过CAN总线是如何诊断出Busoff故障？总线上那种状态属于故障状态？总线故障后立即触发Busoff吗？总线故障后如何恢复？那么下面将带着这些问题对CAN总线的错误处理机制进行分析。

CAN总线错误处理机制：

错误检测
错误界定
错误处理

错误检测机制：

CAN总线的回读机制、循环冗余检查、位填充和报文格式检查保证了CAN总线数据交互的准确性，当然也为此提供了5种CAN错误类型【位错误，位填充错误，CRC错误，格式错误，ACK错误】;如果总线上检测到此类错误，那么必定会触发相应CAN节点的动作，但是是否触发Busoff并非取决于CAN错误类型而是取决于CAN节点的错误状态；

位错误：发送的数据和总线上的电平不一致【仲裁段及ACK段属于特例】
    位填充错误：连续检测到6个同极性电平
    CRC错误：当接收方接收到的数据计算出的CRC值与接收到的CRC不一致
    格式错误：接收到的帧和规定的帧格式不一致
    ACK错误： ACK slot 场为隐性电平

错误界定及处理机制：

错误界定并非是依据错误的类型去界定CAN节点的错误状态，而是依据错误计数器【TEC/REC】的值来界定CAN节点的错误状态；错误状态分为三种：主动错误状态、被动错误状态和总线关闭态；这样分类的目的又是什么呢？可以理解成是依据当前节点的错误累积程度区分不同的错误等级，不同错误等级对应不同的动作，从而保证CAN总线上其他节点的正常交互。即：“量变引起质变的过程”；当该节点检测到错误后，内部REC/TEC计数器会相应的增加，基于REC/TEC的值判定节点状态；

网络上很多资料针对 “主动与被动” 关键字眼对主动错误状态与被动错误状态进行区分，看了许久未曾想通，反而越发迷茫；个人感觉不需过分纠结主动及被动字眼，理解成不同的错误等级即可，重点关注的是这几种状态下CAN总线允许该节点做哪些动作以及如何去动作；

主动错误状态：【REC<127 且TEC<127】

初步可判定该节点相对稳定可靠，该错误计数很可能是由于X节点异常导致的，那么其他节点很可能也会触发该错误，那么允许该节点破坏CAN总线的异常报文并告知其他节点；

如果该节点是发送节点，相当于报文发送时自检出错误，将发送错误帧“6个连续显性位”至CAN总线，破坏总线异常数据，并告知其他节点请勿接收；
如果该节点是接收节点，相当于报文接收时校验出错误，该错误很可能是由于发送节点异常导致的，其他节点接收时很可能也会校验出错误，那么允许该接收节点发送错误帧“6个连续显性位”至CAN总线，破坏总线异常数据，并告知其他节点；

被动错误状态：【REC>128 或TEC>128】

初步可判定该节点相对不可靠，该错误计数很可能是由于自身节点问题导致，即该错误很可能仅有该节点才有，对于其他节点而言是可以正常交互的，总线不信任该节点提供的错误标识，将不允许破坏总线数据，那么允许该节点发送错误帧“6个连续隐性位”至CAN总线，仅告知其他节点异常；

如果该节点是接收节点，该错误很可能是由于自身节点问题导致，其他节点可以正常接收，不存在此类错误，即仅允许该异常节点发送6个连续隐性位告知错误，但不影响总线电平以及其他节点的正常接收；
如果该节点是发送节点，检测到错误后会立即发送“6个连续隐性位”告知其他接收节点请勿接收该报文；由于该发送节点处于被动错误状态，那么将在下一帧发送之前传送一个间歇场【3个隐性位】和挂起传送场【8个隐性位】，使总线处于总线空性态，将该被动错误状态节点挂起，总线控制权交由其它待发送节点；

总线关闭状态：【TEC>255】

当发送错误计数TEC>255时才会触发该状态，使该节点处于总线关闭态；
复位或者等待传送128次11位隐性电平的时间后，重新加入活动，并且TEC/REC清零；

CAN总线-错误处理机制分析

CAN总线错误处理机制：

错误检测
错误界定
错误处理

错误检测机制：

错误界定及处理机制：

主动错误状态：【REC<127 且TEC<127】

被动错误状态：【REC>128 或TEC>128】

总线关闭状态：【TEC>255】

当发送错误计数TEC>255时才会触发该状态，使该节点处于总线关闭态；
复位或者等待传送128次11位隐性电平的时间后，重新加入活动，并且TEC/REC清零；

————————————————
版权声明：本文为CSDN博主「Royal Air」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/m0_37280790/article/details/88082681

一、五种CAN总线可能发生的错误

1、CRC错误：

接收节点计算出的CRC校验值，与发送节点计算的结果不一致；

2、格式错误：

传输的数据帧格式，与任何一种帧格式都不符；

3、应答错误：

ACK段，发送节点没有收到接收节点发出的应答（显性位）；

单节点的CAN设备发送数据帧时为发生应答错误；

4、位发送错误：

发送过程中，发送节点发送的同时监听总线电平，如果总线电平和发送的不一致；

在仲裁域发现不同不报错，因为就是要仲裁掉优先级低的报文；

发送被动错误标志、主动错误标志期间检测总线电平有6个相同位时；

5、位填充错误：

帧起始到CRC之间，接收节点检测到有6个连续相同的位电平时，也就是违反5位相同位插入1位相反位的“位填充”原则；

因为ACK域和帧结束域电平固定，也无需填充；

二、三种错误状态

主动错误标识——6个显性位、由主动错误节点发出

被动错误标识——6个隐性位、由被动错误标志发出

错误界定符——8个隐性位

1、主动错误

因为主动错误标识由6个显性位组成，可以理解为破坏“位填充”原则，一个节点发现通信错误时，它会主动将帧彻底破坏掉，让其他节点知道它接收出错了；

CAN总线的特点是“广播”，也就是总线上一个节点发出，其余所有节点均能正确接收，如果有一个或多个节点由于某种原因出现接收错误，那么这个节点会主动站出来，通过发送不符合“位填充”规则的帧错误帧，来彻底把这一帧破坏掉，以通知其他节点“这一帧我接收错了，不算数，重来”，其他节点也许没有错，但是也会在收到主动错误标识后发出一个主动错误标识；发送节点在发送的同时也会监听总线数据，当发现数据被其他节点“破坏”后,会主动进行数据重发。

由CAN控制器自动完成。

错误不多，不是我导致的，我主动发送错误标识，通知其他节点放弃这一帧，我正常收发；

2、被动错误

错误比较多，很可能错误是由我导致的，我通知其他节点有错但是不干扰他们正常收发数据，也不要求重发，同时我不能连续发送了，得再插入8位隐性位的“延迟传送”段；这样是为了让其他正常节点（处于主动错误）优先使用总线；

被动错误的节点很可能存在硬件故障，不能让它拖累整个网络；

3、总线关闭

错误太多，是我的问题，我停止收发并脱离总线；

总线上数据的收发都被禁止；
————————————————
版权声明：本文为CSDN博主「Elsa Duan」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_22433397/article/details/78320970

CAN总线-ACK应答机制分析相关推荐

Kafka Ack应答机制理解
背景最近李哥做了kafka的调研,我看了他做的kafka与rabbitmq的对比与性能分析,打算深入了解一下kafka的ack应答机制 1.kafka基础大家可自行学习 2.这里我直接分析下ack应 ...
Kafka 生产者数据安全（ACK机制，ACK时机，ACK应答机制，故障处理，Exactly Once）
目录生产者数据安全一.数据分区图解分区原因分区原则二.数据可靠性保证 ACK机制 ACK时机 ACK应答机制故障处理 Exactly Once 语义生产者数据安全一.数据分区图解 ...
linux内核的I2C子系统详解3——i2c-core.c初步分析、I2C总线的匹配机制
以下内容源于朱有鹏<物联网大讲堂>课程的学习,如有侵权,请告知删除. 5.i2c-core.c初步分析 (1)smbus代码略过:smbus是基于I2C总线发展出来的. (2)模块加载和卸 ...
TCP协议可靠性保证（确认应答机制，超时重传机制，流量控制，拥塞窗口）
上一次我们知道了TCP协议通过连接管理机制保证可靠性,今天我们继续来看一看TCP协议中其他几种保证可靠性的方法. · 确认应答机制 · 超时重传机制 · 流量控制 · 拥塞窗口确认应答机制 ...
pcie握手机制_【博文连载】PCIe扫盲——Ack/Nak 机制详解（一）
原标题:[博文连载]PCIe扫盲--Ack/Nak 机制详解(一) 前面在数据链路层入门的文章中简单地提到过Ack/Nak机制的原理和作用,接下来的几篇文章中将对Ack/Nak机制进行详细地介绍. A ...
TCP的状态：SYN, FIN, ACK, PSH, RST, URG 简介及 ACK确认机制
1.TCP的状态FLAGS字段状态在TCP层,有个FLAGS字段,这个字段有以下几个标识:SYN, FIN, ACK, PSH, RST, URG. 对于我们日常的分析有用的就是前面的五个字段:它们 ...
libpcap捕包机制分析（三）
目前,在linux操作系统下的网络数据包捕获系统普遍是建立在libpcap捕包平台上的,libpcap的英文意思是Library of Packet Capture,即数据包捕获函数库.该库提供的C函 ...
can总线配置读入是什么意思_STM32学习笔记—CAN总线收发数据常见问题分析
CAN,Controller Area Network(控制器局域网络),在汽车电子.工业控制领域的应用比较多,通常用于局域组网. 这是第9篇学习分享文章,<STM32学习笔记>之CAN总 ...
以修改注册表的方式避免ACK确认机制带来的延时现象
TCP本身属面向链接的通讯协议.通讯双方的每一个收发动作,需要以通讯链路正常为前提.因此TCP协议内部提供了默认的ACK验证机制. 假定A.B之间存在一条TCP通讯链路,某一时刻A第一次向B发送数据, ...

CAN总线-ACK应答机制分析

CAN总线-ACK应答机制分析相关推荐

最新文章

热门文章