CAN与CAN-FD总线通信深度解析：从物理层到调试实战

1. 为什么总线通信是嵌入式系统的神经系统做嵌入式开发十几年我越来越觉得一个系统里最容易被低估、又最容易出问题的部分就是设备之间的通信。你想想一辆车里有几十甚至上百个电子控制单元从发动机管理到车窗升降从刹车防抱死到座椅记忆它们之间要不停地交换数据。如果每个模块都单独拉一根线那线束会粗得像一棵树重量、成本、故障率全都失控。所以从很早开始工程师们就在琢磨一件事能不能用一根或两根线把所有节点串起来让它们按规则轮流说话这就是总线通信的出发点。而在这个领域里CANController Area Network控制器局域网是绕不开的一座山。它诞生于上世纪八十年代最初就是为了解决汽车内部通信的可靠性问题。你可能会问为什么偏偏是它活了下来而不是别的什么协议答案藏在它的设计哲学里不追求带宽最大而是追求在最恶劣的电磁环境下、在最关键的瞬间数据一定能送达。这个关键瞬间就是安全气囊要不要弹、刹车要不要介入这类决定生死的事情。我见过不少刚入行的朋友一上来就盯着以太网、盯着各种高速总线觉得CAN太老土了。但实际做项目你就会发现只要涉及分布式控制、涉及多节点协同、涉及对实时性和可靠性的硬要求CAN几乎总是那个最稳妥的起点。它就像城市里的红绿灯系统——不炫酷但没它整个交通就乱了。这篇文章我想把CAN和它的升级版CAN-FDFlexible Data-rate灵活数据速率从底层到应用讲透包括帧结构、仲裁机制、位定时计算、常见坑点以及在实际项目中怎么选型、怎么调试。不管你是刚接触总线的新手还是已经用过但总觉得知其然不知其所以然的老手应该都能从里面找到点有用的东西。2. CAN总线的物理层与差分信号两根线背后的抗干扰逻辑2.1 为什么是双绞线而不是单根线先说说物理层因为很多通信问题最后查下来都是物理层没搞对。CAN用的是差分信号也就是两根线CAN_H和CAN_L。这两根线通常拧在一起做成双绞线。为什么要拧因为双绞线能让外界电磁场在两根线上感应出的干扰几乎相等而接收端只看两根线的电压差共模干扰就被抵消掉了。这个原理和平衡音频线、以太网双绞线是一样的。具体电平上CAN总线有两种状态显性Dominant和隐性Recessive。显性状态下CAN_H大约3.5VCAN_L大约1.5V压差约2V隐性状态下两根线都接近2.5V压差接近0V。注意这个命名很有意思——显性会覆盖隐性就像逻辑与里的0会覆盖1一样。这个特性是后面仲裁机制的基础非常关键。提示如果你用示波器抓CAN波形看到的是两根线的电压但真正有意义的是它们的差值。很多新手直接看单根线觉得波形怪怪的其实要减一下才对。2.2 终端电阻那个120欧姆不是随便选的CAN总线两端各需要一个120欧姆的终端电阻并联起来就是60欧姆。这个电阻的作用是消除信号在总线末端的反射。你可以把总线想象成一根水管信号是水波如果末端是开口的波会反射回来和后面的波叠加导致波形畸变。终端电阻就是给波一个吸收口让它到末端就消失。我踩过的一个经典坑有次调试一个只有两个节点的短总线心想线这么短终端电阻不接应该也没事吧结果通信时好时坏偶尔丢帧。后来老老实实把两个120欧姆接上立刻稳定。原因是即使线短阻抗不匹配依然会造成反射只是程度轻一点但在高波特率下就足以让采样点采错。终端电阻的功率也要注意。一般用1/4瓦就够了因为总线平均电流不大。但如果你在实验室用可调电源直接给总线供电测试要小心别把电阻烧了。另外终端电阻必须接在总线的两个物理末端不能接在中间分支上否则起不到吸收反射的作用。2.3 总线拓扑与分支长度限制CAN标准推荐的是线性总线拓扑也就是一根主干节点通过短分支挂上去。分支长度不能太长一般建议单分支不超过0.3米而且波特率越高分支要越短。为什么因为分支相当于一段 stub信号进去会反射回来分支越长反射越严重。实际布线时很多人图方便把节点随便接在主干的不同位置甚至搞成星形。星形拓扑在CAN里是大忌因为每个分支都会产生反射多个反射叠加起来波形就烂了。如果实在需要星形得用CAN集线器或者中继器但那又增加了成本和延迟。我个人的经验是在画板子之前先把总线拓扑画出来标好每个节点的位置和分支长度。如果发现某个节点离主干太远宁可调整布局也别硬拉一根长分支。这个习惯能帮你省掉后面大量的调试时间。3. CAN帧结构拆解从仲裁场到CRC场的逐位分析3.1 标准帧与扩展帧的区别CAN帧分标准帧和扩展帧。标准帧用11位标识符扩展帧用29位。标识符不是地址而是消息的优先级和内容标识。这一点和很多总线不一样——CAN不是点对点寻址而是广播式所有节点都能收到然后根据标识符决定要不要处理。标准帧的结构大致是帧起始SOF1位、仲裁场11位标识符 RTR位、控制场IDE、r0、DLC共6位、数据场0到8字节、CRC场15位CRC 1位界定符、ACK场2位、帧结束7位。扩展帧在仲裁场里多了18位标识符和SRR、IDE位结构更复杂一些。为什么要有两种因为早期11位够用后来需求多了11位不够分配就扩展成29位。但扩展帧的仲裁场更长传输效率略低所以如果标识符需求不复杂标准帧更划算。实际项目中我一般建议能用标准帧就用标准帧除非确实需要大量不同的消息ID。3.2 仲裁机制为什么CAN能做到不撞车这是CAN最精妙的地方。多个节点同时想发数据怎么办CAN用的是非破坏性逐位仲裁。每个节点在发送标识符的每一位时同时也在监听总线。如果它发的是隐性逻辑1但总线上是显性逻辑0说明有更高优先级的节点在发它就立刻退出转为接收。标识符数值越小优先级越高。这个机制的好处是仲裁过程中获胜的那帧数据完全不受影响不需要重发总线利用率极高。你可以把它想象成一群人同时想说话规则是谁说的第一个字编号最小谁先说而且其他人一发现自己编号大就立刻闭嘴不打断。我见过有人问如果两个节点发完全相同的标识符怎么办答案是这本身就是设计错误。CAN要求同一总线上的标识符必须唯一至少对于需要区分的消息。如果两个节点发相同ID但不同数据就会产生错误帧通信会乱。所以分配ID时一定要做好规划最好建一张表记录每个ID的用途、发送节点、周期。3.3 数据长度码与CAN-FD的扩展经典CAN的数据场最多8字节DLCData Length Code用4位表示取值0到8。到了CAN-FD数据场最多可以到64字节DLC的编码方式也变了0到8还是对应0到8字节但9到15分别对应12、16、20、24、32、48、64字节。这个映射不是线性的得查表。为什么CAN-FD要扩到64字节因为现代汽车里有些数据比如摄像头预处理结果、雷达点云摘要8字节根本不够如果拆成多帧发开销大、延迟高。FD把单帧容量提上去减少了协议开销。但要注意数据场变长后CRC也变长了从15位变成17位或21位而且填充位规则也变了这些后面细说。4. 位定时与采样点一个让无数人栽跟头的参数4.1 位时间的组成CAN是异步通信没有单独的时钟线所以每个节点必须自己根据波特率来采样。一个位时间被分成若干段同步段Sync_Seg、传播段Prop_Seg、相位缓冲段1Phase_Seg1、相位缓冲段2Phase_Seg2。采样点就在Phase_Seg1和Phase_Seg2之间。这些段用时间份额Tq来衡量。Tq 1 / (波特率 × 每位的Tq数)。比如波特率500kbps每位20个Tq那Tq就是100纳秒。同步段固定1个Tq其他段可配置。采样点位置 (Sync_Seg Prop_Seg Phase_Seg1) / 总Tq数。一般推荐采样点在75%到80%之间。为什么因为信号在总线上传播有延迟而且不同节点的晶振有偏差采样点太靠前容易采到还没稳定的电平太靠后容易采到下一个位的跳变。4.2 晶振偏差与同步机制每个节点都有自己的晶振频率不可能完全一样。CAN靠硬同步和重同步来调整。硬同步发生在帧起始节点检测到SOF的下降沿时把自己的位时间对齐。重同步发生在帧中间如果检测到边沿比预期早或晚就调整Phase_Seg1或Phase_Seg2的长度最多调整SJW同步跳转宽度个Tq。SJW一般设为1到4个Tq。设太小同步能力弱晶振偏差大时容易出错设太大又可能影响采样点稳定性。我一般建议如果总线上节点晶振精度是±0.5%以内SJW设2到3个Tq就够如果有些节点用廉价陶瓷谐振器精度差SJW要适当加大同时采样点也要留更多余量。4.3 一个真实的位定时计算案例假设你要配500kbps主频8MHz想用20个Tq。那么Tq 1 / (500k × 20) 100ns。预分频器 主频 × Tq 8M × 100n 0.8不对应该是主频 / (波特率 × Tq数) 8M / (500k × 20) 0.8这不对说明8MHz主频配不出20个Tq的500k。重新算如果预分频器取1Tq 1/8M 125ns每位Tq数 1/(500k × 125n) 16。所以用16个Tq。然后分配Sync_Seg1Prop_Seg2Phase_Seg17Phase_Seg26采样点 (127)/16 62.5%有点靠前。调整Prop_Seg3Phase_Seg18Phase_Seg24采样点 (138)/16 75%比较理想。这个计算过程看起来简单但实际配寄存器时很多芯片的段定义和上面略有不同有的把Prop_Seg和Phase_Seg1合并有的叫法不一样。一定要对着芯片手册的位定时图来配别凭记忆。我见过有人把Phase_Seg1和Phase_Seg2搞反结果通信完全不通查了一整天。5. CAN-FD带来的变化不只是更快5.1 可变数据速率与双波特率CAN-FD最核心的变化是支持两种波特率仲裁段用标准波特率比如500kbps数据段可以切换到更高的波特率比如2Mbps、5Mbps。为什么仲裁段不加速因为仲裁需要所有节点都能正确比较位如果速率太高传播延迟和晶振偏差的影响会放大仲裁容易出错。所以仲裁段保持稳健数据段才提速。这个切换靠帧里的BRS位Bit Rate Switch控制。BRS1时从BRS位之后开始切换到数据波特率到CRC界定符之前切回仲裁波特率。实际配置时你需要设置两组位定时参数一组给仲裁段一组给数据段。很多芯片的CAN-FD控制器都支持这种双配置。5.2 CRC与填充位的变化经典CAN的CRC是15位FD因为数据更长CRC扩展到了17位数据≤16字节或21位数据16字节。另外FD的填充位规则也变了经典CAN是每5个相同位插入一个相反位FD在数据段改用固定填充——每4位插入一个填充位而且填充位的位置是固定的不依赖数据内容。这样做是为了简化收发器的处理提高速率。这些变化意味着如果你用经典CAN的分析仪去抓FD帧可能会解析错误。必须用支持FD的工具。我在项目里就遇到过用老工具抓FD总线看到的全是错误帧换了新工具才正常。5.3 实际选型什么时候用CAN什么时候上FD不是所有项目都需要FD。如果你的数据量小、节点少、对成本敏感经典CAN完全够用而且生态成熟、工具便宜。FD适合这些场景需要传输较大数据块比如标定数据、诊断数据、需要更高带宽比如多个传感器融合、或者总线负载已经很高需要提速。但上FD也有代价收发器要换FD收发器对时序要求更严、线束和终端电阻要求更高、调试工具更贵、节点间的兼容性要确认FD节点和经典CAN节点混在一个总线上需要特殊处理否则经典节点会因为FD帧的快速位而报错。我一般建议新项目如果预判未来数据量会涨直接上FD老项目升级先评估总线上所有节点是否都支持FD否则就维持经典CAN。6. 调试实战从通信不上到稳定跑满负载6.1 排查链路先物理后协议通信出问题我的排查顺序永远是物理层→位定时→标识符分配→软件逻辑。物理层先看终端电阻对不对、总线电压对不对、有没有短路断路。用万用表测CAN_H和CAN_L之间的电阻断电应该是60欧姆左右两个120并联。如果测出来是120说明只接了一个终端电阻如果是40说明多接了如果是无穷大说明断路。然后看波形。用示波器看差分信号显性电平够不够2V隐性是不是接近0V边沿有没有过冲或振铃。如果波形很烂先解决物理层别急着调软件。6.2 总线负载率与延迟计算总线负载率 所有帧的传输时间之和 / 单位时间。比如500kbps下一帧标准帧约110位传输时间约220微秒。如果每秒发1000帧负载率就是22%。一般建议负载率不超过50%留余量给突发和错误帧。如果超过70%延迟会明显变大实时性没保证。计算延迟时要考虑最坏情况最高优先级帧的等待时间 传输时间。如果总线上有低优先级帧在发高优先级帧要等它发完才能仲裁。所以设计时要把最关键的帧设为最高优先级ID最小并且控制低优先级帧的长度和频率。6.3 常见错误帧与处理CAN有五种错误位错误、填充错误、CRC错误、格式错误、ACK错误。每种错误都会导致错误帧发送错误计数器增加。如果错误计数器超过255节点会进入总线关闭状态停止通信。我遇到最多的是ACK错误——发送节点没收到任何节点的应答。原因可能是总线上没有其他节点、其他节点没上电、波特率不匹配、或者接收节点过滤掉了这个ID。排查时先确认有没有其他节点在正常工作再看波特率是否一致最后查过滤器配置。注意错误计数器是诊断通信问题的重要线索。很多CAN控制器可以读取发送错误计数器和接收错误计数器通过它们的变化能快速定位是发送方问题还是接收方问题。7. 从沙子到车辙一个工程师的通信观写到这里我想起标题里的从沙子到车辙。沙子是硅的原料车辙是车辆走过的痕迹。从一粒沙子到一条能跑车的路中间是无数层抽象和工程妥协。CAN总线也是这样从物理层的电压差到帧结构的位仲裁到位定时的纳秒级计算再到应用层的消息调度每一层都在为可靠两个字服务。我个人的体会是做通信不要只盯着协议文档要多动手、多抓波形、多算参数。很多问题在纸面上看不出来一上总线就暴露了。另外别迷信标准配置每个项目的总线长度、节点数量、电磁环境都不一样位定时和终端电阻要针对具体情况调。我见过太多人直接抄别人的配置结果在自己的板子上就是不通。最后分享一个小技巧如果你手头没有专业的CAN分析仪可以用两块支持CAN的开发板一块发一块收自己写个简单的收发程序也能完成基本的通信验证。虽然不如专业工具方便但胜在灵活、便宜适合前期摸底。等确认基本通信没问题了再上专业工具做详细分析。这个思路我在好几个项目里都用过挺管用的。