简介：这是一份关于CAN总线驱动代码实现的嵌入式工程资源包，适合汽车电子、工业自动化领域的嵌入式开发者，尤其是正在学习GD32/STM32类MCU的CAN外设驱动编写与调试的人群。资源共710个文件，包含48个C源代码文件、49个头文件以及大量编译生成的.o、.d、.crf等中间产物，同时提供完整的Keil工程配置（uvprojx/uvoptx）和Hex/Axf烧录文件，压缩包约21.18MB，可支撑从源码阅读到编译下载的完整流程。简介中对CAN协议分层、帧格式、波特率配置、滤波器、中断与错误处理等关键模块做了系统梳理，并给出基于GD32F30x的硬件驱动实现示例。目前已有77人学习下载。通过这份资料，读者可以较快掌握CAN控制器初始化、数据收发以及异常处理的实际编码方法，获得可直接对照分析的驱动工程模板。 做嵌入式这几年，我最大的感受就是：CAN总线这个技术，入门不难，但真正把驱动代码写好、调稳，需要踩的坑比想象中多得多。这篇是项目进行到中后期时沉淀下来的东西——当时控制器要带着十几个从机节点跑CAN通信，牵一发动全身，最后从驱动层开始重构，才有了这份比较满意的实现。这篇就完完整整把核心思路和代码细节给你拆开来讲，适合同样在折腾CAN总线的朋友参考。
1. 拿到需求先想清楚：CAN驱动到底在驱动什么
在动手写代码之前，必须想清楚一个问题：CAN驱动这层代码，本质上解决的是两件事，一是把上层业务的数据正确封装成CAN帧发出去，二是把总线上收到的帧正确解析出来交给上层。听起来简单，但实际项目中大量的丢帧、卡死、错误帧问题，都出在这两件事之间的夹缝里。
1.1 为什么选CAN而不是串口或SPI
这个项目里，控制器和从机之间的通信距离有几米，而且现场环境存在电机启停带来的电磁干扰。串口在这类场景下用过的人都知道，没有差分信号，抗干扰能力弱，距离一长就出稀奇古怪的错误。SPI更不用说，虽然有高速优势，但本质上是一个主对多从的同步方案，距离、拓扑和仲裁都不适合。
CAN总线的价值在于三件事。第一，两根差分线（CAN_H和CAN_L）天然抗共模干扰，物理层就赢了一半。第二，多主仲裁机制，多个节点同时抢总线时，ID小的先发，不会撞车。第三，自带错误检测和自动重发机制，每个节点都能监控总线错误并自我标定状态。这些特性决定了它特别适合那种"一条总线上拖十几个节点、每个节点都要实时通信"的场景。
1.2 驱动代码的分层思路
我写驱动时喜欢把代码按照"硬件无关"和"硬件相关"拆开，这一点在CAN驱动上异常重要。硬件相关的部分很明确：寄存器配置、GPIO复用、中断与DMA这些，直接依赖芯片型号，换一颗芯片就得改。硬件无关的部分则是帧数据的组织、过滤规则的抽象、收发队列的管理，这些逻辑一旦抽象出来，移植到任何带CAN外设的芯片上都能复用。
这个项目用的平台是STM32的HAL库，因为HAL层把寄存器操作封装得比较完整，代码可读性和可维护性比较好。我的实际做法是：驱动文件只保留三部分职责——初始化、发送、接收。发送和接收内部都不直接暴露帧头帧尾和寄存器细节，上层业务拿到的只是标准化的数据结构。这样做的直接好处是，后来从STM32F1平台换到F4平台时，应用层代码几乎没有改动。
2. 初始化配置：硬件基础决定一切
CAN驱动的初始化是整个代码的地基。很多人上来就对着例程抄初始化函数，抄完能跑就不管了，结果换了节点数量或线缆长度后，通信时好时坏，问题往往就出在初始化参数没吃透。
2.1 GPIO与CAN外设时钟配置
以STM32F103这类常用芯片为例，CAN1的收发引脚通常在PA11（RX）和PA12（TX），但如果你用的是别的封装或者引脚被占用，也可能复用在PB8和PB9上。这个地方第一个坑就是：引脚复用功能一定要开对。
用CubeMX配置工厂模式下，其实要点就三步：把引脚模式设为Alternate Function，选择对应的复用号（AF9等，具体看型号），然后使能CAN外设的中断。如果你手写HAL代码，则在MspInit回调里面把GPIO和中断使能写好。
void HAL_CAN_MspInit(CAN_HandleTypeDef* hcan) { GPIO_InitTypeDef GPIO_InitStruct = {0}; __HAL_RCC_CAN1_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitStruct.Pin = GPIO_PIN_11 | GPIO_PIN_12; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); HAL_NVIC_SetPriority(CAN1_RX0_IRQn, 0, 0); HAL_NVIC_EnableIRQ(CAN1_RX0_IRQn); }这里有个容易被忽略的细节：引脚速度尽量设置到HIGH。CAN总线速率高时，如果引脚翻转速度不够，信号的边沿会被拉长，波形上升沿和下降沿变得圆滑，直接表现为总线误码率上升。
GPIO和时钟配置好之后，还不能急着初始化CAN模式，HAL库的要求是先调用HAL_CAN_Init进入初始化态，再配置过滤器，最后调用HAL_CAN_Start启动CAN通信。这个顺序如果颠倒，会出现寄存器返回错误或者过滤器不生效的情况。
2.2 位时序计算：波特率是算出来的，不是蒙出来的
CAN的波特率由分频和位时间段决定，这一点必须吃透。CAN协议把一个bit时间划分为若干个时间量子（tq），基本结构是：同步段（SS，固定1个tq）、传播时间段（PTS）、相位缓冲段1（PBS1）、相位缓冲段2（PBS2），整个位时间 = SS + PTS + PBS1 + PBS2。
STM32的CAN外设配置里分频值（Prescaler）和BS1、BS2就是用来确定这个结构的。实际项目里常见的是500kbps，我们来算一笔账。假设系统时钟为72MHz，CAN外设挂载在APB1上，APB1分频后通常为36MHz，那么CAN外设时钟是36MHz（不同芯片有差异，必须先查自己的时钟树）。波特率 = CAN时钟 / (Prescaler × (1 + BS1 + BS2))。
期望波特率500kbps，36000000 / 500000 = 72个tq，那如果Prescaler取4，则36M/4 = 9MHz，9M/500k = 18个tq。位时间由18个tq组成，减去固定的1个SS段，剩下17个tq分配给PTS + PBS1 + PBS2。为了采样点在80%附近，我一般把采样点设置在85%左右较稳妥，那可以配置BS1 = 14，BS2 = 3？检查一下：1 + 14 + 3 = 18，采样点 = (1 + 14) / 18 = 83.3%，比较合理。而如果取Prescaler = 1，那就需要72个tq，也可以，但过长的位时间会让同步过程变得迟钝，所以一般取4~16之间的分频值更合适。
| 项目 | 推荐值 | 说明 |
|---|---|---|
| 时钟频率 | 36 MHz | 确认APB1外设时钟 |
| Prescaler | 4 | 得到9 MHz的TQ频率 |
| BS1 | 14 tq | 对应传播段+相位缓冲1 |
| BS2 | 3 tq | 对应相位缓冲2 |
| 采样点 | 83.3% | 处于位时间后段，抗干扰较好 |
采样点的选择是个工程经验问题。如果总线上节点数量多、线缆长，信号边沿容易变缓，采样点要靠后一些；如果波特率较高，则采样点不能太靠后，否则来不及判断下一位。这个参数没有绝对正确，只有结合自己的硬件环境实测调整。
配置代码在HAL库里面长这样：
hcan.Instance = CAN1; hcan.Init.Prescaler = 4; hcan.Init.Mode = CAN_MODE_NORMAL; hcan.Init.SyncJumpWidth = CAN_SJW_1TQ; hcan.Init.TimeSeg1 = CAN_BS1_14TQ; hcan.Init.TimeSeg2 = CAN_BS2_3TQ; hcan.Init.TimeTriggeredMode = DISABLE; hcan.Init.AutoBusOff = ENABLE; hcan.Init.AutoWakeUp = DISABLE; hcan.Init.AutoRetransmission = ENABLE; hcan.Init.ReceiveFifoLocked = DISABLE; hcan.Init.TransmitFifoPriority = DISABLE; if (HAL_CAN_Init(&hcan) != HAL_OK) { Error_Handler(); }特别注意参数：AutoBusOff置成ENABLE后，总线出现严重错误导致节点进入Bus-Off状态时，硬件会自动等待恢复而无需软件干预，这对无人值守的控制器节点很重要。AutoRetransmission置为ENABLE也很关键，发送的帧如果因仲裁丢失或错误而失败，硬件会自动重发，否则丢帧就只能靠软件补，复杂度陡增。
2.3 终端电阻的物理层细节
初始化搞定了，但如果总线物理层没处理好，驱动写得再好也白搭。CAN总线两端必须各接一个120欧姆终端电阻。这个电阻的作用是匹配线缆的特性阻抗，吸收信号反射。没有匹配的反射信号会叠加在原始波形上，让CAN_H和CAN_L的差分电压出现振铃，接收端误判的概率大幅提高。
判断是否需要终端电阻有一个快速技巧：用万用表测量CAN_H和CAN_L之间的直流电阻。如果测到大约60欧姆，说明总线两端都有120欧姆电阻——正确。如果测到120欧姆，说明只在一端接了，另一端缺失。如果接近0欧姆，说明短路了。这个60欧姆的判断值我屡试不爽，调试现场最常用的就是这个方法。
3. 收发逻辑：驱动代码的核心战场
初始化只是把跑道修好了，真正要飞起来的是收发逻辑。这里最大的问题是：CAN是广播式总线，每个节点都能收到总线上所有的帧，如何高效地只处理自己需要的帧，同时不遗漏重要数据？
3.1 过滤器配置
STM32的bxCAN控制器内置了过滤器组，可以配置为列表模式或屏蔽位模式。列表模式比较严格，必须每个ID精确匹配才接收。屏蔽位模式则是按位匹配，某一位可以是"无关项"，一片ID都能通过。项目实践中，如果通信对象是固定几个节点ID，我习惯用列表模式，匹配精准，代码直观。如果对端ID动态变化或者需要支持广播地址，则用屏蔽位模式更灵活。
下面是一个典型的过滤器配置：接收标准ID为0x321和0x322的帧，其它的全部丢弃。
CAN_FilterTypeDef canfilter; canfilter.FilterActivation = ENABLE; canfilter.FilterMode = CAN_FILTERMODE_IDMASK; canfilter.FilterScale = CAN_FILTERSCALE_32BIT; canfilter.FilterIdHigh = (0x321 << 5) >> 8; canfilter.FilterIdLow = ((0x321 << 5) | CAN_ID_STD) & 0xFF; canfilter.FilterMaskIdHigh = 0xFFFF; canfilter.FilterMaskIdLow = 0xFFFC; canfilter.FilterBank = 0; canfilter.FilterFIFOAssignment = CAN_RX_FIFO0; HAL_CAN_ConfigFilter(&hcan, &canfilter);这里有一个常见的误区：标准ID和扩展ID的位宽不同，过滤时要按照对应的格式把ID移位到寄存器指定位置，HAL库里如果直接填原始ID而不移位，过滤器永远不会命中。另外，FIFO分配也要注意，同一个FIFO可以挂多个过滤器组，优先级由过滤器编号决定，编号小的先匹配，匹配成功则帧进入FIFO，不再继续匹配。
3.2 发送实现细节
发送流程在HAL库中被封装得非常简洁，但背后的机制值得注意。CAN外设有多个发送邮箱，硬件自动选择一个空闲邮箱排队发送，发送完成后触发发送邮箱空中断。如果邮箱被占满且AutoRetransmission开启，新的发送请求会一直等待，这可能造成发送接口阻塞较长时间。
我一般的做法是，把发送接口设计成"非阻塞"，上层调用发送时，先检查是否有邮箱空闲，如果没有就直接返回失败码，让上层决定是重试还是丢弃。这样能避免驱动层长期占用CPU时间。判断邮箱状态可以使用HAL_CAN_GetTxMailboxesFreeLevel()函数。
uint8_t CAN_SendFrame(uint32_t stdId, uint8_t* data, uint8_t len) { CAN_TxHeaderTypeDef txHeader; uint32_t txMailbox; txHeader.DLC = len; txHeader.IDE = CAN_ID_STD; txHeader.RTR = CAN_RTR_DATA; txHeader.StdId = stdId; if (HAL_CAN_AddTxMessage(&hcan, &txHeader, data, &txMailbox) != HAL_OK) { return 0; } return 1; }DLC（数据长度码）这个字段有个细节，CAN FD和经典CAN不同，经典CAN的DLC表示实际字节数，最大8个字节。但DLC的编码值可以大于8，这在经典CAN里属于非法长度，发送时会被部分节点当作错误帧处理。所以驱动代码里必须判断：如果len大于8，做截断或者直接返回错误。
3.3 接收中断与消息解析
接收逻辑要保证不丢帧，最稳妥的方案是中断接收。HAL库的接收中断回调机制是：当FIFO0收到新帧，进入中断，HAL_CAN_RxFifo0MsgPendingCallback回调函数被触发。在回调里调用HAL_CAN_GetRxMessage取出帧内容。如果回调执行时间过长，后面来的帧可能溢出FIFO，所以接收回调里只做数据拷贝，不做业务解析，解析放到主循环里。
void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rxHeader; uint8_t rxData[8]; HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &rxHeader, rxData); if (rxHeader.StdId == 0x321) { // 拷贝到业务缓冲，置位标志位 rx_flag_0x321 = 1; memcpy(rx_buffer_0x321, rxData, 8); } }中断回调里不要调用HAL_CAN_Start或者HAL_CAN_ActivateNotification这类函数，它们在中断里重新使能中断会有风险，而且也没有必要，正确的使能时机应该放在主程序初始化阶段，一次性把接收中断打开：HAL_CAN_ActivateNotification(&hcan, CAN_IT_RX_FIFO0_MSG_PENDING)。
4. 学会用波形和数据区判断问题
代码写完了，最终还要上线跑。CAN驱动写得好不好，波形和数据区是最客观的裁判。
4.1 波形怎么看穿通信质量
用示波器同时抓CAN_H和CAN_L两根线是最直接的判断方法。正常情况下，总线空闲时两根线都稳定在2.5V附近，这个状态对应隐性电平。当节点开始发送显性位时，CAN_H被拉高到3.5V左右，CAN_L被拉低到1.5V左右，差分电压从0V跳到2V左右，这就是逻辑0。如果是逻辑1的隐性位，两根线都回到2.5V，差分电压接近0V。
所以"电压差是怎么改变的"这个热搜问题的答案就藏在波形里：显性位对应槽型脉冲，隐性位对应平直回线。如果波形上方沿和下方沿不对称，比如CAN_H上升沿慢、CAN_L下降沿快，说明总线负载过重或者节点驱动能力不均衡。如果边沿出现明显过冲和振铃，多半是终端电阻缺失或阻抗不匹配。如果波形上出现很多毛刺，就要检查地线、屏蔽层和节点供电。
再进一步，把波特率测量出来。测波形相邻两个显性位起始端之间的时间间隔，取倒数就是实际波特率。如果和配置的500kbps对不上，初始化参数算错了。这个验证方法非常快，配置完第一件事就该量这个。
4.2 总线错误码就是字典
STM32的CAN外设有一个CAN_ESR寄存器，里面的LEC字段会记录最近一次的错误类型：0表示无错误，1表示位填充错误，2表示格式错误，3表示ACK错误，4表示显性位错误，5表示位错误。这个字段是排查问题的第一现场。
举例来说，ACK错误在单节点调试时非常常见。发送节点发出数据帧后，需要等待至少一个其他节点应答ACK位。如果总线上只有自己一个节点，没有节点回应ACK，发送就会一直重试并报ACK错误。这个不是驱动代码的问题，而是测试环境的问题，加一个节点或者用CAN分析仪看着就能解决。如果项目上遇到"控制器发给执行器一直失败"，优先确认执行器是否真的在总线上。
实践中我还遇到过一种诡异情况：两个节点的波特率配置看似都是500k，但采样点差异很大，短距离测试没问题，一旦距离拉长就大量位错误。最后用CAN_ESR寄存器抓到大量位填充错误，才定位到是采样点不一致。所以项目里多个节点的位时序参数务必统一，不能只统一波特率数字。
4.3 常见问题排查对照表
总结一下实际项目里最常踩的坑，整理成表格，照着查能省很多时间：
| 现象 | 可能原因 | 排查手段 |
|---|---|---|
| 完全无法通信 | 终端电阻缺失、CAN_H/L接反 | 测CAN_H与CAN_L间电阻，应在60Ω左右 |
| 偶发丢帧 | 采样点不合理、总线长度过长 | 抓波形看边沿质量，统一各节点位时序 |
| 总线错误帧频发 | 波特率不一致、地线电位差 | 检查CAN_ESR的LEC字段，确认共地 |
| 发送返回超时 | 总线上无其他节点应答 | 加分析仪或从机节点，确认ACK |
| 热点干扰导致通信中断 | 线缆未双绞、屏蔽层未接地 | 更换双绞线，屏蔽层单端接地 |
这些坑每一个我都真实踩过。尤其是采样点统一这件事，起初觉得不就是一个波特率嘛，后来项目规模大了，各种批次硬件混装，才明白位时序参数的统一规范必须写进项目文档，否则后期联调会非常痛苦。
最后再分享一个小技巧：调试CAN驱动，不管代码写的多好，务必在调试阶段接一个CAN分析仪，全程记录总线报文和错误帧。之前项目运行不规律，偶尔掉线又自动恢复，查了一个礼拜没头绪，最后靠分析仪日志发现是某个从机在上电瞬间向总线发送乱码帧，把总线干扰到总线关闭状态，过几秒恢复后又正常。这种灵异问题，没有日志很难定位。驱动代码只是载体，把总线状态监控和错误统计也一并加到驱动里，是让系统长期稳定的关键一环。
本文还有配套的精品资源，点击获取
