1. 先把“CAN”这个词拆开争议才有解前几天在一个技术群里两位工程师为一个问题争了半个多小时CAN 到底算协议还是算接口。一方摆出证据——它有帧格式、有位仲裁、有 CRC 校验、有错误计数器是一整套完整的通信规则这不明摆着是协议另一方同样有依据——平时开口就是“这块板子给我留两路 CAN”“这个屏是 CAN 接口的”明明是当插口在用怎么就成协议了。两个人说的其实都对只是站在了不同的层面上说话谁也没往下追一步。我做过几年车载和工业控制相关的项目这个问题被问过不止一次而且每次问的人出发点都不一样。刚入行的想搞清楚概念画原理图的想知道该关注哪几个引脚写驱动的想知道该配哪些寄存器做系统集成的想知道采购清单上那行字到底指什么。如果没有把这件事说透后面就容易出现一种很尴尬的局面硬件说“我给了你两路 CAN”软件说“我只看到一个控制器”最后发现两个人从头到尾说的不是同一个东西。这篇东西想解决的就是这一件事把“CAN”这个词在不同语境下的含义一层层拆开说清楚哪一层是协议、哪一层是接口、哪一层是芯片外设、哪一层是插头以及这个区分在实际选型、配置和排错里到底会带来什么影响。不管你是刚接触总线的学生还是已经在画板子、调波形的工程师看完至少能保证在开会时不会跟人各说各话。中间我会给出一套可直接照做的排查顺序和几个参数计算示例都是我在项目里反复用到的。1.1 同一个词被用在六个不同的层次上“CAN”这三个字母在实际工作中至少承担了六种指代而且这六种指代经常出现在同一场对话里这才是混乱的根源。第一层是规范文档指的是一整套白纸黑字写下来的标准文本规定了电平、时序、帧结构、错误处理第二层是协议也就是这套规范里关于“怎么说话”的那部分规则——什么时候可以发、冲突了怎么办、对方没应答怎么办第三层是控制器指的是单片机或 SoC 内部那个负责组装和解析帧、计算 CRC、做位填充的硬件外设它输出的是普通的单端逻辑电平第四层是收发器是一颗独立的芯片负责把控制器出来的逻辑电平转换成总线上的差分电平同时把总线上的差分电平转回来第五层是连接器与线束就是你能用手摸到的插头、端子、双绞线第六层是软件接口即驱动向上层暴露的那套 API打开设备、配置波特率、发送一帧、注册接收回调。这六层里只有第二层能严格叫“协议”只有第五层和第四层的组合最接近工程师口中的“接口”。但日常交流没人会把层数说全于是“给我留两路 CAN”这句话可能是“两个控制器外设”可能是“两个收发器通道”也可能是“两个物理连接器”还可能是“两个可以独立配置波特率的逻辑通道”。这几种理解在成本、PCB 面积、软件复杂度上差得很远。我见过一个项目需求文档写的是“预留两路 CAN 接口”硬件按两个并联的连接器做软件按两个独立控制器写联调时才发现板子上只有一个控制器两个连接器在电气上根本就是同一路没法同时跑不同速率。这不是谁不专业是从需求提出那一刻起词就没对齐。我的建议很土但很有效在需求文档和原理图评审里把“路”这个字拆成三个字段写——控制器数量、收发器数量、连接器数量。这三个数字可以相等也可以不等写清楚了后面所有争论自动消失。1.2 用寄快递的类比把协议和接口彻底分开我习惯用寄快递来解释这件事几乎每个被我解释过的人都能一次听懂。协议相当于快递行业的整套规则面单怎么填、收件人和地址写在哪一栏、包裹超重怎么算、签收要不要拍照、投递失败几次算异常件、异常件怎么退回。这套规则决定了包裹能不能准确送到、出了问题谁负责。接口相当于你家楼下那个快递柜或者门禁对讲——它是物理的、能看见能摸到的东西决定了快递员有没有一个入口把东西交给你。这两者缺一不可但坏起来的表现完全不同。规则出问题表现为包裹送错人、重复投递、丢了没人认账——对应到 CAN 上就是 ID 配错、波特率不匹配、采样点不一致导致的偶发错误帧、应答丢失。入口出问题表现为快递员压根进不了小区——对应到 CAN 上就是终端电阻没焊、线接反了、收发器没供电、双绞线断了一根。你会发现这两类故障的排查手法完全不同前者要翻配置、看时序、抓报文后者拿万用表和示波器五分钟就能定位。分不清协议和接口最直接的后果就是排错方向从一开始就是反的——有人抱着示波器去查 ID 冲突也有人对着代码找了两天最后发现是终端电阻少焊了一个。还有一个更微妙的点快递规则可以升级比如新增了“必须本人签收”的条款但你家的快递柜不用换。CAN 从经典格式演进到可变速率格式本质就是规则升级了一次而总线还是那两根线、接头还是那个接头——这本身就证明了协议和接口是可以分开演进的两件事。1.3 一张表看清六个层次各自管什么下面这张表是我自己整理的一页速查贴在工位上用了很久。它解决的问题是当有人跟你说“CAN 有问题”时你能在三秒内判断该找谁、该拿什么工具。层次具体指什么典型载体出问题时的表现主要排查工具规范文档电平、时序、帧格式、错误处理的完整定义标准文本、协议手册一般不会“坏”但容易被误读手册原文协议仲裁规则、帧类型、CRC、错误计数与故障界定控制器内部的协议引擎偶发错误帧、总线关闭、优先级倒挂总线分析仪、报文记录控制器组装解析帧、位填充、验收滤波的硬件外设单片机内部模块收不到帧、滤波器把帧挡了、邮箱满寄存器、驱动日志收发器单端逻辑电平与差分总线电平互转独立芯片完全不通、波形畸变、发热万用表、示波器连接器与线束插头、端子、双绞线、屏蔽层DB9、插拔端子、圆形航空插头时通时断、抗干扰差、接反万用表、目视软件接口驱动向上层暴露的 API 与数据结构驱动库、内核子系统打开失败、发送阻塞、接收丢帧日志、抓包把这六层摆在桌面上之后那个原始问题就有了一个干净的回答**CAN 在严格意义上是协议而且是同时覆盖数据链路层和物理层电气部分的一套规范工程口语里的“CAN 接口”指的是这套协议在物理世界的落地形态包括收发器、连接器和线束。**两者不是二选一的关系是同一件事在抽象层和物理层的两个名字。下面两章分别从协议和接口两个方向把这个结论撑起来。2. 协议视角CAN 的规则全都写在帧里判断一样东西是不是协议最朴素的标准是它有没有规定“谁在什么时候可以说话、说的话长什么样、说错了怎么办”。CAN 这三条全占了而且规定得相当细。它的帧结构、仲裁机制和错误处理构成了一个自洽的体系任何一家厂商的控制器只要按这套规则实现就能和另一家的节点在同一根线上共存——这种互操作性正是协议存在的意义。我经常跟新人说你不需要背下每一个字段但你必须理解三件事帧怎么组织、冲突怎么解决、错误怎么被发现和隔离。这三件事理解了剩下的都是查表。2.1 四种帧类型撑起了协议的骨架CAN 总线上跑的不止一种帧。数据帧负责携带实际内容是绝大多数业务通信使用的那一种远程帧用于请求对方发送指定 ID 的数据实际项目里用得很少因为它会引入额外的不确定性错误帧由检测到错误的节点主动发出用来通知全网“刚才那一帧有问题”过载帧用于接收方还没准备好时请求延迟。数据帧的字段排布本身就是协议的体现。开头是一位帧起始把总线从空闲拉出来接着是仲裁段标准格式里是 11 位标识符加一位远程帧标志扩展格式里是 29 位然后是控制段包含标识符扩展位、保留位和数据长度码中间是数据段经典格式最多 8 字节后面是 15 位CRC 段加一位界定符再往后是应答段发送方发隐性位任何正确接收的节点都会把它拉成显性等于集体签字确认最后是 7 位帧结束把总线拉回隐性。这套结构里有两个细节特别值得注意。第一个是数据长度码只有 4 位所以经典格式的上限被卡在 8 字节——这不是随意定的而是在当年总线速率有限、实时性要求高的背景下做的权衡字节数越多一帧占用的时间越长高优先级消息的等待时间就越不可控。第二个是应答段的设计不是指定某一个节点应答而是所有正确接收的节点一起把这一位拉成显性。这带来一个副作用发送方只知道“至少有一个节点收到了”不知道是谁收到了。这个特性在很多现场故障里是关键线索——如果发送方报应答错误说明总线上没有一个节点能正确接收问题往往在物理层或者波特率如果发送方一切正常但某个特定节点没反应那问题多半在接收端的滤波器、ID 配置或者应用层。2.2 位仲裁协议层最值得琢磨的一个设计CAN 最有意思的地方在于它允许多个节点同时开始发送而且不会因此丢数据。这套机制叫非破坏性位仲裁靠的是两个约定总线上显性位压过隐性位标识符数值越小优先级越高。具体怎么运作的所有想发数据的节点先监听总线发现空闲后同时发出帧起始位然后逐位往外发自己的标识符。每一位发出后节点都会回读总线上的实际电平。如果自己发的是隐性位但读回来是显性位说明有别的节点正在发一个更小数值的 ID自己输了立刻停止发送、转为接收状态等下一次总线空闲再重来。赢的那个节点完全感觉不到有人跟它竞争帧继续往下发一个位都不会丢。举个例子三个节点同时要发标识符分别是 0x0F0、0x123、0x150。从最高位比起第一个不同的位置就分出胜负0x0F0 的高位更小一路都是显性会把另外两个都压下去。输的节点不会产生错误帧也不会重传同一帧——它们只是退让等这帧结束后按优先级重新竞争。这个设计带来两个实践中必须知道的后果。**第一高优先级帧会饿死低优先级帧。**如果总线上周期性发的高优先级帧足够多低优先级帧可能永远抢不到总线。我遇到过一次某个诊断报文要等十几秒才发出去一算负载率已经到 70% 以上了把几条非关键的周期性报文周期从 10 毫秒放宽到 100 毫秒问题立刻消失。**第二标识符分配是一门学问。**别图省事按设备顺序编号要按消息的实时性要求来分安全相关的、控制闭环的用小 ID状态上报的、诊断的用大 ID。等到系统跑起来再想调整 ID那就是牵一发动全身的活儿。2.3 错误检测与故障界定协议自带的免疫系统CAN 在协议层内置了一整套错误检测机制这是它能在电磁环境恶劣的场合活下来的重要原因。检测手段有五种位错误节点发出去的电平和回读的不一致填充错误位填充规则被破坏CRC 错误接收端算出的校验值和帧里带的对不上格式错误固定格式位出现了不该出现的电平应答错误发送方在应答位没等到任何人拉显性。其中位填充这条规则经常被忽略但它是协议层的一部分和插头没有任何关系。规则是从帧起始到 CRC 段结束连续出现 5 个相同电平发送方必须插入一个相反电平接收方看到连续 5 个相同电平就自动把下一位丢掉。这样做是为了保证总线上的跳变足够多接收方能持续从跳变沿恢复时钟——如果没有这条规则一长串相同电平会让接收端的位定时漂移采样点落到错误的位置。检测到错误之后的处理更能体现设计意图。每个节点维护两个计数器发送错误计数和接收错误计数。计数正常时节点处于错误主动状态发现问题就主动发错误帧把这一帧作废让全网重来发送错误计数超过 127 之后进入错误被动状态只能被动标记错误不再主动打断总线——这是为了防止一个本身有问题的节点把整条总线搞瘫痪发送错误计数超过 255 时进入总线关闭状态节点主动脱离总线停止收发。恢复方式由软件决定可以等一段冷却时间后自动重连也可以要求上位机下发指令才恢复。注意总线关闭之后不做任何处理是新手最容易留下的一类问题。表现是设备“突然就不通信了”重启就恢复过一阵又复发。一定要在驱动里加上总线关闭的回调处理并记录发生次数和发生时的错误计数这两个数字对定位物理层问题极有价值。2.4 从经典格式到可变速率格式变的是规则插头几乎没动后来演进出的可变速率格式是理解“协议与接口分开”这件事最好的例子。它的核心改动有三处数据段可以切换到时基更短的高速率仲裁段还是用原来的速率保证兼容数据长度码扩展单帧最多能带 64 字节把小包拼大包的开销省下来了校验算法加固加入了填充位计数和固定填充位把原来残余的错误漏检概率又压低了一截。这里的关键在于这些改动全部发生在协议层。总线上还是那两根差分线电平定义没变终端电阻还是 120 欧姆连接器还是那些连接器。真正需要换的是收发器——因为速率上去了收发器的上升下降时间、环路延时必须跟得上老型号在高速率下波形会明显变圆。所以你会看到一个很典型的场景同一块板子换一颗支持高速率的收发器再改几行控制器配置协议就升级完了线束一根没动。如果 CAN 只是一根“接口”这种升级是不可能发生的正因为规则和物理形态是分离的它才能这样平滑地演进。3. 接口视角电气和机械上的硬性约束把视角切换到接口这一侧逻辑就完全变了。这里没有“谁先说话”的问题只有电压够不够、阻抗配不配、线长超没超、插头对不对。这一层的错误往往是确定性的——接反了就是不通电阻少一个就是不稳不用怀疑测一下就知道。我个人的经验是现场报“CAN 通信异常”七成以上能在这一层找到原因而且大部分用万用表和示波器十几分钟就能定位。可惜很多人第一反应是去翻代码。3.1 控制器、收发器、总线三个必须分开说的东西这三个东西经常被混成一句“CAN 芯片”。控制器在单片机内部是一个数字外设它的工作是按协议规则组装和解析帧、算 CRC、做位填充、跑错误计数器、按滤波器决定收不收这一帧。它的引脚输出的是普通单端逻辑电平也就是 0 和电源电压。收发器是一颗模拟为主的小芯片输入端接控制器的收发引脚输出端接总线负责把单端逻辑转成差分电平、把总线上的差分电平转回单端同时还承担总线故障保护、共模抑制这些活儿。总线就是那对特性阻抗 120 欧姆的双绞线。为什么必须分清因为“这块芯片不支持 CAN”这句话指的可能是完全不同的三件事。可能是单片机的控制器外设数量不够这要靠换型号或者外扩解决可能是板上压根没焊收发器很多核心板为了省成本只把控制器的引脚引到排针上收发器留了空焊盘也可能是收发器焊了但供电没接对某些型号需要 5V某些能宽压工作混着用就会出现“逻辑能通、总线不通”的现象。我见过一次很典型的返工一块板子怎么都不通信示波器量控制器出来的收发引脚波形很漂亮量总线却是一潭死水最后发现收发器的使能脚被默认拉到了一个无效状态飞线改了一个电阻就好了。所以在原理图评审时我坚持要看三个独立的数字控制器外设几路、收发器几颗、连接器几个。这三个数字对不上一定要当场问清楚。3.2 差分电平与终端电阻接口层的两条硬性规则总线的电平定义很简洁。显性状态下两条线的电平被分别拉高和拉低差分电压大约 2 伏隐性状态下两条线都处于中间的偏置电压差分接近 0 伏。接收端的判定阈值大致是差分电压超过 0.9 伏判为显性低于 0.5 伏判为隐性中间是不确定区。这个设计的好处是即使线上有相当程度的共模干扰只要两条线一起漂差分值基本不变接收端照样能判对——这就是差分传输抗干扰的根本原因也是为什么这两根线必须绞在一起走绞距越密共模干扰被抵消得越彻底。终端电阻是另一个硬指标。高速总线的两端各要接一个 120 欧姆电阻跨接在两条信号线之间。为什么是两端而不是一端、为什么是 120 而不是别的值因为双绞线的特性阻抗大约是 120 欧姆信号传到头如果没有匹配的负载就会反射回来和后续的信号叠加在高速率、长线的情况下直接把波形搞花。两端各接一个 120 欧姆从任意一点看进去是两个 120 欧姆并联后与线路阻抗匹配等效 60 欧姆。所以有一个非常实用的现场判断方法断电用万用表电阻档量两条信号线之间正常应该读到 60 欧姆左右。读到 120 欧姆说明只接了一端读到无穷大说明两头都没接或者线断了读到明显小于 60 欧姆说明某处短路或者有人多接了一个。这个方法能在三十秒内排掉一大类故障我基本上每次到现场第一件事就是做它。注意测量前一定要断开所有节点的供电带电测电阻不但读数不准还可能损坏万用表。另外某些节点的收发器内部集成了一部分终端功能断电后可能影响读数遇到读数奇怪的情况要先把节点逐个拔掉再测。电阻的功率也有讲究。有人问要不要用 1 瓦的其实没有必要——显性状态虽然电流不小但单帧的显性时间很短平均功耗远低于峰值常规的 1/4 瓦贴片足够只要注意别把两个电阻叠在一起贴着塑料件就行。3.3 速率、线长、节点数接口层的预算怎么算接口层的所有约束归根到底都指向一个物理事实**信号在线上跑是有延时的而且必须在一个位时间内跑完一个来回才能完成仲裁和应答。**这就是为什么速率和线长是一对死绑的关系。下面这张表是行业里流传很广的经验值我在实际项目里试过基本吻合可以当预算用波特率单段最大线长经验值典型应用场景1 Mbps约 40 米短距离高实时性控制500 kbps约 100 米车载动力与底盘常见档位250 kbps约 250 米商用车、工程机械125 kbps约 500 米工业现场、楼宇50 kbps约 1000 米长距离低速采集20 kbps约 2500 米超长距离、极低速场合这张表的用法不是“正好卡在边界上”而是留出余量。我一般的做法是把实际线长控制在表内数值的 60% 到 70%剩下的余量用来对付线材批次差异、接头接触电阻和温度变化。曾经有一个项目500 kbps 跑了 95 米实验室里一切正常装到现场夏天中午就开始偶发错误帧后来把速率降到 250 kbps 就彻底稳了。不是因为 95 米超过了 100 米的限值而是因为余量太小任何一点参数漂移都会把它推出安全区。节点数量同样有个上限但这个上限更多取决于收发器的输入阻抗而不是协议本身。每个节点挂在总线上都会带来一定的负载节点越多总的差分负载越重显性时的差分电压就越低低到一定程度接收端就判不出来了。保守的做法是单段不超过 32 个节点如果需要更多就用中继或者分段。还有个容易被忽略的点是支线长度从主干线分出去到节点的这一段在高速率下要尽量短一般控制在 0.3 米以内。支线就是一段没有终端匹配的短线它会把信号反射回主干支线越长反射越明显。我见过一个机柜所有节点都从一条主线上用长线并出来每根支线接近 1 米500 kbps 下根本通不了改成分段加中继之后立刻正常。3.4 五花八门的连接器同一个协议不同的插头到了连接器这一层可以说是百花齐放同一个协议能长出十几种不同的物理形态这也是“接口”这个词最容易被误解的地方——很多人说的“CAN 接口”其实指的是某个特定形状的插头。常见的几种9 针 D 型连接器在工业设备和调试口上很常见信号定义基本上是 2 脚接负极性信号线、3 脚接地、7 脚接正极性信号线但这套定义并不是强制标准不同厂商的引脚分配存在差异接线前必须查对方的手册。车载诊断口是一个 16 针的梯形接口其中两针给一组总线、另两针给另一组还有电源和地。插拔式接线端子在工业控制柜里最常见通常标着正、负、地三个位。圆形航空插头用在高振动、需要防护的场合。还有一些设备会用网线接口的外形来跑这路总线这种最容易让人误判看到网口就以为是以太网。线材也有讲究。要用特性阻抗 120 欧姆的双绞线两根信号线对绞有屏蔽层更好。屏蔽层的接地方式是个老话题两端都接在某些场合会形成地环流反而把干扰引进来一端接抗干扰能力会打折。我自己的习惯是短距离、单机柜内部两端接地问题不大跨机柜、长距离、接地电位差明显的场合只在主控端接另一端通过一个小电容接地。这个做法不是教条具体还得看现场但至少比“随手两头一拧”强得多。4. 分不清会怎样选型、配置、排错三处的实际影响前面讲的是概念这一章讲后果。概念上的模糊不会立刻出问题它会在某个具体的节点上以某种具体的形式炸出来而且往往是返工级别的。我把这些年遇到的案例归了三类选型时把接口当协议、配置时把协议参数当接口参数、排错时从错误的层次入手。这三类问题的共同点是只要事先把层次说清楚全都可以避免。4.1 选型时把接口当协议买回来对不上这是最常见也最贵的一类。某项目需求写的是“需要两路独立 CAN”采购按“两个接口”理解选了一块带两个连接器的板子。硬件工程师拿到手才发现板子上只有一个控制器、一颗收发器两个连接器是从同一对线并联引出来的。电气上它们是同一个通道不可能一个跑 500 kbps 一个跑 250 kbps也不可能做双通道冗余。返工方案要么换板要么外挂一个控制器模块工期直接推了两周。还有个反向的例子另一位同学要的是“两个连接器”方便菊花链布线结果供应商给了一块双控制器的板子成本上去了不说多出来的那一路还得在软件里屏蔽掉白白增加复杂度。我的处理办法是在需求阶段就把三个问题问死**需要几个能独立配置速率的逻辑通道需要几个物理连接器这两个数字是不是必须相等**如果需求方说“我就要两个插口随便插哪个都行”那就是并联引出一路控制器足够如果说“我要同时接两个不同速率的子系统”那必须是两个独立控制器。这两种需求的成本差距可能是几倍。4.2 位时序配置协议参数配在控制器里位时序是最能体现“协议参数落在硬件外设里”的地方。它不是接口参数插头和线材怎么换都改不了它但它配错了表现却很像物理层故障——偶发错误帧、通信不稳定、长线尤其明显。配置的核心是把一个位时间切成若干份每份叫一个时间份额。整个位时间由四段组成同步段、传播段、相位缓冲段一、相位缓冲段二。采样点就在相位缓冲段一结束的位置。举个具体例子假设控制器时钟 8 MHz目标速率 500 kbps。第一步算位时间1 除以 500000等于 2 微秒。第二步选时间份额数取 16 份则每份 125 纳秒。第三步算分频8 MHz 的周期是 125 纳秒正好一份所以分频系数取 1。第四步分配各段同步段 1 份、传播段 5 份、相位缓冲段一 6 份、相位缓冲段二 4 份加起来正好 16 份。采样点位置等于前三段之和除以总份数也就是 12 除以 16等于 75%。如果想按行业常见推荐值把采样点提到 87.5%就改成同步段 1 份、传播段 6 份、相位缓冲段一 7 份、相位缓冲段二 2 份前三段之和 1414 除以 16 正好 87.5%。同步跳转宽度一般取 1 到 2 份用来吸收节点之间的时钟偏差。注意一条总线上所有节点的采样点必须尽量一致差异最好不要超过几个百分点。我踩过一次坑两个厂家的设备一个默认 75%一个默认 87.5%短线测试完全正常接到 60 米线束上就开始偶发错误帧速率降到一半才稳。后来把两边都统一到 87.5%问题消失。所以协议里说的“速率要一致”其实不够采样点也要一致。4.3 排错的顺序从物理层往上别一上来就翻代码排错有一条我坚持了很多年的顺序几乎没失手过先量电阻再量静态电平再看波形再确认速率和采样点然后才是 ID 和周期最后才是应用层信号定义。为什么是这个顺序因为下面几层的错误会以“上面几层出错”的形式表现出来而下面的层次测量成本最低。终端电阻缺一个表现可能是间歇的错误帧看起来像协议问题收发器没供电表现是彻底收不到看起来像驱动没起来波特率差一点表现是偶尔收到一堆错误帧看起来像线束干扰。如果按相反的顺序查你会在代码里找到一百个“可能的原因”然后一个一个排除花掉整整两天。反过来下面几层确认没问题之后往上查就是顺藤摸瓜电阻 60 欧姆正常、静态电平 2.5 伏左右正常、波形干净、速率和采样点都对那问题一定在滤波器和报文配置上如果连滤波器都确认放开了那就只剩应用层的数据解析了。这个顺序不是理论是我被坑出来的——有一次为了一个偶发丢帧我在驱动里加了一堆日志最后发现是接插件松动插拔一下就好的事。5. 常见问题与排查实录这一章是纯经验都是我在实验室和现场反复遇到的。我把它们整理成了一张速查表再加上几个印象比较深的案例。速查表的用法是先看现象再看对应的层次然后按那一列的动作去做不要跳步。5.1 现象与层次对照速查表现象最可能的层次优先动作完全不通信所有节点都收不到接口供电、接线、收发器测信号线电阻测收发器供电检查正负是否接反断电测电阻读到 120 欧姆接口终端电阻补齐缺失一端注意节点内部是否已集成断电测电阻读到无穷大接口断线或双端缺失分段测量逐段断开定位发送方报应答错误接口或速率先查物理层再核对两侧速率短线上正常长线上偶发错误帧协议采样点或速率余量统一各节点采样点降低速率验证只有某个特定节点收不到控制器滤波器或 ID 配置放开验收滤波核对标识符通信一阵后彻底停止重启恢复协议错误计数与总线关闭加总线关闭回调记录错误计数波形上升沿圆钝、幅值偏低接口收发器速率等级或负载过重核对收发器速率等级减少节点或分段高优先级报文正常某条报文长期发不出协议仲裁优先级与总线负载算负载率调整标识符分配与发送周期换一个机柜就变差同一套设备接口屏蔽与接地检查屏蔽层接地方式与地电位差5.2 几个印象比较深的坑第一个坑是终端电阻只焊了一端。板子出厂时两个 120 欧姆电阻都焊了但其中一块板子的电阻位置被误贴了 0 欧姆等于短路。表现是这条支路一接上整条总线就瘫因为等效阻抗被拉得太低显性差分电压被压下去了。这种故障用电阻档一量就露馅量出来只有二十几欧姆。所以我现在量电阻不只是看“有没有 60”还要看“是不是明显小于 60”。第二个坑是两支线太长。一个控制柜里主干线只有 1 米但从主干上分了 6 根支线到各个模块每根 80 厘米。250 kbps 下勉强能跑升到 500 kbps 直接不通。后来把模块改成串接在主干上支线压到 10 厘米以内问题消失。这件事让我后来画任何总线拓扑都先把支线长度标出来超过 30 厘米就必须解释原因。第三个坑是屏蔽层两端接地引进了干扰。一台设备单机测试干干净净装到现场就偶发错误帧。查了整整一天最后发现屏蔽层在两端都接了机柜地而两端的地电位差有将近 2 伏屏蔽层上跑起了环流反而变成了干扰源。改成主控端单点接地之后现场和实验室表现一致了。这个案例说明接口层的问题有时候不是“没做防护”而是“做过头了”。第四个坑是总线关闭没处理。某设备的错误计数被打满进入脱离状态软件里没有任何回调界面上看起来就是“设备在线但不刷新数据”。这种问题最难查因为从外部看设备是活的。后来加了错误计数和总线关闭次数的上报才发现是某个接插件在振动下间歇接触不良导致反复出错。加上上报之后这个硬件问题三天就定位了而在之前它可能藏几个月。5.3 手里那两件工具怎么用万用表承担了八成的初步判断。断电测信号线之间电阻判断终端和短路上电测静态时两条线对地的电压隐性状态下两条线都应该在 2.5 伏附近如果一条明显偏高一条明显偏低说明有节点在持续输出显性或者有节点短路到电源或地再测一下收发器供电脚确认电压在器件要求范围内。示波器负责看波形。最方便的做法是用两个通道分别接两条信号线然后打开数学运算做差直接看差分波形。正常情况下应该看到清晰的方波台阶显性时差分约 2 伏隐性时接近 0 伏边沿干净没有明显的过冲和振铃。如果看到台阶变圆、幅值只有 1 伏出头多半是负载过重或者收发器速率等级不够如果看到明显的振铃和台阶上的台阶基本可以确定终端匹配有问题。提示探地线一定要短最好用探头自带的短弹簧地针。用地线夹子夹一根长线去测测出来的“振铃”很可能是探头地线引入的容易误判。6. 我自己的几条体会写到这里那个最初的问题其实已经有了完整答案CAN 在规范层面是协议而且是同时覆盖数据链路和物理电气的一整套规则工程口语里的“CAN 接口”是这套协议落地时的物理形态。两者不是对立选项是同一件事的两个侧面。真正值得花时间的是那六个层次怎么分、分完之后各自该找谁、该用什么工具——这才是能省钱省时间的地方。几条我自己的做法随手记下来。写需求文档时把“路”拆成控制器数量、收发器数量、连接器数量三个字段这一条至少帮我省过两次返工。画原理图评审时一定要把收发器的使能脚和供电范围单独过一遍很多“莫名其妙不通信”都出在这两个地方。调试时先把万用表拿出来量电阻量电平五分钟能排掉一大半问题比在代码里加日志高效得多。多节点项目在协议文档里明确写死采样点不要指望各家的默认值一样。最后任何产品化的设计都要处理总线关闭的恢复策略并且把错误计数上报出来——这个数字是硬件健康的体温计出事的时候它就是唯一的线索来源。