★ FEATURED ARTICLE 1. 从汽车的“神经”说起CAN 到底是什么聊到 CAN 总线十有八九的场景都和汽车有关。车里现在少说几十个电子控制单元发动机、变速箱、ABS、气囊、仪表盘、车门模块、车灯每个模块都有自己的单片机模块之间要交换转速、油门位置、刹车状态、车门开关信号。如果每个模块之间都拉一堆独立线束整车线束会重到离谱故障点也多到没法排查。CANController Area Network控制器局域网络就是当年为了解决这个痛点被设计出来的——用两条差分线把几十个节点串在一条总线上任何两个节点之间都能通信线束重量骤降可靠性还更高。不过 CAN 早就不只是汽车圈的专属了。工业自动化里伺服驱动器、PLC、传感器组网医疗器械里的床边设备互连船舶电子、农用机械、机器人关节控制器到处都有它的身影。原因很简单CAN 是真正的多主实时总线抗干扰能力强传输距离长而且出错能自动重发这些特性组合在一起是 UART、SPI、I2C 这些常见板级总线很难同时具备的。这篇内容面向两类读者一类是从没接触过 CAN想搞懂协议原理和为什么这么设计的小白另一类是已经会点单片机想快速在 STM32 上把 CAN 跑起来、解决实际问题的开发者。我会把协议机制的“为什么”讲透再把 STM32 上的硬件结构、CubeMX 配置、收发代码、调试经验一条线串下来。很多人在网上搜 CAN 的资料要么是纯理论看不下去要么是直接甩一堆寄存器操作。我希望这篇能把两头接上你读完能理解它为什么这么设计同时能自己动手把工程搭起来遇到问题知道往哪个方向查。2. 为什么嵌入式通信要单拎出来学 CAN2.1 CAN 和常用板级总线的本质区别做嵌入式开发最先接触的通信接口基本都是 UART、I2C、SPI。它们有个共同特点都基于“主机-从机”或者“单对单”模型。UART 只能两个设备点对点SPI 虽然能挂多个从机但片选信号得单独拉线从机之间不能互相通信I2C 是多主总线但速度慢、抗干扰一般地址冲突还麻烦。CAN 不一样。它把 UART 的简单、广播式消息模型和多主自由竞争机制结合到了一起。总线上任何一个节点只要总线空闲就能发起发送所有节点都能同时收到这帧数据然后自己判断要不要接收。这种模型和“微信群聊天”非常像任何一个人都能在群里发言所有人都会看到看到后谁要回应谁回应不用群主来点名。总线拓扑多主机传输距离抗干扰典型速率UART点对点否短几米差115.2kbpsSPI一主多从否板级差可达数十MbpsI2C多主总线是板级较差400kbps / 1MbpsCAN多主总线是可上千米低速强差分信号最高 1Mbps / CAN FD 5Mbps注意 CAN 的标准速率上限是 1Mbps听起来比 SPI 慢很多但它的优势不在速度而在“在恶劣电磁环境下保证数据完整到达”。汽车引擎舱里点火线圈、电机、继电器一大堆普通串口在这种环境下误码率高到没法用。CAN 用差分电压传输再加上协议层的 CRC 校验和错误重发机制可靠性完全不是一个量级。2.2 CAN 的三个核心价值多主、可靠、低成本先说多主。CAN 没有“主机”概念这个设计极大简化了系统架构。传统串口总线如果主机挂了整个网络瘫痪CAN 网络里任何一个节点挂掉其他节点照常通信。实时性也更好紧急数据不用等着主机轮询随时可以抢占总线发送。再说可靠。CAN 协议栈里内置了五类错误检测机制位错误、填充错误、CRC 错误、格式错误、应答错误。发送节点发完一帧会主动监听总线上的反馈发现错误立即停止当前帧发出错误帧然后自动重传。这个“坏了会自动重来”的能力对工业现场太重要了。最后是低成本。两条双绞线就能带上几十个节点节点的控制器也便宜。一个小几百行的协议栈就能跑在几块钱的 MCU 上。对比以太网动辄就要交换机、PHY 芯片、协议栈内存开销CAN 在成本敏感、节点分散的场景下几乎是无敌的。2.3 为什么工业现场也在用 CAN除了汽车工业自动化里 CAN 出现的频率非常高。比如一条生产线上多台变频器要实时接收主控的速度指令同时各自上报电流、故障状态。如果用 RS485主机要轮询每个变频器响应慢而且 RS485 没有内建错误检测现场变频器的强电干扰能把数据打得稀烂。用 CAN主控只需周期性广播速度指令每个驱动器都能同时收到每个驱动器也可以主动上传故障报警不用等轮询。CAN 的物理层本质是差分信号对共模干扰有很强的抑制能力。而且它的总线仲裁机制保证高优先级消息延迟可控——工程上 CAN 的实时性是可计算的这在运动控制、安全联锁这些场景是刚需。3. 协议核心机制拆解帧结构、仲裁与错误处理3.1 CAN 的分层结构与帧类型CAN 协议按 ISO 11898 定义大致可以拆成两层物理层和数据链路层。数据链路层里又分 LLC逻辑链路控制和 MAC媒体访问控制。MAC 层负责打包、解包、仲裁、错误检测和重发LLC 层负责报文过滤、恢复管理和通知。我们平时用 STM32 的 CAN 外设MCU 内部已经集成了完整的 CAN 协议控制器你只要往发送邮箱里填数据、配置接收过滤器剩下的 MAC 层操作芯片全干了。CAN 的帧有四种类型数据帧、远程帧、错误帧、过载帧。日常用得最多的是数据帧。远程帧在标准框架里用来请求对方发送数据但实际工程里建议直接由数据发送方周期上报别依赖远程帧否则总线在总线空闲时才响应实时性不好控制也容易踩到节点不支持远程帧的坑。数据帧标准格式里一场标准的 11 位 ID 帧最多携带 8 字节用户数据。8 字节这个设计当年是拍脑袋定的但考虑过报文越短总线被占用时间越短实时性越高错误重传的成本也越低。CAN FD 把数据场扩展到最多 64 字节但老节点不兼容混合组网要小心。3.2 帧格式里的每个字段都是干嘛的一帧标准数据帧的组成如下SOF1 个显性位逻辑 0标志帧开始同时用于总线同步。仲裁场标准帧是 11 位 ID 1 位 RTR扩展帧是 29 位 ID 1 位 SRR 1 位 IDE 1 位 RTR。控制场IDE、DLC4 位表示数据长度 0-8。数据场要发送的用户数据。CRC 场15 位 CRC 校验值 1 位 CRC 分隔符。覆盖范围是 SOF、仲裁场、控制场、数据场。ACK 场ACK 槽 ACK 分隔符。发送节点发出一个隐性位任何正确接收到这帧的节点都会在这个位置拉一个显性位作为应答发送节点如果没读到显性应答就认为这帧没人收到触发重传。EOF7 个隐性位标志帧结束。这个 ACK 机制非常妙它保证了“接收方确认”不是靠软件层握手而是协议层强制行为。这也意味着哪怕总线上只有一个节点在收也要设置好滤波器让它能产生应答否则发送节点永远发不成功、一直报错。3.3 仲裁机制为什么 ID 数字小的优先上总线CAN 总线的仲裁是它最区别于其他总线的地方。我用一个最直接的方式讲总线上的电平有两种显性Dominant逻辑 0和隐性Recessive逻辑 1。当多个节点同时发送时任何一个节点发出显性位总线电平就是显性的。也就是说显性位会“覆盖”隐性位这和 I2C 的线与逻辑类似。仲裁发生在仲裁场。每个节点一边发送自己的 ID 位一边监听总线。如果自己发送的是隐性位1但读到总线是显性位0说明有更高优先级的节点在同时发送自己立刻转入接收状态退出竞争。发完 ID 没被怼下来的那个节点赢下总线继续发送。这就像一群人走在独木桥上约定“谁的数字小谁先过”。两个人都迈出第一步A 发出 0 占住桥B 刚发出 1 就被 A 的 0 顶回去了B 自动后退等下一轮。整个过程完全分布式不需要中央仲裁器也不浪费带宽。所以 CAN 里 ID 越小优先级越高工程上一类安全消息也应该分配较小的 ID。3.4 位填充、CRC 和五重错误检测位填充规则发送节点在连续发出 5 个相同电平后自动插入一个相反电平的位。接收端再把这一个填充位去掉。作用是保证总线有足够的跳变沿供各个节点的时钟做同步防止长时间电平不变导致锁相环失锁。这也是为什么 CAN 波特率误差超过一定范围后通信直接崩溃——它的时间基准就靠这些跳变沿不断纠正。错误检测五重防护错误类型检测点说明位错误发送节点发送时监听到的总线电平与自己发送的不一致填充错误接收节点违反 5 位填充规则CRC 错误接收节点CRC 校验不一致格式错误接收节点检测到固定隐性位被拉成显性应答错误发送节点ACK 槽读不到显性电平任何节点发现错误会立刻发送 6 个显性位组成的错误帧把当前总线上的错误帧破坏掉让所有节点都放弃当前帧然后发送节点自动重发。如果一个节点错误率太高协议会让它进入 Passive被动状态只能听不能说再严重就 Bus-off总线关闭彻底隔离防止一颗老鼠屎搅坏一锅粥。STM32 外设里都有错误计数器和状态寄存器调试时看这两个计数非常管用。3.5 位时间与采样点为什么能把 1Mbps 跑稳CAN 的一个位时间被划分成四段同步段SYNC_SEG固定 1 个 TQ、传播段PTS、相位缓冲段 1PS1、相位缓冲段 2PS2。采样点发生在 PS1 结束的位置。波特率 外设时钟 / 预分频系数 / 1 PTS PS1 PS2。采样点位置非常关键。位时间太靠前位末端的信号不稳定太靠后下一个位边沿可能已经到来。行业惯例采样点设在 75%-85% 之间。我个人的习惯500kbps 及以下选 80% 左右1Mbps 选 83%-85%低速长距离网络可以适当提前到 75%。各大总线的采样点标准也不统一如果你要把设备接进别人的总线网段最好先问清楚对方采样点是多少否则哪怕波特率名义上一模一样报文也会一帧一帧地错。4. 物理层实战双绞线、终端电阻、收发器与总线供电4.1 差分信号和电平逻辑CAN 物理层跑的是差分信号CAN_H 和 CAN_L 两根线。隐性时CAN_H 和 CAN_L 都约为 2.5V差分电压接近 0显性时CAN_H 被拉高到约 3.5VCAN_L 被拉到约 1.5V差分电压约 2V。差分的好处是外部干扰往往同时作用在两根线上形成共模干扰差分接收端看的是两者之差共模被抵消。这也是 CAN 能在电噪声大的场合正常工作的物理基础。注意CAN 的逻辑 0 是显性、逻辑 1 是隐性刚好和很多人的直觉相反。写代码时别忘了ID 帧里 0 优先业内在分配 ID 时通常用 0 表示紧急/重要信息。4.2 终端电阻必须加不是可选项CAN 总线两端各需要一个 120Ω 终端电阻。为什么正好是 120Ω因为常用双绞线特征阻抗就是 120Ω终端匹配阻抗是为了消除信号反射。没有终端电阻时信号到了总线末端会反射回来和原信号叠加波形出现台阶、振铃轻则边缘变缓导致采样错误重则直接通信失败。很多人测试时只在电脑端用 USB-CAN 分析仪接一个节点分析仪里面自带 120Ω所以偶尔能通一旦接了第二个、第三个真实节点波形就开始乱。这就是终端电阻缺失的典型症状。正确的工程接法总线物理拓扑呈一条直线或尽量接近直线两个物理端点各并联一个 120Ω 电阻。不要接成星型、环形拓扑。CAN 协议本身没有限制拓扑但实际信号在星型中心反射严重长度稍长就出问题。实在受布线限制可以考虑用集线器/网桥设备做星型汇聚而不是直接硬并。4.3 收发器怎么选、节点数怎么算STM32 内部的 CAN 协议控制器输出的是 TX/RX 数字信号要靠外部收发器芯片转成差分信号。经典收发器型号满地都是常见的有 TJA1050、MCP2551、SN65HVD230 等它们基本兼容但注意有些收发器不带保护功能工业现场最好选带热关断和共模耐压高的。节点数上限取决于收发器驱动能力和总线负载。标准做法按每个节点等效电容和差分输入阻抗算。以 TJA1050 为例理论上最多可带约 110 个节点考虑总线阻抗下降但实际工程建议保守些常规节点用 60-80 个以内比较稳妥。另一个限制是总线长度和速率波特率最大总线长度实际工程参考1 Mbps约 40m500 kbps约 100m保守建议 60m250 kbps约 200m125 kbps约 500m50 kbps约 1000m如果想跑远距离高速率要么用 CAN FD 提高速率要么用中继器分段要么通过网桥级联。别指望一路硬拉到极限长度。4.4 隔离工业现场最容易忽略的坑多节点 CAN 网络最阴间的坑是共模电压。汽车里 12V/24V 系统电机启动瞬间电源波动巨大工业现场不同节点可能接在不同的电源地地之间电位差甚至能到几十伏。CAN 收发器的共模输入范围一般只有正负几十伏超限直接烧收发器。解决办法是隔离MCU 侧的 CAN 控制器和总线侧的收发器之间加数字隔离器或者用自带隔离的收发器模块两侧电源完全隔开。隔离之后共模电压被隔离层挡住两个网段的“地”各管各怎么波动都不怕。我从入行到现在因为没隔离烧掉的收发器不下十片教训深刻。高压设备旁边布线的项目隔离不是选项是命门。另外总线供电问题也要提前考虑。现场设备经常只有两根 CAN 线没有额外电源线。一种做法是在 CAN 线旁边单拉一对电源线给节点供电另一种是“总线载电”在协议里预留电源引脚通过总线给低功耗节点供电。但后者需要所有节点都支持同一供电方案设计时要同步规划。5. STM32 上的 CAN 硬件bxCAN 与 FDCAN 的差别以及滤波器到底在干啥5.1 经典 CANbxCAN和 CAN FDFDCANSTM32 不同系列的 CAN 外设分为两类。老一点的 F1/F4 用的是 bxCAN只支持经典 CAN 11 位/29 位 ID速率最高 1Mbps数据场最多 8 字节。再新的 G4/H7 系列升级成了 FDCAN支持 CAN FD 协议数据场最长 64 字节数据段速率最高可达 5Mbps 甚至更高FDCAN 内部还增加了 Tx Event FIFO、灵活滤波器、支持 TTCAN 时间触发等功能。设计新项目时如果可选我建议直接选带 FDCAN 的型号。哪怕初期只跑经典 CAN 帧FDCAN 在滤波器数量、邮箱深度、诊断能力上也比旧 bxCAN 舒服很多。而且它兼容经典帧不存在“用了 FDCAN 就不能和普通 CAN 设备通信”的问题。外设类型支持帧格式数据场最高速率滤波器资源bxCAN经典 CAN 2.0A/B最多 8 字节1 Mbps28 个F1 / 14 个F4FDCAN经典 CAN FD最多 64 字节数据段 5Mbps每个 FDCAN 实例 128 个过滤器5.2 bxCAN 的内部结构和发送邮箱机制拿最常用 STM32F1 的 bxCAN 举例它有 3 个发送邮箱TX Mailboxes、2 个接收 FIFORX FIFO0/1、28 个滤波器。发送时你选择一个空闲邮箱填入 ID、DLC、数据请求发送如果当前总线空闲外设会自动完成仲裁、重发。多个邮箱同时挂起时外设按“邮箱号从小到大”的顺序发送但你一般感知不到这种差异。接收侧每收到一帧外设先拿滤波器组筛选命中放入 RX FIFO。FIFO 满了之后新来的帧会被丢弃并产生溢出错误。所以工程上收数据的策略是要么开中断及时搬走要么用 DMA如果外设支持。滤波器是 bxCAN 里比较绕的部分。它的基本模式有两种掩码模式一个 ID 掩码指定“哪些位必须精确匹配”。比如掩码是 0x7FF表示 11 位全部校验那只有完全相同的 ID 能进来。列表模式每个滤波器只匹配一个精确 ID。举例你只想接收 ID 为 0x321 和 0x322 的两帧用两个滤波器各自配成列表模式命中这两个 ID。如果你想把 0x310 到 0x31F 这一整个区间都接收可以用掩码 0x7F0 ID 0x310只校验高 7 位所有低 4 位任意的帧都会通过。实际工程中我建议接收过滤器宁大勿小可以先全放行在中断回调里用软件判断避免漏帧。等协议稳定了再把过滤器收紧减少中断频率。5.3 FDCAN 的增强更宽的滤波和更深的缓冲FDCAN 比 bxCAN 多了标准过滤器和扩展过滤器的双套资源支持“范围过滤”直接指定 ID 区间FIFO 也从两个队列扩展成最多 64 个 FIFO 元素。对于帧频高、ID 多的项目比如你同时收 30 个不同 ID 的周期报文bxCAN 的 28 个滤波器省着点也够用但 FDCAN 能给你接近无限的配置裕量。FDCAN 还支持 “Tx Event FIFO”——记录每帧实际发送的时间戳。这在做总线调度、延迟分析时特别有用你不需要让 CPU 在发送瞬间去读取定时器硬件自己把时间戳记好了。对多数入门项目经典 CAN 够用但如果你要做一个多节点、高频率、大数据量的系统上 FDCAN 是正路代码还基本兼容。6. 从头跑通STM32CubeMX 配置 收发代码 波特率计算实例6.1 时钟与波特率计算先拿出计算器STM32 的 CAN 波特率完全由 APB1 外设时钟、预分频器、以及位时间的三段时间决定。公式是波特率 F_APB1 / (Prescaler × (1 BS1 BS2))以 STM32F103 为例APB1 典型配置为 36MHz。假如我们要 500kbps常用配置是 Prescaler4BS19BS26那么36MHz / (4 × 16) 0.5625MHz不对。我们倒过来算36MHz / 500kHz 72需要 72 个总TQ。取 Prescaler4则位时间需要 18 个 TQ通常 BS113BS24同步段 1总共 18。这时采样点 1 13/ 18 ≈ 77.8%在合理范围。再举个例子如果你用 STM32G4 的 FDCAN内核时钟是 80MHz想要 500kbps80MHz / 500kHz 160 个TQ。这个数太大了物理层位时间一般不超过 25 个 TQ所以加大预分频Prescaler8位时间20 个TQBS115BS24采样点 80%。这样也是标准值。技巧先选好目标波特率再用“总TQ 时钟/波特率”反推拆解优先把位时间控制在 16-20 TQ 之间采样点落在 75%-85%这是多年的工程经验值。6.2 CubeMX 图形化配置步骤在 CubeMX 里把 CAN1 外设使能之后几个关键参数Prescaler预分频按上面计算填入。Time Quanta in Bit Segment 1 / Bit Segment 2对应 BS1/BS2。波特率会自动显示在下方核对即可。使能中断如果是经典 CAN选 RX0 中断或 RX1FDCAN 则使能 Message RAM 中断里的 RX FIFO 0 New Message。接着配置 GPIOCAN_RX、CAN_TX 自动映射模式选 AF_PP 即可。外设时钟注意 APB1FDCAN 和 bxCAN 时钟源不同G4/H7 里还能选 PLL 独立时钟建议单独给 CAN 一路时钟别和 APB1 挤来挤去。发送函数用 HAL 库是CAN_TxHeaderTypeDef TxHeader; uint8_t TxData[8]; TxHeader.DLC 8; TxHeader.IDE CAN_ID_STD; TxHeader.RTR CAN_RTR_DATA; TxHeader.StdId 0x321; TxData[0] 0x01; TxData[1] 0x02; // ... 填充数据 if (HAL_CAN_AddTxMessage(hcan1, TxHeader, TxData, pTxMailbox) ! HAL_OK) { // 发送邮箱全忙需要处理过载 }注意 HAL_CAN_AddTxMessage 只是把帧挂到邮箱里不是真的立即发完。所以它的返回值只表示“挂载是否成功”不代表总线已经发出去了。要确认真正发送完成可以开发送邮箱空中断或者轮询 HAL_CAN_GetTxMailboxesFreeLevel。6.3 接收中断回调别再漏帧了接收侧我推荐用中断方式。CubeMX 里使能 RX0 中断然后 HAL 库里注册回调void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef RxHeader; uint8_t RxData[8]; if (HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, RxHeader, RxData) ! HAL_OK) { return; } if (RxHeader.StdId 0x180) { speed (RxData[0] 8) | RxData[1]; // 按实际协议解析 } }有个细节HAL_CAN_GetRxMessage 一旦读取了 FIFO硬件 FIFO 立即释放。如果你在回调里耗时过长比如去打印、做算法下一帧来了而 FIFO 已被占满就会溢出丢帧。所以回调里尽快把数据拷到自己的全局变量或者环形缓冲区复杂的解析放到主循环里做。如果你用 FDCANAPI 会略有差异例如 HAL_FDCAN_GetRxMessage但编程思路一致。报文多的时候还可以用 FIFO 中断 逐帧拷贝实测很稳。6.4 一个最小可运行的发送接收轮询例程新手最容易卡壳的其实是几个外设初始化顺序CAN 必须调用 HAL_CAN_Start 启动滤波器也必须配置并激活否则即使状态寄存器显示“已初始化”数据也进不来。void CAN_Init(void) { // CubeMX 已生成 MX_CAN1_Init() MX_CAN1_Init(); // Step1: 配置滤波器这里是全部放行只做演示 CAN_FilterTypeDef filter; filter.FilterBank 0; filter.FilterMode CAN_FILTERMODE_IDMASK; filter.FilterScale CAN_FILTERSCALE_32BIT; filter.FilterIdHigh 0x0000; filter.FilterIdLow 0x0000; filter.FilterMaskIdHigh 0x0000; filter.FilterMaskIdLow 0x0000; filter.FilterFIFOAssignment CAN_FILTER_FIFO0; filter.FilterActivation ENABLE; HAL_CAN_ConfigFilter(hcan1, filter); // Step2: 启动 HAL_CAN_Start(hcan1); // Step3: 使能中断必须先启动再激活中断顺序反了会出怪问题 HAL_CAN_ActivateNotification(hcan1, CAN_IT_RX_FIFO0_MSG_PENDING); }顺序是初始化 - 滤波器 - 启动 - 激活中断。很多人在网上问“为什么我的 CAN 收不到数据”排查下来十有八九是启动之后没配滤波器、或者忘了 ActivateNotification。7. 常见问题排查与调试心得报文错乱、漏帧、总线关闭怎么办7.1 无终端电阻导致通信不稳定表现偶尔能收到一帧然后又断开用示波器看波形成台阶状或过冲。多数情况是终端电阻缺失。解决总线两端各并一个 120Ω 电阻严格等长双绞。注意别把 120Ω 并联在 CAN_H/CAN_L 线中间反复焊终端电阻的“位置”比“阻值精确”更关键。7.2 波特率误差累积导致大量错误帧表现通信速度慢、发送节点反复重发、错误计数蹭蹭涨。先确认两端波特率标称一致再看采样点。总线时钟不同比如一个节点 36MHz另一个 40MHz同样标称 500kbps实际误差可能已经超出协议容限。CAN 规范要求振荡器容差在 ±0.5% 以内才算稳妥所以批量产设备建议用精度高的晶振别贪便宜用内部 RC 做 CAN 时钟。7.3 总线上共模干扰大、收发器发热表现设备能跑但偶发错误摸收发器烫手。多半是两个网段地电位差太大。解决方案加隔离或者至少用带内部隔离的收发器模块。别指望双绞线“抗干扰”能扛住共模电压那是两码事。7.4 CAN_H/CAN_L 接反表现完全不通或者错误帧刷屏。用万用表量总线静态电压正常应该在 CAN_H 约 2.5VCAN_L 约 2.5V双方不对齐基本就是接反。接反时示波器看两线差分电压方向反了一眼就能识别。7.5 滤波器配置错误导致收不到特定 ID表现其他帧能收关键 ID 收不到。检查滤波器掩码和 ID 是否匹配。如果滤波器全部放行能收到但一收紧就收不到多半是掩码位算反了。用列表模式逐个测试最省心。7.6 总线进入 Bus-off 后恢复困难STM32 的 bxCAN 在总线关闭后默认进入 Bus-off 恢复流程需要检测到 128 次 11 个连续隐性位才会回到主动状态。如果外界干扰持续存在它会频繁在 Bus-off 状态反复横跳应用层完全感知不到。处理办法上位机读取错误状态寄存器发现 Bus-off 主动做一次软复位重新初始化同时累计错误计数计数超标就报警。常见问题速查表现象大概率原因快速排查动作完全不通接反 / 无终端电阻 / 波特率不符万用表量静态电平示波器看波形偶发错误帧采样点不对 / 干扰调整 BS1/BS2加隔离发送重发严重ACK 没收到 / 无接收节点确认总线上有节点在收并回应收不到数据滤波器 / FIFO 溢出 / 中断没开先全通测试再查回调收发器发烫共模电压过高 / 短路查两地电位差检查线缆绝缘调试工具方面一个 USB-CAN 分析仪是必备的便宜的就行。把分析仪挂上总线重点看错误帧计数和 Arbitration Lost 计数。这两个数字能告诉你总线基本健康状况。再看哪些 ID 频繁发送对照协议表就知道哪个节点行为异常。8. 实测下来的一些实话和建议读到这里你已经把 CAN 从协议层到 STM32 的应用层走了一遍。我给最后几点个人经验第一别一上来就仿真。真正把两个 STM32 板子用双绞线连起来加上终端电阻用分析仪看真实波形你对差分信号、终端匹配、干扰这些概念的体会比读十篇文档都深。仿真只能验证寄存器的时序验证不了物理世界的玄学问题。第二调试时先看错误计数别看业务逻辑。总线上报文的正确性是所有业务逻辑的前提。错误计数为 0才说明物理层和链路层是健康的。否则你追了半天业务 Bug其实是物理层在疯狂丢帧。第三CAN 协议本身不带身份安全机制任何节点都能收全网数据也能伪造任意 ID。如果你做的是安全相关系统需要在应用层自己做鉴权和白名单过滤别指望总线协议。最后多节点系统里ID 分配和报文规划要先于代码动手。把 ID 列表、周期、长度、优先级提前写进文档后面所有节点照着规范填表就行。CAN 这种总线协议设计好了代码反而简单。别被一堆细节吓住CAN 最迷人的地方恰恰是它那些“看起来很麻烦”的机制仲裁、填充、错误重发。正是这些设计让它在嘈杂的工业现场还能几十年稳定跑下去。你亲手跑通一帧数据、看着报文在分析仪上按预期流动的时候就会理解为什么它至今不过时。
阅读完成 · 觉得有帮助？
