说句实话现在很多搞嵌入式的朋友对CAN总线是又爱又怕。爱的是它在车载、工控、机器人这些场景里实在太能扛事了怕的是协议栈一多、接线一乱调起来就容易让人怀疑人生。但其实用STM32F103配合CubeMX和HAL库做双机CAN通信并没有想象中那么玄乎只要把配置逻辑捋顺把过滤器、中断、波特率这几个坎迈过去基本半小时就能把两个板子拉通跑起来。这篇文章我就用手把手的方式带你从头到尾把这条路走一遍顺便把我踩过的坑和排查思路都写在里面照着做就行。先说清楚这篇文章适合谁。你如果是刚接触CAN、准备做点双机交互的小项目或者在学校/公司里被分配了“用F103搞个CAN通信”的活儿那这篇就是给你准备的。如果你已经是老手也可以看后面章节的过滤器配置和负载率计算多少能值回一点时间。文章全程基于STM32F103C8T6最小系统板加TJA1050收发器用CubeMX生成HAL工程代码量不大但每一步我都会讲清楚为什么这么做。1. 方案构思与硬件准备1.1 为什么双机通信偏偏选CAN很多人在做双机通信时第一反应是串口。串口确实简单点对点一根线就能跑但你只要试过以下场景就会明白它为什么不够用两块板子之间距离超过两米或者现场电机一启动串口数据就开始乱码多块板子要组网串口要么加485芯片要么搞一堆跳线再或者你的数据既要实时性又要可靠性串口协议从帧头帧尾到校验位全得自己写。这时候CAN的优势就体现出来了。CAN是差分信号传输CAN_H和CAN_L两根线抗干扰能力天然比单端串口强总线长度在低速下能跑到几百米。它用的是多主结构任何节点都能主动往总线上发数据天生支持多机组网。再加上硬件自带的仲裁机制、错误检测、错误恢复你不需要像串口那样手动处理一堆容错逻辑。当然代价就是需要对CAN协议本身有一定了解。好在STM32F103的bxCAN外设把底层处理得很好HAL库又帮你把寄存器操作封装掉了实际写代码的难度其实跟串口差不了太多。我这次选F103做双机通信并不是因为它性能有多强而是因为这颗芯片在市面上保有量极大、资料极多、价格便宜到让人安心。用它对CAN通信进行学习和验证性价比非常高。1.2 硬件清单与接线注意事项两块STM32F103C8T6最小系统板最常见某宝几十块两块CAN收发器模块芯片是TJA1050或者SN65HVD230都行两个120欧姆终端电阻注意是“两个”后面我会解释若干杜邦线和一根USB转TTL调试线可选逻辑分析仪或示波器用来观察CAN_H/CAN_L波形接线看起来很简单直接把两块板的PA11、PA12分别连到收发器的TXD、RXD然后CAN收发器的CAN_H接CAN_HCAN_L接CAN_L。这里有个常见误区有人第一次接线下意识会把CAN_H和CAN_L交叉接这个习惯是从串口RXD对TXD那里带过来的。CAN总线不需要交叉CAN_H对CAN_H、CAN_L对CAN_L收发器之间是并联关系。终端电阻的接法也需要强调。CAN标准规定总线两端各需要一个120欧姆电阻用来匹配阻抗、消除反射。很多人图省事只在其中一块板上接了一个120欧或者把两个120欧并在同一块板上这两种做法都会导致信号反射近距离短总线可能勉强能用但只要距离稍微拉长或者干扰一来就会出现偶发错误帧。我自己的做法是直接用两个120欧贴片电阻分别焊在两个收发器模块的CAN_H和CAN_L之间正好符合总线两端各一个的要求。还需要强调一点两个板子之间必须共地。CAN是差分信号理论上不共地也能通信但收发器的工作电平参考系不同长期下来容易出现莫名其妙的错误。我习惯在接线时顺手把两块板的GND也连在一起成本只是一根杜邦线但能少掉80%的偶发问题。1.3 双机拓扑到底能用在哪些地方双机通信虽然简单但它是多机CAN网络的基础。你可以把两块板子理解为一个最小验证环境先在这个环境里把收发、过滤器、差错处理跑通之后再往CAN总线上挂第三个、第四个节点本质上只是配置不同的过滤器ID而已。我见过不少项目最开始只要求两个模块通信最后扩展成六个节点都是先从双机起步的。而且双机调试有个好处出问题时排查范围小不是A的问题就是B的问题不用像多机网络那样分析一大堆交互关系。所以你完全可以把这篇文章当成一次总线的“最小系统验证”后面的方向盘、电机控制器、传感器节点都是基于这套底子加出来的。2. CubeMX工程配置与关键参数2.1 新建工程与时钟树配置要点打开CubeMX之后新建工程选芯片型号STM32F103C8T6。很多新手会在这一步卡住因为从ST官网拉取固件包时有时候网络很慢甚至直接失败。这个问题我之前遇到过后来直接把固件包手动下载放进仓库目录或者在CubeMX里切换一下下载源基本就能解决。如果你急着用先确认CubeMX和固件包版本匹配再检查网络环境这个问题通常不在配置思路上。选中芯片之后先别急着碰CAN先把最基础的引脚配置好RCC设为HSE Crystal/Ceramic Resonator使用外部8M晶振SYS里的Debug设为Serial Wire否则后面下载程序时容易报找不到芯片时钟树里把HCLK拉高到72MHz软件会自动把PLL参数算好时钟树是关键。STM32F103的CAN外设挂在APB1总线上而APB1最高只能到36MHz。CubeMX默认会把APB1设为36MHz这个不用改但你要清楚一件事CAN外设的时钟源是PCLK136MHz后面算波特率时这个数值要反复用到。接着在左侧Peripherals里打开CAN1勾选Master。默认引脚PA11RX和PA12TX会自动分配好不需要手动转。很多教程让手动改GPIO其实没必要CAN1的引脚是硬件固定的。做完这些后先不要急着生成代码下一节把波特率参数设置讲清楚再一起生成。2.2 CAN波特率计算从Tq到bps波特率可以说是CAN配置里最核心、也最容易出错的环节。很多人直接在CubeMX里随便填一个Prescaler和BS段数值生成后发现两个板子都收不到数据却找不到原因十有八九就是波特率配置出了问题。先看公式CAN波特率 PCLK1 / Prescaler / (1 BS1 BS2)其中PCLK1 36MHz。这里要特别注意CubeMX界面里的Prescaler、BS1、BS2这几个参数和你在代码里看到的CAN_InitTypeDef结构体成员是对应的。BS1和BS2实际上表示的是“时间段长度”它们决定了每一位数据占几个时间量子Tq。我常用的1Mbps配置参数如下参数数值说明Prescaler336MHz / 3 12MHz Tq时钟BS199个TqBS222个Tq位总长度12个Tq9 2 1个同步段最终波特率12MHz / 12 1Mbps满足要求同步段Sync_Seg固定占1个Tq这个需要自己加进去也是新手最容易漏掉的地方。如果你把BS1和BS2填完之后给出的结果始终不对先想想是不是漏了“1”。如果你需要500kbps也很简单参数数值说明Prescaler636MHz / 6 6MHz Tq时钟BS199个TqBS222个Tq位总长度12个Tq和上面一致最终波特率6MHz / 12 500kbps满足要求网上很多教程给出的SamplingPoint采样点配置五花八门实际上你不必追求极致默认在78%左右就可以稳定工作。采样点 (1 BS1) / (1 BS1 BS2)1Mbps配置下是(19)/12 ≈ 83%这个数值覆盖大多数场景。这里还有一个容易被忽视的坑两个节点的波特率参数不需要完全一致只要最终波特率相同理论上就能通信。但为了调试方便我建议两块板子直接用同一份CubeMX工程生成两次就行省得两边参数不一致导致问题。2.3 串口调试通道的配置CAN通信本身不产生你肉眼可见的东西调试时最好有个打印通道。我一般会顺手打开USART1配置为异步模式波特率1152008N1引脚默认PA9和PA10。这样后面程序里把接收到的CAN帧直接通过串口打印出来看结果一清二楚。用HAL库重定向printf只需要两步在main.c里加上#include stdio.h然后重写fputc函数。我用的是int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; }这样串口和CAN的联合调试通道就算打通了。CubeMX里USART1的NVIC设置记得勾选全局中断虽然printf走的是轮询发送但接收部分如果想从串口下发指令会用到。我这次的主流程是CAN接收后用串口打印所以串口只用发送不配中断也够用但为了后续扩展提前把中断打开没坏处。到这里CubeMX里的配置就算完成了。检查一下Project Manager里的Toolchain设置MDK-ARM还是别的然后点Generate Code生成工程。3. HAL库CAN驱动代码详解3.1 从CubeMX生成到基本初始化生成代码之后打开工程先看main函数里的初始化顺序。MX_CAN1_Init()会读取我们刚才在CubeMX里设置的波特率参数MX_USART1_UART_Init()负责串口初始化。这里不需要手动改初始化代码但有一点要注意CubeMX生成的CAN初始化函数只配置了外设寄存器并没有真正启动CAN总线需要在用户代码区域手动调用HAL_CAN_Start()。具体顺序推荐这样int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_CAN1_Init(); MX_USART1_UART_Init(); CAN_FilterTypeDef canFilterConfig; canFilterConfig.FilterIdHigh 0x0000; canFilterConfig.FilterIdLow 0x0000; canFilterConfig.FilterMaskIdHigh 0x0000; canFilterConfig.FilterMaskIdLow 0x0000; canFilterConfig.FilterFIFOAssignment CAN_RX_FIFO0; canFilterConfig.FilterMode CAN_FILTERMODE_IDMASK; canFilterConfig.FilterScale CAN_FILTERSCALE_32BIT; canFilterConfig.FilterActivation ENABLE; HAL_CAN_ConfigFilter(hcan1, canFilterConfig); HAL_CAN_Start(hcan1); HAL_CAN_ActivateNotification(hcan1, CAN_IT_RX_FIFO0_MSG_PENDING); while (1) { // 发送逻辑 } }先解释一下为什么滤波器设置为全零加全零掩码。CAN的掩码模式规则是掩码位为1时必须匹配掩码位为0则忽略。全零掩码意味着所有ID都能通过也就是“不过滤”对于双机通信的初期验证最省事。等基本功能通了再按ID过滤后面3.3小节会细讲。HAL_CAN_Start()是启动总线的关键调用漏了它CAN外设始终处于初始化状态数据收发完全没反应。这个坑我见得太多了很多新手在while循环里发了半天数据板子上一点反应都没有查来查去发现Start没调用。初始化之后建议紧跟着在CAN GPIO初始化完成后手动拉一下CAN收发器的STB或RS引脚。TJA1050模块大部分是5V供电模块上自带电平转换不需要额外处理但有些低成本模块的RS引脚悬空时会进入静音模式导致只能收不能发。我一般直接用杜邦线把RS接地强制进入正常模式。3.2 发送流程邮箱机制与HAL_CAN_AddTxMessageHAL库发送CAN帧的核心函数是HAL_CAN_AddTxMessage()。别看这个名字带“Add”实际上它就是把一帧数据塞进发送邮箱然后硬件自动发出去。STM32F103的bxCAN有3个发送邮箱你可以把它理解成3个快递柜格口满了就暂时放不进去。CAN_TxHeaderTypeDef txHeader; uint8_t txData[8] {1, 2, 3, 4, 5, 6, 7, 8}; uint32_t txMailbox; txHeader.StdId 0x101; txHeader.ExtId 0; txHeader.IDE CAN_ID_STD; txHeader.RTR CAN_RTR_DATA; txHeader.DLC 8; HAL_CAN_AddTxMessage(hcan1, txHeader, txData, txMailbox);这里重点解释几个结构体成员StdId标准帧ID范围0x000到0x7FF共11位。双机通信时这个ID就是“门牌号”接收方过滤器认的就是它。IDECAN_ID_STD表示标准帧CAN_ID_EXT表示扩展帧。扩展帧ID有29位普通双机通信用不到保持标准帧即可。RTRCAN_RTR_DATA表示数据帧CAN_RTR_REMOTE是远程帧。远程帧一般用于请求发送入门阶段直接用数据帧。DLC数据长度CAN帧最大8字节。这个上限是由协议规定的不能超过8。HAL_CAN_AddTxMessage()的返回值是HAL_StatusTypeDef类型HAL_OK表示入队成功HAL_ERROR或HAL_BUSY需要处理。如果返回BUSY通常是3个邮箱全满要么发送太快要么总线上有节点处于离线状态导致硬件一直重发。这时候最简单的做法是加一个短暂延时或者检查总线状态。如果你仔细观察HAL库内部的发送逻辑会发现它已经帮你处理好了空闲邮箱选择用户不需要关心具体用哪个邮箱。不过有一点值得知道HAL_CAN_AddTxMessage发送完成后需要通过HAL_CAN_GetTxMailboxesFreeLevel()来查看剩余邮箱数量。我在实际项目里会在发送前查询一次邮箱释放情况如果小于1就延时几毫秒再发避免邮箱占满导致丢帧。3.3 接收流程过滤器的原理与中断回调接收部分比发送稍微绕一点主要是绕在过滤器上。很多人在这一步卡住把过滤器设置成“什么都收”然后发现该来的不来或者设置成“只收特定ID”又发现数据进不来。其实理解了过滤器原理这个环节就通了。CAN过滤器的本质是一个ID比对器。每个CAN外设有28个过滤器组F103是14个F105/107是28个每个过滤器组可以选择两种工作模式屏蔽位模式和列表模式。屏蔽位模式就是掩码匹配掩码位为1时必须相等为0则忽略。列表模式就是精确匹配只有ID完全等于设定值时才能通过。最常用的32位屏蔽位模式代码如下CAN_FilterTypeDef sFilterConfig; sFilterConfig.FilterActivation ENABLE; sFilterConfig.FilterMode CAN_FILTERMODE_IDMASK; sFilterConfig.FilterScale CAN_FILTERSCALE_32BIT; sFilterConfig.FilterIdHigh 0x101 5; sFilterConfig.FilterIdLow 0x0000; sFilterConfig.FilterMaskIdHigh 0x7FF 5; sFilterConfig.FilterMaskIdLow 0x0000; sFilterConfig.FilterFIFOAssignment CAN_RX_FIFO0; sFilterConfig.FilterBank 0; HAL_CAN_ConfigFilter(hcan1, sFilterConfig);这里有个非常容易踩的坑FilterIdHigh里不能直接写0x101要左移5位也就是0x101 5。为什么因为标准帧ID是11位在32位过滤器寄存器里它们被放置在bit31~bit21的位置而低5位是扩展帧ID的存放位置标准帧模式下忽略。HAL库没有自动帮你做这个移位需要手动处理。很多新手在这里栽了跟头填了0x101结果数据死活进不来。如果你想同时接收多个ID比如0x101、0x102、0x103可以使用掩码来模糊匹配。掩码位为1的位必须相等为0的位可以不同。比如让高8位匹配、低3位忽略就能同时收3个相邻ID。接收中断的配置同样不能漏。HAL库处理接收有两种思路轮询和中断。轮询就是主循环里不停调用HAL_CAN_GetRxMessage()代码简单但浪费CPU中断方式性能好是工程项目的首选。开启中断用HAL_CAN_ActivateNotification(hcan1, CAN_IT_RX_FIFO0_MSG_PENDING);然后在stm32f1xx_it.c里或直接在HAL库的回调函数里接收数据void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rxHeader; uint8_t rxData[8]; if (hcan hcan1) { HAL_CAN_GetRxMessage(hcan1, CAN_RX_FIFO0, rxHeader, rxData); printf(Rx ID:0x%03X Data:, rxHeader.StdId); for (int i 0; i rxHeader.DLC; i) { printf(%02X , rxData[i]); } printf(\r\n); } }回调函数是HAL库的弱定义函数用户在自己的代码里重写同名函数就行。这里有个细节值得注意HAL_CAN_GetRxMessage()必须在回调函数里调用把FIFO里的数据搬出来否则FIFO一直被占着后续数据无法进入丢帧就是这么来的。接收方式的选型上我明确建议优先用中断。CAN在嵌入式系统里往往承担数据交互的核心角色如果主循环一忙轮询接收必然导致丢帧。中断方式让硬件在FIFO里积压数据满了就回调实时性和CPU占用都更可控。至于DMA方式接收CAN帧技术上CAN硬件是支持DMA请求的但HAL库对CAN的DMA封装目前还比较有限而且1Mbps下数据量并不大中断完全够用。我实际测过在72MHz主频下接收压力非常小没必要为了DMA而DMA。3.4 双机通信协议设计建议硬件和驱动都通了之后协议设计反而是决定通信质量的关键。很多同学用CAN只会一股脑往外发裸数据没有帧结构概念这在双机场景可能问题不大一旦扩展成多机就会乱套。我的习惯是固定帧ID分配规则比如A板固定发0x101B板固定发0x102每个节点发什么ID接收方通过ID判断来源。数据字段也可以做个最简协议第0字节是功能码比如0x01表示控制指令、0x02表示状态查询、0x03表示数据上报第1到6字节是业务数据第7字节放校验常用累加和或者异或和。虽然CAN硬件已经有CRC校验但那是物理层的事应用层加一字节校验能有效防止数据被错误解释。我在实际中习惯用异或和代码简单出错概率能被控制在极低水平。双机通信还有一种常见模式是请求应答A板发一帧“读取指令”给B板B板收到后回一帧“数据回复”。这种模式在调试时特别有用因为你可以非常清楚地观察请求是否到达、回复是否回来。我建议第一次做双机通信的朋友都按这个模式先跑通不要一上来就搞双向轮询发数据那样问题出现时不好定位。4. 完整测试流程与现象验证4.1 接线与上电前的最终检查程序烧进去之前先把硬件接线检查一遍这个环节能省掉后面大量定位时间。我列一个自己每次都要过一遍的清单两块板子都接了CAN收发器模块TXD连接PA12RXD连接PA11两个收发器的CAN_H互连、CAN_L互连两个120欧电阻分别在两个收发器模块上两块板子的GND已连通收发器模块电源正确TJA1050用5V供电RS引脚如果有接地确认不在静音模式检查完这些再上电。上电后先不接CAN线单独给两块板子供电用万用表量一下CAN_H和CAN_L之间电压。正常情况下不通信时CAN_H约2.5VCAN_L约2.5V两者电压差接近0V。如果在没有数据时CAN_H和CAN_L电压差就很大说明收发器状态异常需要先解决硬件问题再做软件调试。4.2 双机收发验证的三种方法方法一串口打印验证。这是我最推荐的方式。A板循环发送测试帧B板在HAL_CAN_RxFifo0MsgPendingCallback回调里把接收到的ID和数据通过串口打印到上位机。A板上电后每隔1秒发送一次B板上接USB转TTL打开串口助手波特率设为115200如果看到如下输出说明通信已经打通Rx ID:0x101 Data:01 02 03 04 05 06 07 00 Rx ID:0x101 Data:01 02 03 04 05 06 07 00方法二回环验证。这个方法适合先排除自己这边的问题。把A板的CAN_TX引脚直接旁路到自己的CAN_RX不经过收发器然后在代码里强行让内部回环模式生效把BTR寄存器SILM和LBKM位设置一下发出去的数据自己能收到。这个方法在硬件收发器异常时特别有用能帮你区分是外设问题还是外部电路问题。HAL库没有直接提供回环配置函数需要手动改写CAN_InitTypeDef.Mode或者直接操作CAN-BTR寄存器。如果不熟悉寄存器也可以直接在CubeMX的CAN配置页把Mode改为Loopback生成代码后验证接收通路之后再改回Normal模式。方法三示波器/逻辑分析仪测波形。有设备的同学可以在CAN_H和CAN_L之间接上示波器探头发送一帧数据时可以看到约2V共模电压上的差分跳变。如果你看到一个类似串口波形但幅度只有2V左右的差分信号说明物理层正在工作。这个方法在调试波特率时尤其好用波形位宽可以直接换算成波特率。4.3 没有示波器时如何判断总线状态没有示波器不代表只能瞎猜。CAN控制器本身有一个状态寄存器可以通过HAL库查询。我在排查问题时常用HAL_CAN_GetState()和HAL_CAN_GetError()把它们打在串口上判断总线状态。HAL库返回HAL_CAN_STATE_LISTENING表示总线在正常监听HAL_CAN_STATE_BUSY表示正在收发。如果反复出现HAL_CAN_STATE_ERROR_ACTIVE或ERROR_PASSIVE说明总线上有错误帧。更直接的办法是观察发送函数返回值。HAL_CAN_AddTxMessage()如果连续返回HAL_ERROR大概率是总线关闭或者配置错误。此时可以用串口打印HAL_CAN_GetError()的具体错误码比如HAL_CAN_ERROR_ACK就是典型的没有收到应答通常对方节点不在线上或者波特率不一致HAL_CAN_ERROR_STF则是填充错误多半是总线受到干扰或终端电阻有问题。5. 常见问题与排查技巧实录5.1 收不到数据从物理层到应用层逐级排查收不到数据是双机调试里遇到最多的现象没有之一。我把排查思路整理成一张表格照着顺序查大多数五分钟内能定位序号检查项判断方法常见原因1接线万用表测CAN_H/CAN_L电压交叉接线、未共地、收发器供电异常2终端电阻断电后万用表测总线两端阻值忘记接电阻或接法错误3波特率两边初始化参数对比双方参数不一致或时间量子算错4过滤器代码检查FilterIdHigh/掩码位未左移5位、过滤器未激活5中断是否调用ActivateNotification漏调、回调函数名称拼写错误6发送邮箱检查AddTxMessage返回值邮箱全满、节点离线导致一直重发7控制器状态HAL_CAN_GetState未调用HAL_CAN_Start外设处于初始化态这里特别提醒第6点。很多同学发现A板虽然发不出数据但程序没有报错这是因为HAL_CAN_AddTxMessage()只是把数据放进邮箱真正发送是由硬件完成的。如果总线上没有其他节点响应ACK应答硬件会不断重发直到错误计数器超过阈值进入Bus Off。所以在排查时不仅要看发送函数有没有返回HAL_OK还要在串口里观察错误码。5.2 总线错误与错误帧的处理思路CAN总线自带错误检测机制但这套机制也会让新手困惑明明只是两个板子通信为什么总线上会出现大量错误帧我遇到过的情况主要有三种。第一种是物理层问题。CAN线过长或者终端电阻没接好信号反射导致位定时采样点采到了错误电平。解决方法是先降低波特率试一下如果问题消失基本就是物理层问题。我试过把1Mbps降到125kbps原先频繁的错误帧立刻消失。第二种是收发器问题。TJA1050在5V供电时信号幅值正常但如果模块用了3.3V供电某些型号的收发器输出电平会不够导致远距离通信时误码。选型时优先选宽电压的收发器或者按模块说明正确供电。第三种是节点长时间离线。如果B板烧录前A板已经在跑发送循环A板会因为收不到ACK而不断重发进入Bus Off后恢复需要时间。这种情况不算硬件故障先把B板烧录好再上电就能解决。错误帧本身并不可怕CAN协议会自动重发失败帧这是它的容错设计。真正需要警惕的是错误帧占比过高那说明物理层或配置存在系统性问题。我判断的标准是正常运行过程中错误帧占比超过0.1%就要查原因超过1%基本不能上线。5.3 波特率匹配问题的核心表现波特率不匹配在两个节点间最常见的表现是发送方HAL_CAN_AddTxMessage()返回成功但发送节点很快进入Bus Off接收方完全收不到数据。或者接收方收到一堆乱码因为采样点采到了错误的电平值。要快速判断波特率是否一致最可靠的办法是看错误计数器。在HAL库中可以通过读取CAN外设的ESR寄存器获取错误状态如果你发现ECR寄存器中的REC接收错误计数持续增长到超过127说明节点进入了Error Passive状态大概率是波特率不匹配或者物理层信号质量太差。当然最直接的还是双方都用同一份CubeMX配置从源头杜绝这个问题。5.4 双机调试的独家心得调试CAN有一个原则在我这些年里反复被验证不要同时怀疑所有环节。很多新手一上来就怀疑代码实际上硬件问题占了六成。我的习惯是先用官方例程或最小代码把两边的CAN驱动跑通确认能收发再往里面加业务逻辑。这样做最大的好处是一旦出现问题你知道至少底子是干净的。第二个心得是善用回车换行把调试信息打印完整。CAN帧数据是二进制的光看串口助手里的字节有时不够直观。我自己写打印函数时会把ID、DLC、8字节数据全部以十六进制打印出来并且每帧占一行。这样一旦数据错位一眼就能看到。第三个心得是双机调试时两块板子都要连串口。只连一块板子你只能看到自己的发送状态或接收状态看不到对方的反馈。两边都连上串口就能在同一条时间线上比对“A发了什么”、“B收到了什么”定位问题快很多。6. 进阶扩展方向6.1 从双机扩展到多机过滤器的延伸玩法双机跑通之后很多项目会往多机方向扩展。CAN的多机和串口多机有一个本质区别每条报文都自带ID接收方通过ID就知道这帧是谁发的。所以理想的做法是给每个节点分配一个唯一ID段比如节点1发0x101节点2发0x102以此类推。接收端可以使用掩码模式把“与我相关”的帧收进来。比如节点3只关心节点1和节点2发来的数据可以把掩码设置为只匹配高6位低5位忽略。这样0x101和0x102都能进FIFO0x201和其他地址则被硬件挡住。这个过程完全不占用CPU是CAN硬件过滤器的优势。如果三个节点的数据量都很大还可以把FIFO0和FIFO1分开用。FIFO0放高优先级实时控制帧FIFO1放低优先级状态帧两个FIFO独立触发不同回调逻辑更清晰。6.2 负载率怎么算什么时候该紧张提到CAN网络规划负载率是个绕不开的概念。简单说负载率就是总线上实际发送的位时间占可用时间的比例。以1Mbps为例一秒钟最多传输1百万个bit。如果一帧标准数据帧在填充后大约是130位ID、控制段、数据段、CRC、填充位等加起来那么每秒发送100帧负载率约为13000/1000000 1.3%。我在实际项目里的经验阈值是10%以下非常轻松随时可以加节点10%~30%正常范围但要注意突发帧的峰值30%~50%偏紧需要仔细设计发送周期50%以上建议重新规划总线否则遇到错误重传很快会打满总线这个负载率是很多人不重视的总觉得“先跑通再说”。但遇到多个节点同时爆发数据时CAN仲裁机制会保证高优先级ID先走低优先级帧会被延迟。如果延迟时间超出业务容忍度系统就会出问题。设计阶段花10分钟算一下负载率后面能省下好多事。6.3 从双机到工程化还要做什么如果你不只是学习而是要把这套双机通信搬到实际产品里还有几个细节需要注意。第一是看门狗。CAN控制器在进入Bus Off后会自动恢复但恢复时间不可控可靠性要求高的项目中我会用硬件看门狗监控通信心跳如果长时间收不到主节点的心跳帧就重启CAN外设或者整机复位。第二是错误统计。HAL_CAN_GetError()可以拿到错误源但在产品中你不能只打印要有一个错误计数变量连续报错超过阈值就切换故障状态。第三是帧周期抖动。有些应用对控制帧的周期性要求很高直接用HAL_Delay延时发送会产生不小的抖动更好的方案是用定时器触发发送让发送周期严格稳定。这些点加进去之后你的CAN通信就从“能跑”变成了“能交付”。我自己做项目时第一版永远是只要能通信就收工第二版才开始补错误处理、心跳检测、周期管理这些东西。先跑通再完善这也是我给所有做嵌入式的人的建议。最后再分享一件事。我最早调CAN双机的时候有一个晚上因为终端电阻接错了位置两块板子距离不到半米通信却一直莫名丢帧。我排查了整整三个小时把代码翻了个底朝天最后发现只是两个120欧电阻并在了同一个收发器上。从那以后我养成一个习惯任何总线类通信调试先把电气层确认无误再碰软件。CAN总线报文上承载的是物理世界里的真信号信号不好代码写得再漂亮也白搭。希望这篇文章能帮你少走我之前走过的弯路。