简介：基于TGA1050收发器的STM32之间CAN通信设计源码，面向嵌入式开发与汽车电子方向的工程师、学习者，解决两个STM32节点之间CAN总线通信的构建难题。项目采用C语言编写，基于Keil uVision工程，完整覆盖CAN控制器初始化、波特率与滤波器配置、中断服务程序设计，以及报文的发送和接收协议栈，并给出了错误检测与恢复思路。压缩包共187个文件，大小24.82MB，包括34个头文件、32个C源文件、33个目标文件、8个汇编源文件，以及Keil工程配置、链接映射、列表输出等辅助文件，结构分明，便于按模块阅读与维护。当前已有348人学习下载。通过这份设计源码，使用者能够深入理解TGA1050收发器与STM32的硬件连接和差分信号转换原理，掌握CAN通信工程的框架组织方式，在实际产品开发中可参考其初始化流程和容错机制，提高开发效率，降低调试成本。 做嵌入式这些年，TGA1050在我眼里就是TJA1050的国产替代方案，管脚兼容、价格友好、供货稳定，很多STM32开发板上直接焊的就是它。这个项目拆开看是三件事：STM32内部自带的CAN控制器负责协议，一颗TGA1050收发器负责物理层电平转换，再加上一套能直接跑的收发源码。目标是让两块STM32通过CAN总线稳定、可靠地互传数据。这类需求在车载电子、工业现场、设备联网里太常见了，尤其是多节点、长距离、强干扰的环境，CAN依然是性价比很高的选择。这套设计与源码我已经在两块开发板上实际验证过，下面把思路、电路、代码和踩过的坑一起整理出来，适合想快速上手CAN通信的嵌入式工程师参考。
1. 项目整体思路与方案选型
1.1 TGA1050与TJA1050的差异：为什么敢用国产料
先说说TGA1050。它在封装、引脚定义和功能上和TJA1050基本一致，SOP-8封装，TXD、RXD接控制器，CANH、CANL接总线。当年很多项目不敢用国产收发器，主要是怕电磁兼容和ESD性能拉胯。实际测试下来，TGA1050在1Mbps速率下表现稳定，ESD能力和TJA1050在同一档位，复杂工业环境里配合TVS管和共模电感使用，没有出现过批量通信异常。
选它的另一个原因是成本。消费级和工业级应用里，一颗收发器的差价看似不大，但量产后算下来很可观，而且国产芯片供货周期短，不用等海外料号大几周甚至几个月。这个项目是做STM32之间的CAN通信验证，收发器本身不是瓶颈，用TGA1050既能省钱又能保证功能，何乐而不为。
这里要说清楚一个分工问题：STM32内部集成的bxCAN外设只是CAN控制器，负责组帧、仲裁、错误检测这些协议层动作，但它输出的TTL电平信号无法直接驱动差分总线。TGA1050的职责就是把STM32发送引脚上的逻辑电平，转换成CANH和CANL上的差分信号，同时把总线上的差分信号还原成逻辑电平送给接收引脚。控制器加收发器，这才是完整的CAN节点。
1.2 为什么是CAN，不是UART也不是RS-485
很多初学者会问：两块板子通信，用串口不就行了？确实，UART点对点、全双工、实现简单，两块开发板之间传数据完全够用。但一旦变成多节点、线路拉长、现场有电机变频器这类干扰源，UART就顶不住了。RS-485虽然支持多点，但本质上需要一主多从的轮询机制，主节点要挨个点名，实时性靠不住。
CAN和这两者最大的区别是它天生支持多主通信，任何节点都可以主动往总线上发数据，靠ID仲裁决定优先级，不需要主机分配时间片。这在高实时性场合非常关键，比如设备报警、急停信号这类消息，必须能够在微秒级抢到总线。再加上CAN的差分传输、CRC校验、错误重发机制，物理层和协议层的可靠性都远超普通串口。
做个简单对比：
| 通信方式 | 拓扑 | 速率 | 实时性 | 错误处理 | 典型场景 |
|---|---|---|---|---|---|
| UART | 点对点 | 较低 | 一般 | 无协议校验 | 调试、短距离传输 |
| RS-485 | 多点主从 | 中等 | 依赖轮询 | 需自定义协议 | 工业仪表、远程采集 |
| CAN | 多主节点 | 最高1Mbps | 事件驱动 | 硬件自带检错重发 | 车载、工控、设备互联 |
所以这个项目选CAN，不是为了炫技，而是它确实适合“多个STM32节点之间自主通信”这个场景。
1.3 硬件连接：STM32与TGA1050之间的电平匹配
硬件连接看起来简单，实际上有几个细节不能省。STM32F103的CAN_TX和CAN_RX默认映射在PA12和PA11，也可以通过重映射到PB8和PB9，我建议直接用默认映射，少折腾。
PA12连接到TGA1050的TXD，PA11连接到TGA1050的RXD，TGA1050的CANH和CANL接总线。要注意的是收发器的供电电压。TGA1050有些批次设计为5V供电，RXD输出高电平时可能接近5V，而STM32的GPIO并不是所有引脚都支持5V容忍，直接连接存在风险。我的做法是优先选择宽压版本，让TGA1050直接用3.3V供电，RXD输出也是3.3V，和STM32电平完美匹配。如果你手头只有5V版本，RXD到STM32之间加一个1kΩ串阻，再并联一个3.3V稳压管或者用电阻分压，把高电平钳到安全范围。
总线两端各放一个120Ω终端电阻，这个不能省。CAN总线之所以需要120Ω，是因为双绞线的特征阻抗约120Ω，终端电阻匹配后能吸收反射信号，避免波形振铃影响通信质量。很多新手只接一个甚至不接，短距离低速率可能没感觉，一旦线长超过几米或速率上到500kbps，各种诡异问题就来了。
另外，TGA1050的电源引脚旁边要放100nF和10μF去耦电容，CANH、CANL上建议加TVS管和共模电感。这些物料成本不高，却能在做EMC认证或者现场批量部署时省掉大麻烦。
2. CAN协议要点：报文结构、仲裁与位时序
2.1 从5V差分到一帧报文：CAN到底怎么说话
CAN总线上传输的是差分电压信号。隐性电平对应逻辑1，显性电平对应逻辑0。5V供电的收发器在隐性状态下，CANH和CANL都保持在2.5V左右，差分电压接近0；显性状态下，CANH被拉高到3.5V左右，CANL被拉到1.5V左右，差分电压约2V。
用一个生活化的类比：总线就像一条共享的走廊，所有人都可以讲话，平时走廊安静，这就是隐性；有人拉低电平，就是显性。CAN协议规定显性优先，谁发了显性位，总线就呈现显性，其他节点的隐性位会被覆盖。这个特性是后面仲裁机制的基础。
再说报文帧。CAN标准数据帧由帧起始、仲裁段、控制段、数据段、CRC段、ACK应答段和帧结束构成。标准帧的标识符是11位，扩展帧是29位。数据段最长8字节，所以一帧CAN报文最多携带8个字节的有效数据，这看起来不多，但工程上通过合理编码完全够用。
帧结束时，发送节点会释放总线，接收节点如果正确收到帧，会在ACK段主动发送一个显性位作为应答。如果总线上没有任何节点应答，发送节点就会判定发送失败并重发。这解释了后面排查问题时会遇到的一个现象：单块板子自己发数据，如果总线上没有其他节点，发送是永远不会成功的，因为没有人回答它。
2.2 ID仲裁与接收过滤：小ID为什么优先
仲裁是CAN协议里最精彩的部分。多个节点同时发送时，它们都在往总线上写ID位，同时回读总线电平。因为显性电平覆盖隐性电平，写着写着，如果有节点的回读结果和自己发出的不一致，就说明有更高优先级的节点在竞争，这个节点立刻退出，转为接收模式，让ID更小的帧先走。
打个比方，就像几个人同时举手发言，谁的ID小谁先讲。ID越小优先级越高，这是CAN协议的硬规则。在工程实际中，通常把急停、报警这类高优先级消息分配小的ID，把周期性的状态数据分配大的ID，这样关键时刻高优先级消息一定能抢到总线。
接收过滤则是接收端的“门卫”。CAN控制器允许设置一组验收码和验收掩码，掩码位为1表示该位必须匹配，掩码位为0表示该位忽略。SJA1000时代叫ACCCode和ACCMask，STM32的bxCAN虽然叫过滤器，但思路完全一样。如果一个节点只关心特定ID的报文，过滤器会帮它直接丢弃不关心的帧，避免CPU被无效中断淹没。这也方便实现分布式系统：每个节点定义好自己关心哪些ID，其他节点发各自的，互不打扰。
2.3 波特率与SJW：两个节点能对上话的前提
CAN通信双方必须工作在同一个波特率下，这是常识，但很多人不知道波特率是怎么来的。CAN的一个位时间由同步段、传播时间段和相位缓冲段构成，STM32把后两段合并为BS1和BS2，再加上一个同步跳转宽度SJW。
位时间计算公式为：位时间 = 1TQ（同步段） + BS1 + BS2，波特率 = CAN时钟频率 / （预分频系数×位时间TQ数）。
以STM32F103为例，CAN1挂在APB1总线上，默认系统时钟72MHz时APB1为36MHz。目标波特率500kbps，把预分频设为9，BS1设为6TQ，BS2设为1TQ，那么位时间 = 1 + 6 + 1 = 8TQ，波特率 = 36MHz / (9×8) = 500kbps，采样点 = (1+6)/8 = 87.5%。
采样点这个参数很多人忽视。采样点太早，信号还没稳定就采样了；太晚，留给线缆传播延迟的时间又不够。推荐采样点在70%到87%之间，线上速率500kbps时87.5%是相当稳妥的配置。
SJW的作用是重新同步。总线上不同节点的晶振总是有小幅偏差，节点在检测到位边沿变化后，通过SJW调整采样位置，容忍时钟偏差。SJW通常设1~2TQ，设得太小抗频偏能力弱，设得太大接收窗口摆动过大。对多数应用来说，1TQ就够用。
3. 源码设计：从CubeMX到收发函数
3.1 CubeMX一步步配置CAN外设
我用STM32CubeMX生成工程，省去手写时钟配置的麻烦。选择芯片型号后，开启CAN1外设，引脚会自动分配为PA11和PA12。注意如果使用重映射引脚，需要在GPIO设置里手动配置。
关键在于CAN参数配置。把Prescaler设为9，Mode选Normal，SyncJumpWidth选1TQ，TimeSeg1选6TQ，TimeSeg2选1TQ。如果只是为了自测，Mode可以选LoopBack回环模式，此时CAN控制器在内部自发自收，可以不接外部节点。AutoRetransmission建议先关闭，这样发送失败会直接返回错误码，方便调试阶段定位问题。
生成工程后，核心初始化代码大致如下：
hcan1.Instance = CAN1; hcan1.Init.Prescaler = 9; hcan1.Init.Mode = CAN_MODE_NORMAL; hcan1.Init.SyncJumpWidth = CAN_SJW_1TQ; hcan1.Init.TimeSeg1 = CAN_BS1_6TQ; hcan1.Init.TimeSeg2 = CAN_BS2_1TQ; hcan1.Init.TimeTriggeredCommunicationMode = DISABLE; hcan1.Init.AutoBusOffManagement = DISABLE; hcan1.Init.AutoWakeUp = DISABLE; hcan1.Init.AutoRetransmission = DISABLE; hcan1.Init.ReceiveFifoLocked = DISABLE; hcan1.Init.TransmitFifoPriority = DISABLE; HAL_CAN_Init(&hcan1);3.2 发送路径：从待发数据到mailbox
STM32的CAN外设有3个发送邮箱，相当于3个待发通道。调用发送函数时，驱动会自动寻找一个空邮箱，把报文头和数据拷贝进去，然后硬件负责逐位发送。
发送一帧报文的代码很简单，但有几个字段要理解透彻：
CAN_TxHeaderTypeDef txHeader; uint32_t mailbox; uint8_t txData[8] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08}; txHeader.StdId = 0x123; // 标准帧ID txHeader.IDE = CAN_ID_STD; // 使用标准帧，还是扩展帧 txHeader.RTR = CAN_RTR_DATA; // 数据帧还是远程帧 txHeader.DLC = 8; // 数据长度，最多8字节 if (HAL_CAN_AddTxMessage(&hcan1, &txHeader, txData, &mailbox) == HAL_OK) { // 报文已加入发送邮箱，等待硬件发送 }关于远程帧，也就是RTR字段，很多教程喜欢讲但实际用得很少。远程帧是请求对方发送数据，但设计良好的系统里一般不会主动用远程帧，而是直接周期性发数据帧。远程帧处理逻辑复杂，一旦用不好容易造成总线风暴，我的建议是：项目初期一律用数据帧，把远程帧当成后续扩展项。
如果发送函数返回失败，先检查返回值。HAL_BUSY说明三个邮箱全满，可能是发送频率太高或者总线上有其他节点阻塞；HAL_ERROR说明参数有问题，比如DLC超过8。还有种情况是总线处于bus-off状态，这时候任何发送都不会成功，需要查看错误寄存器确认状态。
3.3 接收路径：FIFO与中断回调
接收报文有两种方式：查询和中断。查询方式在主循环里不停调用接收函数，缺点是CPU占用高，且消息来了不能及时处理。我推荐用中断，接收FIFO收到新消息时，硬件自动触发中断，在回调函数里处理数据，速度快且CPU空闲。
中断回调代码如下：
void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rxHeader; uint8_t rxData[8] = {0}; if (hcan->Instance == CAN1) { HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &rxHeader, rxData); // 判断ID，执行对应处理逻辑 if (rxHeader.StdId == 0x123) { // 处理接收到的8字节数据 } } }注意接收FIFO有两个，FIFO0和FIFO1，一个节点可以用两组过滤器分别把不同ID映射到不同FIFO。如果FIFO满了，新来的报文会被丢弃，这在调试阶段容易踩坑。我在调试时发现过一种情况：接收中断频率太高，回调函数处理不过来，FIFO溢出丢帧，但程序看起来一切正常，只有增加一个溢出计数器才发现问题。
回调函数里务必不要做耗时操作，比如打印日志、延时、复杂计算。CAN一帧500kbps下传输时间约200微秒，如果在回调里做太多事，下一帧来了处理不过来，就会丢帧。我的做法是回调里只做数据拷贝和置标志位，数据处理放到主循环。
3.4 源码分层与扩展：不能只跑通一次
工程里的源码不能简单把所有逻辑堆在main.c里，否则后续加协议、加节点会越来越乱。我习惯把CAN相关的硬件操作封装成bsp_can.c和bsp_can.h，提供初始化、发送、注册接收回调这几个接口，上层业务只关心数据内容，不关心引脚和寄存器。
// bsp_can.h 简要接口设计 void BSP_CAN_Init(void); uint8_t BSP_CAN_SendMessage(uint32_t id, uint8_t *data, uint8_t len); void BSP_CAN_SetReceiveCallback(void (*callback)(uint32_t id, uint8_t *data, uint8_t len));这样后续如果想加协议解析层，比如把CAN数据转化成设备控制指令，直接在业务层写逻辑就行，不需要再动CAN驱动。源码按这个方式组织，以后复制到其他项目上也快。
4. 实测、常见问题与避坑经验
4.1 开机第一件事：回环模式自测
拿到板子或者新焊接的板卡，第一步不要直接连总线，先把Mode配成LoopBack，用回环模式验证MCU到CAN控制器的通路是否正常。回环模式下CAN控制器的发送数据直接在内部回环到接收路径，不需要外部节点应答，省去了接线的干扰因素。
实测下来，回环模式能通过，说明STM32的CAN外设、时钟、中断、过滤器配置都没问题，剩下的变量只剩外部收发器和物理连接。这一步能筛掉一大批低级问题，减少联调时排查范围。
4.2 用示波器看CAN波形：判断通信质量
两块板子联调之前，我用示波器先看波形。探头接CANH和CANL，用数学通道看差分波形。正常波形下，隐性位时CANH和CANL都在2.5V附近，差分接近0；显性位时CANH到3.5V，CANL到1.5V，差分约2V。
500kbps速率下，一个位的时间是2微秒。用示波器的光标功能量一下相邻两个下降沿的间隔，可以确认实际波特率是否和预期一致。波形质量怎么看？边沿应该陡峭，不应该出现圆弧状；差分幅度不应该明显衰减；在字节间隙处不应该有大幅毛刺。如果波形上升沿很缓，多半是终端电阻没接好或者总线分支线太长。波形有回勾，可能是阻抗不匹配，要检查线缆和终端电阻。
有一次我遇到两块板子偶尔通信失败，看波形才发现总线在显性位结束时有明显过冲，定位到是分支线太长，把分支线剪短后问题消失。所以，波形是物理层问题最直接的证据。
4.3 常见问题排查速查表
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| 发送函数一直超时 | 总线上没有其他节点，无ACK应答 | 接上另一块板或CAN分析仪 |
| 两块板无法通信 | 波特率不一致，或CANH/CANL接反 | 核对两侧位时序参数，检查接线 |
| 能发不能收 | 过滤器配置把帧全屏蔽，或中断没开 | 检查过滤器和HAL_CAN_ActivateNotification |
| 收到大量错误帧 | 位时序偏差大，采样点位置不对 | 调整BS1/BS2，确保采样点在70%以上 |
| 偶发通信失败，波形异常 | 缺少终端电阻，分支线太长 | 总线两端接120Ω，缩短分支线 |
| Keil报no stm32 target found | SWD接线错误、板子没供电、ST-Link驱动异常 | 检查SWDIO/SWCLK和供电，重装驱动 |
| 虚拟COM口有叹号 | 串口驱动没装好 | 安装对应USB转串口驱动 |
遇到问题先分域排查：先看物理层，用示波器确认波形；再看协议层，确认波特率和ID；最后才怀疑软件逻辑。这个顺序能省下大量无用功。
4.4 几个能救命的小习惯
调试CAN通信一年下来，我发现几个非常实用的小习惯。第一，在程序里加上错误中断的处理，监控错误警告和bus-off状态。发送失败时及时读取CAN1->ESR寄存器，里面的LEC字段会告诉你上次错误的类型，是位错误、CRC错误还是应答错误，定位问题事半功倍。
第二，用CAN分析仪当第三个节点挂在总线上。它能看到所有报文和错误帧，还能模拟任意ID发数据，联调时非常方便。没有分析仪也可以先用USB转CAN工具，十几二十块钱的就行，能看原始帧就可以。
第三，发送失败后的处理逻辑一定要写。我见到很多新手调用发送函数，返回错误就丢弃不管了。CAN在强干扰环境下偶尔发送失败是正常的，如果开启动AutoRetransmission，硬件会自动重发；但如果你用的是不自动重传的配置，就要在软件里做重试或者记录错误计数，否则数据会悄悄丢。
第四，初始化完成后，先读取HAL_CAN_GetState，确认状态是READY再启动。如果初始化没完成就调用发送函数，会出现莫名其妙的现象。
最后再分享一个我自己的习惯：新板子到手，我一定先用回环模式把收发跑通，再接总线。越复杂的项目，越要先证明最小系统是好的。CAN通信这种事，协议层折腾半天发现是物理层一个电阻没焊，是最痛的经历。示波器就是你的眼睛，遇到问题不要猜，直接看波形，一步步缩小范围，问题总会浮出水面。
本文还有配套的精品资源，点击获取
