简介：这份资源面向使用STM32G0B1进行FDCAN通信开发的嵌入式工程师与学习者，围绕HAL库实现CAN帧发送这一核心场景，帮助解决FDCAN模块初始化、消息对象配置与总线参数设置等实际问题。压缩包共1215个文件，以661个c源文件、259个h头文件为主，辅以103个s汇编启动文件、24个icf链接脚本及uvprojx、ioc等工程配置，整体约56.26MB，构成一套可直接编译的完整工程。内容涵盖STM32G0B1的FDCAN外设特性、HAL库标准化接口调用、比特率与帧格式设定、错误检测机制，并延伸至通过CAN总线与TFT_VCU显示终端交互的命令帧设计，预览中可见数学库与HAL外设驱动文件，说明工程同时集成了信号处理与多外设支持。已有1083人学习下载，适合希望从零搭建FDCAN收发链路、理解HAL抽象层移植思路的开发者参考，也可作为汽车电子、工业自动化等场景的通信代码模板。
1. FDCAN_Send.rar 背后：一个 CAN FD 发送端到底要解决什么问题
如果你手里拿到一个叫FDCAN_Send.rar的压缩包，大概率场景是这样的：某块板子上跑着 CAN FD，你需要让它周期性地往外发几帧报文，或者按事件触发发一帧，但手头的工程要么是经典 CAN 的旧代码，要么是别人给的半成品，收发都对不上。这个标题里的关键词拆开看就三件事——FDCAN 是外设控制器，Send 是发送方向，rar 说明它是一份可解压的工程或源码集合。它要解决的核心问题不是“CAN 是什么”，而是“怎么让 FDCAN 外设真的把一帧数据按你想要的格式、时序、ID 发到总线上，并且能被另一台设备正确收到”。
适合读这篇的人有三类：刚接触 CAN FD、需要从零把发送跑通的嵌入式新手；手里有经典 CAN 代码、想迁移到 FD 的熟手；以及做台架测试、需要写一个稳定发送端来喂数据的测试工程师。发送端看起来比接收端简单，但实际踩坑一点不少——波特率配置、采样点、帧格式、邮箱分配、发送确认，任何一处不对，示波器上就是一片安静。下面按“先立住原理、再动手复现、最后讲坑”的顺序，把这条链路走一遍。
2. FDCAN 发送链路的原理与最小工程搭建
2.1 从经典 CAN 到 CAN FD：发送端多了哪些必须处理的参数
经典 CAN 一帧最多 8 字节数据，波特率全场统一。CAN FD 把这两点都改了：数据段可以到 64 字节，并且允许仲裁段和数据段用两个不同的波特率，也就是常说的“双波特率”。发送端因此多出一组必须显式配置的参数：仲裁段波特率、数据段波特率、采样点、以及数据段长度。很多人第一次配 FD 发送失败，不是代码写错，而是数据段波特率没使能，或者采样点落在总线容差之外。
仲裁段和数据段的分界点在 BRS 位。BRS 为隐性时切到高速数据段，为显性时保持仲裁段速率。发送端要保证 BRS 位和实际配置一致，否则接收端采样位置全乱。另一个容易忽略的是 DLC 编码：FD 的 DLC 不再是线性对应字节数，9 到 15 对应 12、16、20、24、32、48、64 字节。你写 DLC=9 以为发 9 字节，实际发的是 12 字节，接收端长度校验直接失败。
2.2 发送邮箱、优先级与触发方式的选择
FDCAN 外设内部一般有多个发送邮箱（也叫 Tx Buffer 或 Tx FIFO）。发送端设计的第一步是决定用邮箱还是 FIFO。邮箱模式适合少量、需要区分优先级的报文，每个邮箱独立配置 ID 和 DLC；FIFO 模式适合批量、顺序发送，按写入顺序出队。多数 MCU 的 FDCAN 支持“专用 Tx Buffer + Tx FIFO/Queue”混合，专用 Buffer 用于高优先级或周期帧，FIFO 用于普通数据。
优先级由 ID 决定，ID 越小仲裁优先级越高。发送端如果同时塞多帧，硬件按 ID 仲裁，不是按你调用发送函数的顺序。这一点在台架测试里经常翻车：你以为先发的帧先上总线，实际低 ID 帧插队了。触发方式上，周期帧用定时器触发发送，事件帧在状态机里调用发送，两者不要混在同一个邮箱里，否则周期抖动会变大。
2.3 用 HAL 库搭一个可复现的 FDCAN 发送最小工程
下面以常见的 STM32 HAL 风格为例，给出一段可抄的发送初始化与发送函数。不同厂商 API 名字不同，但参数含义一致，照着改即可。
/* fdcan_send.c - FDCAN 发送端最小实现 */ #include "fdcan.h" FDCAN_HandleTypeDef hfdcan1; FDCAN_TxHeaderTypeDef TxHeader; uint8_t TxData[64]; /* 初始化：仲裁段 500k，数据段 2M，采样点 80% */ void FDCAN1_Init(void) { hfdcan1.Instance = FDCAN1; hfdcan1.Init.FrameFormat = FDCAN_FRAME_FD_BRS; /* 使能 FD 与 BRS */ hfdcan1.Init.Mode = FDCAN_MODE_NORMAL; hfdcan1.Init.AutoRetransmission = ENABLE; /* 失败自动重传 */ hfdcan1.Init.TransmitPause = DISABLE; hfdcan1.Init.ProtocolException = DISABLE; /* 仲裁段 500k：标称分频与段配置 */ hfdcan1.Init.NominalPrescaler = 4; hfdcan1.Init.NominalSyncJumpWidth = 4; hfdcan1.Init.NominalTimeSeg1 = 31; hfdcan1.Init.NominalTimeSeg2 = 8; /* 数据段 2M：数据段分频与段配置 */ hfdcan1.Init.DataPrescaler = 1; hfdcan1.Init.DataSyncJumpWidth = 4; hfdcan1.Init.DataTimeSeg1 = 15; hfdcan1.Init.DataTimeSeg2 = 4; hfdcan1.Init.StdFiltersNbr = 0; hfdcan1.Init.ExtFiltersNbr = 0; hfdcan1.Init.TxFifoQueueMode = FDCAN_TX_FIFO_OPERATION; if (HAL_FDCAN_Init(&hfdcan1) != HAL_OK) { Error_Handler(); } HAL_FDCAN_Start(&hfdcan1); } /* 发送一帧：id 为标准帧，len 为实际字节数 */ uint8_t FDCAN1_Send(uint32_t id, uint8_t *buf, uint8_t len) { TxHeader.Identifier = id; TxHeader.IdType = FDCAN_STANDARD_ID; TxHeader.TxFrameType = FDCAN_DATA_FRAME; TxHeader.DataLength = len; /* HAL 内部会转成 DLC 编码 */ TxHeader.ErrorStateIndicator = FDCAN_ESI_ACTIVE; TxHeader.BitRateSwitch = FDCAN_BRS_ON; /* 数据段切高速 */ TxHeader.FDFormat = FDCAN_FD_CAN; TxHeader.TxEventFifoControl = FDCAN_NO_TX_EVENTS; TxHeader.MessageMarker = 0; if (HAL_FDCAN_AddMessageToTxFifoQ(&hfdcan1, &TxHeader, buf) != HAL_OK) { return 1; /* 入队失败，通常是 FIFO 满 */ } return 0; }逻辑说明：初始化里把FrameFormat设为FDCAN_FRAME_FD_BRS，这是发送端能发 FD 帧且数据段变速的前提；AutoRetransmission打开后，仲裁丢失或错误帧会自动重发，台架测试建议打开，实时控制场景要评估重传带来的延迟。发送函数里DataLength直接填字节数，HAL 负责映射到 DLC，但你要清楚 9 到 15 的映射关系，接收端长度校验才一致。
参数说明：NominalPrescaler和DataPrescaler分别决定仲裁段和数据段的时间量子。采样点由TimeSeg1和TimeSeg2决定，公式是(1 + TimeSeg1) / (1 + TimeSeg1 + TimeSeg2)。上面仲裁段采样点约 80%，数据段约 80%，这是 500k/2M 组合下比较稳的取值。实际项目里采样点要按总线长度和收发器延迟微调，不能照搬。
2.4 发送确认与总线错误状态怎么读
发送函数返回成功只代表帧进了 FIFO，不代表上了总线。要确认真正发出，得看发送事件 FIFO 或中断标志。常见做法是开启TxFifoEmpty中断或轮询HAL_FDCAN_GetTxFifoFreeLevel，再配合HAL_FDCAN_GetErrorCounters读发送错误计数 TEC。TEC 持续增长说明总线上没有其他节点应答，或者波特率不匹配。发送端单独上电、总线上没有第二个节点时，TEC 会累加到错误被动甚至总线关闭，这是正常现象，不是代码 bug。
3. 把 FDCAN_Send 工程跑起来：从解压到第一帧上总线
3.1 解压后先看什么：工程结构与依赖判断
拿到FDCAN_Send.rar这类压缩包，先别急着编译。解压后按顺序确认四件事：有没有厂商 HAL/LL 库、有没有启动文件和链接脚本、有没有时钟配置、有没有收发器使能引脚的定义。很多发送失败案例的根因是收发器没使能——MCU 的 FDCAN 引脚出来了，但外部 CAN 收发器的 STB 或 EN 引脚悬空，总线一直是隐性，示波器上看不到任何差分信号。
工程结构上，发送端通常包含fdcan.c、main.c、stm32f4xx_hal_msp.c这类文件。重点看 MSP 初始化里 GPIO 的复用功能有没有配对，FDCAN1 一般映射到 PA11/PA12 或 PB8/PB9，不同封装不一样。时钟树里要确认 FDCAN 的时钟源频率，因为分频参数是按这个频率算的，时钟源换了，波特率全错。
3.2 时钟与波特率参数的计算步骤
波特率计算是发送端最容易出错的地方。步骤如下：先确认 FDCAN 内核时钟fdcan_clk，再定时间量子tq = Prescaler / fdcan_clk，然后bit_time = tq * (1 + TimeSeg1 + TimeSeg2)，波特率就是1 / bit_time。以 500k 为例，若fdcan_clk = 40MHz，取Prescaler = 4，则tq = 100ns，需要 20 个 tq 组成一位，即1 + TimeSeg1 + TimeSeg2 = 20，取TimeSeg1 = 15、TimeSeg2 = 4，采样点 80%。
数据段同理，只是用DataPrescaler和DataTimeSeg1/2。注意数据段波特率不能超过收发器和总线能承受的上限，2M 在短总线上没问题，长总线要降。计算完最好用厂商的配置工具交叉验证一遍，手算容易在分频取整上差一个 tq，导致采样点偏移。
3.3 用回环模式先验证发送逻辑
在接真实总线之前，强烈建议先开回环模式自测。回环模式下发送端自己收自己，不需要第二个节点，能快速验证 ID、DLC、数据内容是否正确。
/* 回环模式初始化片段：只改 Mode */ hfdcan1.Init.Mode = FDCAN_MODE_INTERNAL_LOOPBACK; /* 其余参数与正常模式一致 */逻辑说明：内部回环把 Tx 直接接到 Rx，发送的帧会进接收 FIFO。你可以在接收中断里打印 ID 和 DataLength，确认发送端组帧没问题。这一步能排掉大部分“代码逻辑错”，剩下的才是“总线物理层错”。参数上，回环模式对波特率不敏感，但建议仍按目标波特率配置，保持和正式模式一致。
3.4 接上总线后的第一帧验证方法
回环通过后接真实总线。验证顺序：先只上电发送端和接收端，不接其他节点；用示波器或 CAN 分析仪看差分信号；确认接收端能收到且 ID、长度、数据一致；再逐步加入其他节点观察仲裁和错误计数。如果接收端收不到，先查终端电阻，CAN 总线两端各 120 欧，缺一个反射就严重，高速数据段尤其明显。
发送端这边，用HAL_FDCAN_GetErrorCounters读 TEC 和 REC。TEC 为 0 且接收端有数据，说明链路通。TEC 增长到 128 以上进入错误被动，到 255 总线关闭，这时要查波特率、接线、终端电阻。台架测试里我一般会先发一帧固定 ID、固定 8 字节的帧，确认通了再上 64 字节和 BRS。
4. FDCAN 发送端避坑：五条血泪经验
4.1 现象：发送函数返回成功但总线上没有波形
原因：最常见是收发器没使能或 GPIO 复用没配对。MCU 内部 FDCAN 已经发出，但引脚没切到 FDCAN 功能，或者收发器 STB 引脚电平不对，差分驱动器没工作。解决：查 MSP 里 GPIO 的Alternate设置，查收发器使能引脚原理图，用万用表量 STB 电平。其次是时钟没使能，FDCAN 外设时钟在 RCC 里要单独开。
4.2 现象：接收端收到的数据长度不对
原因：DLC 编码理解错。FD 的 DLC 9 到 15 不是 9 到 15 字节，而是 12、16、20、24、32、48、64。你填 9 期望 9 字节，实际发 12 字节。解决：发送端按实际字节数填DataLength，接收端按 DLC 映射表还原长度，两边用同一张表。超过 8 字节的帧一定要确认接收端也支持 FD，经典 CAN 控制器收到 FD 帧会报格式错误。
4.3 现象：数据段高速时误码率高、错误帧多
原因：采样点不合适或终端电阻缺失。数据段波特率越高，对采样点和总线反射越敏感。2M 数据段在长总线或没终端电阻时，采样点稍微偏一点就误码。解决：把数据段采样点调到 75% 到 80%，缩短总线或补终端电阻，必要时降数据段波特率。用示波器看数据段眼图，眼宽不够就是物理层问题，不是代码问题。
4.4 现象：多帧发送顺序和预期不一致
原因：硬件按 ID 仲裁，不按调用顺序。你连续调用发送，低 ID 帧先上总线。解决：需要严格顺序时，用同一个邮箱且等上一帧发送完成再发下一帧，或者把 ID 设计成递增。周期帧和事件帧分邮箱，避免事件帧被周期帧插队。这个坑在协议栈开发里很常见，表现是状态机时序偶发错乱。
4.5 现象：总线关闭后发送端不再恢复
原因：TEC 累加到 255 进入 bus-off，没有自动恢复或恢复条件没满足。解决：确认AutoRetransmission和自动恢复配置，bus-off 后按协议需要检测 128 次 11 位隐性位才能恢复。有些 HAL 需要手动调用HAL_FDCAN_Start重新启动。台架测试时如果只上电一个节点，必然 bus-off，这是预期行为，接上第二个节点再测。
5. 让发送端更可靠：周期调度与发送完成回调的配合技巧
发送端跑通之后，真正决定它能不能上项目的，是时序稳定性和异常恢复。我一般会把发送分成两层：上层是业务调度，用定时器或 RTOS 任务按周期组织要发的帧；下层是 FDCAN 发送完成回调，用来做流控和统计。两层之间用一个发送请求队列衔接，队列满时丢弃低优先级帧而不是阻塞，避免拖垮整个任务。
具体技巧上，周期帧用专用 Tx Buffer，每个 Buffer 绑定一个 ID，定时器到点直接触发对应 Buffer 发送，这样周期抖动只取决于定时器精度，不受 FIFO 排队影响。事件帧走 Tx FIFO，入队前检查HAL_FDCAN_GetTxFifoFreeLevel，剩余空间不足就记录一次丢弃计数，事后能定位是总线慢还是发送太猛。发送完成回调里更新每帧的发送时间戳和成功计数，跑一段时间后看统计，哪帧丢得多一目了然。
验证方法上，我会做一个简单的压力测试：以总线带宽的 70% 持续发送 64 字节 FD 帧，跑一小时，同时用分析仪统计错误帧率和 bus-off 次数。错误帧率为 0 且 TEC 稳定在低位，才算这个发送端可用。如果错误帧随负载上升，先降数据段波特率或优化采样点，再查终端电阻和线束。这个测试比单帧收发更能暴露问题。
还有一个容易被忽略的点是发送完成中断的优先级。如果 FDCAN 中断优先级低于其他高频中断，发送完成回调会被延迟，流控判断就不准。我一般把 FDCAN 中断设成中等优先级，高于普通任务但低于系统滴答，保证回调及时又不抢占关键时序。回调里只做计数和置标志，具体业务放到任务里处理，避免在中断里做耗时操作。
最后说个习惯：每次改完波特率或采样点，我都会先用回环模式跑一遍，再上真实总线，最后跑压力测试。这三步看着麻烦，但比在总线上抓瞎省时间。FDCAN 发送端的玄学大多出在物理层和参数配置，代码逻辑本身反而简单。把参数算准、把物理层查清、把异常恢复做全，这个FDCAN_Send类的工程就能从“能发”变成“敢用”。希望帮到你。
本文还有配套的精品资源，点击获取
