做嵌入式这几年我发现自己绕来绕去总躲不开两个总线一个是UART另一个就是CAN。UART是入门时天天用的调试通道而CAN才是真正把设备“联网”用的现场总线。尤其是做车载、储能、工业控制、机器人这一类项目时MCU之间、MCU和传感器之间如果还要稳定可靠地交换数据CAN总线几乎是绕不开的选项。CAN的好处说白了就四个字稳定、耐造。一条双绞线就能挂几十个节点抗干扰能力强通信距离能到几十米甚至上千米还自带错误检测和重发机制。这篇就把CAN总线从底层协议到STM32实战的关键点一次聊透争取让你看完直接上手调通自己的板子。1. CAN总线到底是什么从“一条线上挂几十个设备”说起1.1 为什么现场通信非得用CAN先想象一个场景一辆车里有发动机ECU、刹车系统、车身控制器、仪表盘、空调、车窗少说十几个控制单元。如果每个单元之间都用独立的信号线互联一束线束比手腕还粗不光成本暴涨故障排查也是噩梦。CAN总线解决的就是这个问题——所有节点接在同一对差分线上用广播的方式通信节点之间不需要点对点连线。早期很多新手会问UART不是也能多点通信吗加个地址就能组网。理论上是但UART物理层是单端信号抗干扰差而且它必须靠协议层自己处理“两个节点同时发数据”的冲突。CAN不一样它的物理层用差分信号协议层自带仲裁和错误恢复这些都是硬件实现的MCU只需要把帧丢给外设剩下的全是CAN控制器的事。从应用角度看CAN总线适合三类场景一是距离长、干扰大的工业现场二是节点多、实时性要求高的车载和机器人系统三是需要简单可靠广播通信的电池管理系统、传感器网络。它的典型指标是通信速率最高1Mbps节点数可以达到110个左右使用双绞线时总线长度和速率直接相关——速率越低能拉的距离越长。这些特点决定了它“现场总线”这个定位。1.2 物理层差分信号和那两只120欧电阻CAN的物理层和I2C、UART完全不是一个路数。它不是用单根线对地电平表示0和1而是用CAN_H和CAN_L两根线上的电压差来表示。标准高速CAN的电气定义是这样的信号状态CAN_HCAN_L差分电压显性位对应逻辑0约3.5V约1.5V约2V隐性位对应逻辑1约2.5V约2.5V约0V这种差分设计对共模干扰有天然的抑制能力。工厂里的电机启动、变频器运行这类强干扰源会在地线上产生很大的共模噪声单端信号很容易被拉飞差分信号却能把干扰看成“两根线上同时抬高的成分”相减之后噪声就抵消了这是CAN能在工业现场存活的核心原因。终端电阻是另一个必须理解的东西。CAN总线要求在物理线路的两端各接一个120欧电阻并联之后总线特性阻抗是60欧。这个电阻的作用是消除高速信号在电缆末端产生的反射。很多新手第一次搭CAN网络忘了接终端电阻结果就是波形振铃严重、错帧率很高、偶尔又正常让人非常头大。后面我有一节专门讲怎么用示波器验证这个事。需要区分清楚的是STM32内部集成的叫CAN控制器它处理协议层的事情输出的是单端的TX/RX信号还不能直接挂到总线上。MCU引脚外面必须串一颗CAN收发器芯片比如TJA1050这类5V供电的经典型号把控制器的单端信号转换成总线上的差分信号。如果你用的是某些带SPI接口的独立CAN控制器模块那是给没有CAN外设的MCU用的STM32用户直接用片上的bxCAN外设就够了。2. 数据链路层帧结构、仲裁和错误处理2.1 一个标准帧的每个字段都在干嘛CAN 2.0B规定了两类帧格式标准帧用11位ID扩展帧用29位ID。日常工程里标准帧占绝大多数。一个标准数据帧从头到尾长这样| SOF 1bit | ID 11bit | RTR 1bit | IDE 1bit | DLC 4bit | Data 0~8byte | CRC 15bit | ACK 2bit | EOF 7bit | IFS 3bit |SOF是起始帧单个显性位表示总线开始进入一帧传输。ID是帧的标识符它同时承担两个任务过滤接收和决定优先级这个后面细说。RTR位表示这是一帧数据帧还是远程帧——数据帧就是带数据正常通信的远程帧是请求别人发数据的工程中用得少能识别就行。IDE位区分标准帧和扩展帧。DLC表示后面数据场有多少个字节最多8个字节这个8字节限制对新手来说可能觉得很小但它保证了一帧的传输时间上限是CAN实时性的重要来源。CRC是15位校验覆盖从SOF到数据场结束的所有位接收方靠它判断这一帧有没有被干扰。ACK位是接收节点“举手”的地方发送节点在这个位发隐性电平任何正确接收的节点如果发现帧没错就会在这拉一个显性位作为回应发送节点就知道“有人收到了”。EOF和IFS是帧结束和帧间隔。需要注意CAN的数据帧最长为8字节数据加上各种开销一帧最多也就一百多个位按1Mbps算只需要约0.13ms这在毫秒级的控制周期里完全够用。我刚做CAN时总觉得8字节太少后来发现车载报文里大量的单帧数据就是几个字节按需拆分就好了。2.2 仲裁广播总线怎么保证不打架总线上多个节点同时发送时CAN用一套叫“非破坏性仲裁”的机制解决冲突。核心在于当一个节点发送隐性位1时如果它在总线上读到显性位0说明有别的节点正在发优先级更高的帧那它立刻停止发送转入接收状态让高优先级帧继续传播。这就是ID数字大小的意义所在ID值越小优先级越高。比如ID0x001的帧和ID0x100的帧同时抢总线在第一位出现差异时0x001的帧先发了0另一方发的是1就被“顶”下去了。整个过程是全硬件完成的没有任何一个节点会被数据破坏高优先级帧一条线从头到尾完好发送所以叫“非破坏性”。这个设计的工程后果很直观调度不需要主机分配时隙每个节点抢到总线就算赢抢不到就等下一轮。对于实时性要求高的报文比如电机转速、刹车状态把ID设小一点就行了。坏处同样明显——极端情况下低优先级帧可能一直被高优先级帧压制也就是“饿死”。所以实际项目里分配ID表要花心思周期性报文和事件性报文要错开优先级实时性敏感的帧优先级高的同时低频高优先级帧不要太多避免堵塞总线。2.3 错误检测与三态错误管理CAN是少数把错误检测做到协议底层的总线。它一共定义了五种错误位错误发送时发现总线电平和自己发的不一致、填充错误违反了“连续5个相同位后必须插一个反向位”的规则、CRC错误、形式错误固定格式段不是规定电平和ACK错误发送节点没收到应答。只要任何节点发现这些错误就会立刻发出一串显性错误帧把这一轮通信“废掉”所有节点丢弃当前帧等待下一条继续。更精巧的是节点状态管理。每个CAN控制器内部维护两个错误计数器发送错误计数TEC和接收错误计数REC。正确收发会把计数减下去出错会按规则加进去。根据计数器的值节点有三种状态状态条件行为表现错误主动TEC128 且 REC128正常通信出错时发主动错误帧错误被动TEC或REC超过127只能发被动错误帧权限降低总线关闭TEC超过255节点完全退出总线不再收发这三级状态是CAN“匿名性”的一种体现——频繁出错的节点不会拖垮全网最坏情况是它自己离网。写STM32的时候HAL库里有AutoBusOff选项开启后硬件检测到总线关闭会自动重新恢复不开启就得软件手动恢复这个后面代码里会说。3. STM32的bxCAN外设与配置要点3.1 邮箱、FIFO和滤波器这些外设术语STM32的bxCAN外设和其他CAN控制器比有几个特色设计要搞清楚。首先是发送邮箱F103的CAN1有3个发送邮箱你可以把等待发送的帧分别丢进三个邮箱硬件会按优先级顺序发送。需要注意的是如果三个邮箱都是满的你需要等待任意一个发送完成再丢下一帧否则会报错。实际编码时我会用一个循环判断“空闲邮箱数量”保证不会把帧丢给一个正在发送的邮箱。接收侧是两条FIFOFIFO0和FIFO1每条可以存3个完整帧。为什么搞两条为了配合滤波器做分流。你可以配置一部分滤波器把优先级高的帧放进FIFO0把调试或者低优先级的帧丢进FIFO1这样中断处理的时候能快速区分。对新手来说先固定用FIFO0就够了。滤波器是bxCAN最好用也最容易踩坑的外设。它有14个滤波器组CAN1上每个滤波器组可以配置成“屏蔽位模式”或“列表模式”。屏蔽位模式的意思是提供一组ID和一组掩码掩码为1的位必须严格匹配ID掩码为0的位不关心。列表模式则要求接收的ID必须和预设ID列表完全一致。一句话总结屏蔽位模式适合按“ID范围”接收列表模式适合按“精确ID列表”接收。3.2 位时序与波特率计算采样点是关键CAN虽然有两根线但没有时钟线接收端是靠波特率位时序从数据流里“抠”出位边界的。一个位时间被拆成四段同步段SS、传播段相位缓冲段1合起来叫BS1、相位缓冲段2BS2和重同步跳转宽度SJW。STM32的HAL库让你直接配置BS1和BS2各占几个TQTQ是“最小时间单位”由CAN时钟经预分频器得到。波特率的完整公式是CAN时钟频率 APB1外设时钟 / Prescaler 波特率 CAN时钟频率 / (SS BS1 BS2)其中SS固定为1个TQ。以最常见的F103系统时钟72MHz、APB1时钟36MHz为例如果我想得到250Kbps的波特率先选一个位时间长度比如16TQ那么CAN时钟频率必须是250K * 16 4MHz预分频器就是36M / 4M 9。然后分配这段位时间SS占1TQBS2通常给2到3TQ剩下都给BS1。采样点位置就是(SS BS1) / (SS BS1 BS2)工程经验推荐落在75%到80%之间。取BS112TQ、BS23TQ采样点就是(112)/16 81.25%很合适。我给的参考配置表如下按APB136MHz计算目标波特率预分频器BS1BS2位时间采样点1Mbps38TQ3TQ12TQ75%500Kbps68TQ3TQ12TQ75%250Kbps912TQ3TQ16TQ81.25%125Kbps1812TQ3TQ16TQ81.25%这里面有个常被忽略的点APB1时钟不一定都是36MHz。有的人把系统时钟超频到128MHzAPB1相应变成64MHz还用原来的预分频器波特率就全偏了。我每次调试CAN第一件事就是回去确认SystemClock_Config里面的APB1分频系数别让这种低级错误浪费一下午。3.3 滤波器配置为什么你收不到别人发的帧滤波器是新手最容易翻车的地方。很多人初始化了CAN、开了中断、也接好了线结果就是收不到数据最后发现是滤波器把所有帧都挡掉了。滤波器的作用就是在硬件层面先做一次“ID预筛”不匹配的帧直接丢弃不进接收FIFO也不触发中断。看一个实际例子。假设我只想接收ID0x123这个帧其他全不要CAN_FilterTypeDef sFilterConfig; sFilterConfig.FilterBank 0; sFilterConfig.FilterMode CAN_FILTERMODE_IDMASK; sFilterConfig.FilterScale CAN_FILTERSCALE_32BIT; sFilterConfig.FilterIdHigh 0x123 5; sFilterConfig.FilterIdLow 0x0000; sFilterConfig.FilterMaskIdHigh 0x7FF 5; sFilterConfig.FilterMaskIdLow 0x0000; sFilterConfig.FilterFIFOAssignment CAN_RX_FIFO0; sFilterConfig.FilterActivation ENABLE; if (HAL_CAN_ConfigFilter(hcan1, sFilterConfig) ! HAL_OK) { Error_Handler(); }我见过很多工程师一上来就全是0掩码结果所有帧都进不来就是因为把掩码的含义理解反了——掩码位是“不关心”不是“必须匹配”。全0掩码意味着任何ID都满足条件如果你只想收某个ID掩码位就该是1。这里再补一句MaskIdHigh左移5位的原因在于标准帧的ID在32位寄存器里不是靠边放的高位对齐后中间还有RTR、IDE这些位要空出来。直接看寄存器位定义会头晕用库函数的时候记住“标准帧ID区域是bit15到bit5”所以左移5位。4. 手写全套代码回环测试到双机通信4.1 回环测试单板自验证CAN外设拿到一个新的板子第一件事不应该急着接外部设备而是让CAN自己给自己发信。STM32的bxCAN支持回环模式Loopback在这个模式下发送邮箱发出的帧会自动进入接收FIFO不需要外部任何接线就可以验证MCU的CAN外设、GPIO复用配置、中断系统是不是正常。这一步通过才能放心去接外部总线。初始化代码里只改一行模式就行hcan1.Init.Mode CAN_MODE_LOOPBACK;其余照常初始化、配置滤波器、使能接收中断。主循环里发一帧数据如果中断回调里打印出了这一帧说明CAN外设的收发链路是通的。回环模式里没有物理层参与所以即使你波特率配置完全错了回环测试也可能通过因为TX直接回RX不涉及时间同步。这就是为什么回环测试不等于整条链路测试它只验证了MCU内部外部接线和收发器还得靠双机测试来验证。配置完模式以后整体初始化流程是这样的__HAL_RCC_CAN1_CLK_ENABLE(); hcan1.Instance CAN1; hcan1.Init.Prescaler 9; hcan1.Init.Mode CAN_MODE_LOOPBACK; hcan1.Init.SyncJumpWidth CAN_SJW_1TQ; hcan1.Init.TimeSeg1 CAN_BS1_12TQ; hcan1.Init.TimeSeg2 CAN_BS2_3TQ; hcan1.Init.TimeTriggeredMode DISABLE; hcan1.Init.AutoBusOff ENABLE; hcan1.Init.AutoWakeUp DISABLE; hcan1.Init.AutoRetransmission ENABLE; hcan1.Init.ReceiveFifoLocked DISABLE; hcan1.Init.TransmitFifoPriority DISABLE; HAL_CAN_Init(hcan1); // 配置滤波器此处全掩码接收所有标准帧 // ... HAL_CAN_Start(hcan1); HAL_CAN_ActivateNotification(hcan1, CAN_IT_RX_FIFO0_MSG_PENDING);这里有个细节初始化完成后必须调用HAL_CAN_Start启动CAN否则一直处于“未使能”状态发不出去也收不到。很多人写完初始化发现没反应就是漏了这一步。4.2 发送和接收中断与轮询的取舍发送侧我封了一个很小的函数每次调用前检查空闲邮箱。邮箱满了就死等这在实时性要求不高的场景够用如果是在定时器中断里发CAN帧就得改成非阻塞方式邮箱满就跳过本轮发送或者加超时计数。void CAN_SendMessage(uint16_t id, uint8_t *data, uint8_t len) { CAN_TxHeaderTypeDef txHeader; uint32_t mailbox; txHeader.StdId id; txHeader.ExtId 0; txHeader.IDE CAN_ID_STD; txHeader.RTR CAN_RTR_DATA; txHeader.DLC len; while (HAL_CAN_GetTxMailboxesFreeLevel(hcan1) 0) {} if (HAL_CAN_AddTxMessage(hcan1, txHeader, data, mailbox) ! HAL_OK) { // 这里可以加错误统计 } }接收侧我用中断方式。CAN的接收中断只有两种常用的FIFO0挂起中断和FIFO1挂起中断。回调函数名是HAL库固定好的之后每当FIFO0收到一帧硬件就会跳进这个回调void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rxHeader; uint8_t rxData[8]; if (hcan-Instance CAN1) { if (HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, rxHeader, rxData) HAL_OK) { printf([CAN] ID0x%03X DLC%d Data, rxHeader.StdId, rxHeader.DLC); for (int i 0; i rxHeader.DLC; i) { printf(%02X , rxData[i]); } printf(\r\n); } } }回调里做的工作越少越好。CAN一帧数据最多8字节拷贝耗时几乎可以忽略所以直接在这里读取和打印没问题。但如果你要把数据往处理线程里送就应该只拷贝到一个全局缓冲区设置标志位让主循环去消费不要在中断里做重量级解析。4.3 双机通信接线与验证步骤回环测试通过后改成正常模式就可以做真正的双机通信了。接线其实非常简单节点A的CAN_H接节点B的CAN_H节点A的CAN_L接节点B的CAN_L两边GND连一起共地是基础要求带隔离的模块可以不连但不连也不代表万事大吉总线两端各接一个120欧终端电阻如果用市面上的CAN收发器模块很多已经内置了这个电阻直接拨码或短接焊盘就行把这个流程走一遍第一步把两个节点的Init.Mode都改成CAN_MODE_NORMAL波特率配置一致。第二步用A发固定IDB用滤波器只收这个ID打印输出。第三步反过来验证B发、A收。第四步两边互发互收验证双向。最容易翻车的地方是两根线接反。CAN_H和CAN_L接反物理上不一定会烧东西但通信是完全不通的——因为差分电平反了所有显性位会变隐性接收端什么都解析不出来。我踩过一次这个坑排查半天发现是端子排上两根线序看错了。所以双机验证时先用万用表量一下总线两端不通信时CAN_H和CAN_L应该都是2.5V左右通信时示波器上能看到显性位把差分电压拉高到约2V。如果手头没有逻辑分析仪可以做一个土办法让A连续发送同样的帧B收到后用串口打印计数用一段时间的收帧数量估算波特率和链路质量。正常通信应该是稳定增长、不掉线、不报错。一旦看到打印断断续续优先怀疑终端电阻和线缆质量。5. 调试技巧示波器、错误码和波形判断5.1 用逻辑分析仪直接看帧结构调试CAN总线我最推荐的设备是带CAN解码功能的逻辑分析仪配上开源软件PulseView非常好用。注意要测的是收发器芯片输出到总线上的差分信号也就是CAN_H和CAN_L两个探针解码器会算出CAN_H - CAN_L的差分波形。打开解码后你不需要自己手工数位软件会直接把ID、DLC、Data、CRC解出来。这时候比对着报文内容看总线上的原始电平理解会比只看库函数快非常多。比如你可以亲眼看到SOF是一个显性位ID字段是从高位到低位依次出现CRC在后面那15个位长得和前面的数据完全不相关以及ACK槽里总线上那个“被拉低”的小坑——那就是接收节点应答的痕迹。还有一种情况值得看错误帧。故障节点狂发错误帧时波形上能看到连续的显性电平异常延长那是错误帧标志6个显性位叠加了填充规则后的结果。看到这个波形就说明有节点在报错比对着错误码寄存器能更快定位是谁在作妖。5.2 错误码、发送状态寄存器与排查方向大部分情况下我没有示波器在手边那我主要靠HAL库的返回值判断HAL_CAN_AddTxMessage返回HAL_OK只能说明帧进了发送邮箱不代表总线上真的发出去了。要看发送成功还是失败得查发送邮箱状态寄存器里的TXOK位或者看HAL_CAN_GetError返回的错误码。uint32_t err HAL_CAN_GetError(hcan1); if (err ! HAL_CAN_ERROR_NONE) { printf(CAN Error: 0x%08X\r\n, err); }HAL_CAN_ERROR_EWG是唤醒错误HAL_CAN_ERROR_EPV是错误被动HAL_CAN_ERROR_BOF是总线关闭后面还有位错误、填充错误、CRC错误、格式错误、ACK错误等细分。实战中最常遇到的是ACK错误它表示“发送节点没收到任何接收节点的应答”。为什么会没应答第一个可能是总线上根本没别的节点在线第二个可能是对方波特率不匹配解析不了第三个就是对方收了但滤波器把帧滤掉没参与应答注意帧只要被硬件完整接收不管滤波器通不通过都会在ACK槽里给应答所以滤波器通常不影响ACK错误真正影响的是波特率不匹配和物理层不通。判断总线状态的另一个利器是读取CAN外设的错误计数器寄存器比如F103的CAN ESR寄存器里有REC和TEC字段。如果REC持续增长说明总线干扰大或波特率不对如果TEC增长到255触发总线关闭说明你发送一直是错的多半是物理层问题很少是软件问题。6. 高频问题速查表与避坑笔记6.1 六大典型故障与排查方向故障现象可能原因排查/解决建议发不出去TX邮箱一直满总线bus off/线没接/没有应答查ESR寄存器REC、TEC确认总线关闭状态能发不能收滤波器把帧滤掉了、中断没使能先全掩码收所有帧再逐步收紧收发偶尔失败错帧率高缺少终端电阻、线太长、干扰大量贴片电阻示波器看振铃加终端电阻两板波特率相同却不通CAN_H/L接反、收发器供电问题万用表量静态电平确认两根差分线序收到乱码一样的错误帧波特率不一致、采样点太差用逻辑分析仪解码实际波特率校准配置通信一段时间后节点“消失”总线关闭未自动恢复开AutoBusOff或在错误回调里软件复位CAN6.2 布局与电气设计建议硬件层面有几点经验值得分享。第一CAN收发器放在离MCU引脚尽量近的位置中间不要走太长的过孔线串联的匹配电阻或者保护器件要有但别乱加电容太大电容会拖慢边沿。第二共地要可靠特别是多节点跨设备供电的时候地电位不一致会让差分信号产生共模偏移轻则错帧重则收发器发烫。第三总线走线用双绞线CAN_H和CAN_L绞在一起比平行线抗干扰能力强一截。第四终端电阻的位置也有讲究——必须放在物理总线的两端不是每个节点都放。有些人图省事在每个模块里都焊一个120欧结果总线负载变成60欧甚至更低波形照样坏掉。软件层面也有两句运维心得给每个节点分配固定的ID和接收过滤器规则不要动态改ID上电后先等待100ms再开始发数据等总线稳定和各节点初始化完成能少很多启动阶段的错帧。这些不起眼的小习惯在调试多节点系统时能少掉很多头发。我在实际调试CAN时最深的一个体会是CAN的错误处理机制实在太友好了——它不像串口那样收发错位就彻底乱掉它能自己回到正轨。只要你愿意花几分钟看一眼波形和错误寄存器大部分问题都能定位到很具体的原因。建议你拿到板子后第一件事建一个“回环测试工程”存起来以后每次在新板子、新工程里移植CAN都先跑它。包括我之前踩过的CAN_H/L接反、滤波器把帧滤光、AutoBusOff没开导致节点死后不活这些问题如果靠回环测试先排除软件层排查时间能缩短一半以上。希望这组从协议到实践的笔记能帮你把CAN总线用到手真正调通自己板子上的第一帧数据。