简介：STM32串口通信入门与调试的完整工程示例，基于正点原子mini板与精英板实现双机USART3对接：mini板通过PB10/PB11发送数据，精英板接收后经USART1转发至串口调试助手，并同步驱动LCD屏显示接收内容。代码已调通可直接运行，板载LED给出收发状态反馈——串口3接收成功时LED10翻转，串口1发送成功时LED1翻转，便于快速验证链路。资源共321个文件，涵盖Keil工程配置（.uvprojx/.uvoptx）、.c源文件与.h头文件、.hex烧写文件、.axf调试文件及编译中间产物等，压缩包约7.35MB，目录完整便于查阅。已有4398人学习下载，使用上也很灵活：没有mini板时可用另一台电脑的串口助手模拟发送；没有LCD时注释掉相关初始化即可。整体覆盖STM32串口收发、终端打印和显示验证环节，适合嵌入式初学者快速上手串口通信实验。
1. 两块STM32对话，为什么第一步就卡在串口上
串口是嵌入式开发里最“皮实”的通信方式之一，但“STM32之间的串口通信”这个话题，恰恰是很多开发者第一次接触多机系统时翻车的重灾区。你可能会遇到这样的情况：两块开发板明明连好了线，A板发送的数据B板就是收不到，或者收到的全是乱码，跟网上的教程对着抄了三遍还是不行。问题往往不是出在代码逻辑上，而是出在硬件连接、电平匹配、波特率误差这些“看似不用管”的细节上。
这篇文章的价值在于帮你把两块STM32之间的串口通信从接线到收发、再到调试排错完整走通。不管是做双机数据交换、主从控制，还是把一个传感器模块的数据转发给另一个处理器，这套方案都适用。适合刚接触多机通信的初学者，也适合想梳理一下UART边界问题的从业者。看完之后你能明白：为什么串口通信“简单”但容易出诡异问题，以及用什么手段可以把这些“玄学”问题变成可排查的确定性问题。
2. 串口通信的底层逻辑与硬件连接：为什么交叉连接总是被忽略
2.1 全双工异步通信的真正含义
STM32的USART（通用同步异步收发器）在异步模式下，通信双方各自维护自己的时钟，不需要额外的时钟线。发送端在TX引脚上按约定的波特率逐位把数据“推”出去，接收端在RX引脚上按同一个波特率去采样。这里的核心协议是空闲状态为高电平、起始位为低电平、数据位低位在前，这些细节决定了双方必须对波特率、数据位、停止位达成一致。
“异步”意味着收发两端各自用内部时钟来采样，而不是像I2C或SPI那样由主机提供时钟。这个特性带来一个实际问题：两边的波特率必须足够接近。如果A板用8MHz外部晶振、B板用HSI内部时钟，两边即使都配置成9600bps，实际的波特率误差也可能相差百分之几，数据量一大会出现偶发错位，表现就是“时好时坏”的乱码。新手最容易忽略的正是这一点：波特率不是写个数值那么简单，它依赖时钟源的精度的。
硬件连接上，全双工意味着需要两根数据线：A板的TX接B板的RX，B板的TX接A板的RX。有些初学者会“理所当然”地把两边的TX接TX、RX接RX，结果收不到任何数据。还有一点需要注意的是共地，两块板子的GND必须连在一起，否则电平基准不同，接收端采样到的信号会飘，甚至会损坏引脚。
2.2 电平标准与板间通信的选型
STM32的串口引脚输出的是TTL电平（0~3.3V），所以两块STM32之间直接连接是没问题的，不需要加MAX232或RS485收发器。这里有两个容易踩的坑。
第一个坑是电平转换。如果其中一端是5V的单片机或老式设备，要注意STM32的引脚是否容忍5V输入。查数据手册里引脚的FT（Five-volt Tolerant）标记，不是所有引脚都能直接接5V。两块STM32之间不存在这个问题，但如果你的系统里混入了其他设备，一定要先确认电平标准。
第二个坑是长距离通信。直接TTL连接在几十厘米内没问题，线长超过一米或者经过电机、继电器等干扰源附近，通信就会变得不稳定。这时候常见做法是用RS232或RS485收发器转成差分信号。对于“STM32之间”的场景，如果你只是桌面调试，杜邦线直连就好；如果是两个分体设备之间的数据链路，优先考虑RS485方案。
2.3 最小硬件接线与验证方法
接线实际上非常简单，我一般会推荐下面的标准方式：
STM32-A PA9 (TX) -> STM32-B PA10 (RX) STM32-A PA10 (RX) -> STM32-B PA9 (TX) STM32-A GND -> STM32-B GND用两块常见的STM32F103C8T6开发板实验时，PA9/PA10是USART1的默认引脚。需要注意：如果你把代码里的引脚改成了PB6/PB7（USART1的重映射），接线也得跟着改，不能照着默认引脚图来。
接好线后不要急着写收发逻辑，先做一个“回环测试”：把A板的TX直接短接到它自己的RX，然后发送一个字节看是否能在同一块板上收到。回环通了说明USART外设本身工作正常，再接双板测试时就能把问题范围缩小到线序或电平上。这个习惯能帮你节省大量排查时间，别嫌麻烦。
3. 初始化与收发实现：把波特率和中断边界一次说清
3.1 标准初始化代码：为什么寄存器写法更适合排错
工程上用标准外设库或HAL库的都有，但如果你正在排查一个诡异的通信问题，我建议先用寄存器方式写一个最小初始化，这能帮你确认USART外设本身是否工作。下面是一份在STM32F103上可用的USART1初始化代码：
#include "stm32f10x.h" void USART1_Init(uint32_t baudrate) { GPIO_InitTypeDef GPIO_InitStructure; USART_InitTypeDef USART_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_USART1, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9; // TX GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10; // RX GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &GPIO_InitStructure); USART_InitStructure.USART_BaudRate = baudrate; USART_InitStructure.USART_WordLength = USART_WordLength_8b; USART_InitStructure.USART_StopBits = USART_StopBits_1; USART_InitStructure.USART_Parity = USART_Parity_No; USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx; USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None; USART_Init(USART1, &USART_InitStructure); USART_Cmd(USART1, ENABLE); }这段代码把PA9配成复用推挽输出（TX），PA10配成浮空输入（RX）。注意RX引脚不要配成上拉输入，因为USART引脚在空闲状态下是高电平，浮空输入依赖外部信号驱动，配成上拉反而可能在调试时掩盖电平问题。波特率通过传入参数设置，这样可以写一个统一的初始化入口，在main里分别对两块板子调用不同数值也方便。
参数方面建议固定使用8数据位、无校验、1停止位，也就是常说的8N1。不要为了“看起来更严谨”去开硬件流控或校验位，对初学者来说这些增加的是出错概率而不是可靠性。通信双方必须完全一致地配置这些参数，任何一处不一致都表现为“收到乱码”或“完全无响应”。
3.2 轮询发送与阻塞式接收：先跑通再优化
初始化做好了，先用最简单的轮询方式发一个字节和一个字符串：
void USART1_SendByte(uint8_t ch) { USART_SendData(USART1, ch); while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); } void USART1_SendString(char *str) { while (*str) { USART1_SendByte((uint8_t)*str++); } }发送的要点是等待TXE标志位。TXE置位代表发送数据寄存器已空，可以写入下一个字节。不要只调用USART_SendData就立刻写下一个数据，否则会丢数据。接收端用查询方式代码对称：
uint8_t USART1_ReceiveByte(void) { while (USART_GetFlagStatus(USART1, USART_FLAG_RXNE) == RESET); return (uint8_t)USART_ReceiveData(USART1); }这里有一个常见的误用：有些人在读USART_ReceiveData之前没有等待RXNE标志，或者连续调用两次接收函数。前一个错误会读到未就绪的数据，后一个错误会把有效数据消耗掉。接收函数返回后，RXNE标志会自动清除，这个行为在不同系列芯片上一致，但如果你用HAL库，它内部还会处理错误标志，行为稍有不同。
用轮询方式跑通以后，再考虑中断或DMA。轮询的劣势是多任务场景下会阻塞CPU，如果两块STM32之间还有别的任务要跑，轮询接收会把其他任务的实时性拖垮。但作为验证手段，轮询是最直观的——你现在每一步都能看到结果，排错成本最低。
3.3 中断方式接收：帧边界才是关键
大多数实际项目里用的是中断接收，因为这样CPU可以在没有串口数据时去做别的事。下面是一段在中断服务函数里接收一帧数据的逻辑：
#define FRAME_MAX_LEN 64 volatile uint8_t rx_buffer[FRAME_MAX_LEN]; volatile uint8_t rx_len = 0; volatile uint8_t frame_ready = 0; void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) { uint8_t ch = (uint8_t)USART_ReceiveData(USART1); if (rx_len < FRAME_MAX_LEN) { rx_buffer[rx_len++] = ch; } } }这段代码只解决了“收到字节往缓冲区里放”的问题，没有解决“什么时候算一帧结束”。这是串口编程里真正体现经验的地方。常见的分帧方式有两种：固定长度帧（约定好每帧N个字节，收满N个就处理）和帧头帧尾（约定帧头0xAA、帧尾0x55或CRC校验）。固定长度帧代码简单，但协议扩展性差；帧头帧尾更灵活，但要处理粘包和半包问题。
我见过不少开发者在中断里写复杂的解析逻辑，甚至跑CRC和状态机。这不是不可以，但中断服务函数里应该尽量只做数据搬运，解析留给主循环。中断里执行时间过长，会丢失后续字节，尤其是高波特率下，这是中断接收“翻车”的主要来源之一。如果你的波特率超过115200，建议用DMA接收。
3.4 双机收发的一个最小可跑示例
把上面几段拼起来，可以形成一块板子发送、另一块板子接收的闭环。A板每秒发送“Hello STM32”，B板在收到完整字符串后在主循环里做判断。最简单的协议可以定义为一个结束符：
// A板发送端 while (1) { USART1_SendString("AT+OK\r\n"); Delay_ms(1000); } // B板接收端 volatile uint8_t line_buffer[32]; volatile uint8_t line_pos = 0; volatile uint8_t line_ready = 0; void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) { uint8_t ch = USART_ReceiveData(USART1); if (ch == '\n') { line_buffer[line_pos] = '\0'; line_pos = 0; line_ready = 1; } else if (line_pos < 31) { line_buffer[line_pos++] = ch; } } } // 主循环消费 if (line_ready) { // 比较 line_buffer 内容 line_ready = 0; }用换行符做帧结束标记，简单直接。注意在处理完line_ready之后必须手动清零，否则会重复处理同一帧数据。另外，要区分“接收缓冲区溢出”和“帧体过长”两种情况，上面代码用数组上限做保护，实际项目里建议在协议层设计帧长度字段，避免依赖固定数组大小。
4. 参数调优与调试手段：从串口助手到逻辑分析仪的分级排查
4.1 波特率、时钟源和误差的三角关系
串口通信的稳定性本质上是波特率误差问题。STM32的USART波特率由APB时钟和分频系数决定，任何一个环节的时钟配置不同，都会影响实际波特率。以F103为例，USART1挂载在APB2上，最高72MHz；USART2/3挂载在APB1上，最高36MHz。如果你在USART2上配了一个需要超过36MHz时钟的波特率，分频结果会有较大误差。
从经验来看，9600和115200这两个波特率用的最多。9600的抗干扰能力强，适合长线和干扰环境；115200是性能和速度的折中，是大多数调试工具的默认档位。超过460800后，杜邦线和板上的走线质量会成为瓶颈，通信稳定性急剧下降，一般不建议在非PCB环境下使用。
排查波特率问题时，先用示波器或逻辑分析仪抓TX引脚的波形，测量一个字节的实际位宽。比如配置9600波特率时，一位的理论宽度约104.2微秒，实测偏离太多就说明时钟配置有问题。没有示波器的话，可以在发送端主动发一个0x55（二进制01010101），这个字节的波形是规整的方波，最容易肉眼判断。
4.2 串口助手看到的乱码，问题不一定在代码
双机通信调试时，你的第一反应可能是把A板的TX接到USB转TTL模块上看数据。这个操作很常用，但也要注意：USB转TTL模块的电平和目标板是否一致，模块的RX/TX是否与板子的TX/RX交叉连接，以及模块的地线是否和目标板共地。
有一个非常容易忽略的细节是：某些USB转TTL模块上电瞬间会拉低TX脚，如果目标板已经通过串口接收并正在等待起始位，这个毛刺会被当成一个字节接收。表现是上电瞬间收到一个0x00或0xFF的干扰字节。这在双机通信里也会出现：A板上电瞬间，TX引脚的电平不稳定，B板可能先收到一个脏字节。解决手段要么是加一个延时让电压稳定后再开始通信，要么是在协议层做校验丢弃无效帧。
4.3 用逻辑分析仪替代“盲调”
很多嵌入式开发者的调试工具还停留在“串口助手看打印”阶段，但双机通信这种问题，逻辑分析仪几乎是必备工具。一个几十块钱的8通道逻辑分析仪，配合开源软件，就能抓取两条信号线上的全部数据。
抓包的正确姿势是这样的：把逻辑分析仪的通道0接A板的TX，通道1接B板的TX（也就是A板的RX）。同时抓这两根线，你就能看到通信的全过程。如果A板发了数据但B板没反应，看波形能立刻判断是B板根本没收到，还是收到了但解析出错。
协议解析层面，逻辑分析仪软件通常自带UART解码器。设置好波特率后，软件会直接显示解析出的十六进制数据，你只需要对比发送端发出的值和接收端解析出的值是否一致。这个工具能把“为什么收不到”和“为什么乱码”这两类问题迅速分开，省去大量盲猜时间。
4.4 打印日志的最佳实践：加时间戳比加废话有用
串口调试说白了就是在通信链路上插入“观察点”。我见过很多人喜欢打印“AAAA”“BBBB”这种没有信息的调试信息，除了确认程序跑到了某个分支，对排查通信问题毫无帮助。更有效的做法是打印带时间戳的收发记录：
// 伪代码：在接收中断里记录字节到达的间隔 printf("[%lu] RX: 0x%02X\r\n", get_tick_ms(), ch);时间戳能告诉你两件关键信息：一是字节之间的间隔是否均匀，如果间隔忽大忽小，说明发送方的调度有问题；二是两帧之间的间隔是否符合设计，如果帧间隔过短，说明接收端可能有缓冲区覆盖的风险。用printf做串口日志时要注意，printf本身也是走串口的，如果你在接收中断里调printf打印，会干扰通信时序，尤其是高波特率下，日志输出本身就可能导致丢数据。
建议的做法是把日志信息和通信数据分开走两个串口，比如USART1做数据通信，USART2做调试日志。但这种奢侈的配置不是所有板子都有，退一步的做法是在主循环里统一打印日志，中断里只设置标志位，绝不在中断里格式化输出。
5. 双机通信避坑指南：六个反复出现的翻车现场
5.1 现象：两个板子都是新的，照着教程接线但完全没反应
原因排查起来其实不复杂。最常见的原因是线序交叉错误，TX接TX、RX接RX。虽然这个错误听起来很基础，但实际的高发频率远超想象，尤其是当你用了一根“看起来像是直连”的杜邦线，而它其实是交叉线时。另一个常见原因是开发板上的串口引脚和板载调试器有冲突，比如某些板子的PA9/PA10默认被板载ST-Link或CH340占用，你外接的线根本没有连到MCU引脚上。
解决方法是先做章节2.3提到的回环测试。把PA9短接到PA10，发送一个字节，看是否能在同一个板子上收到。回环通了，说明代码和引脚配置没问题，问题在外部接线。回环不通，则先检查引脚初始化代码是不是跑在USART1上。注意有些开发板的调试器串口和用户的USART1共用引脚，需要拨码开关或跳线切换。
5.2 现象：波特率明明设置的一样，收到的数据总是缺字节或多字节
这个现象最容易让人怀疑人生。双方都配置了115200，但发10个字节对方只收到8个，或者偶尔收到11个。问题通常出在时钟源上。板子A用了外部晶振（精确），板子B用了内部RC（误差可达1%~2%），两者的实际波特率偏差超出了UART的容错范围。UART采样理论上容错约3%~4%，但在帧连续发送的场景下，误差会累积导致帧错位。
解决方法是检查两块板子的时钟配置。用逻辑分析仪测一下每块板子的TX引脚的实际位宽，对比理论值。如果误差超过2%，换用更精确的时钟源，或者在代码里调整USART分频寄存器。还有一个隐蔽坑是库函数配置里的prescaler没改，比如某些代码从别的型号移植过来，RCC配置不匹配。
5.3 现象：单独测试都正常，两台设备一接上就出现周期性乱码
这种情况首先要怀疑电源问题。两块板子用同一个USB口供电时，A板的电机或继电器一动作，B板复位的例子并不少见；两块板子用两个USB口供电时，共地不良或地环路导致电平漂移也很常见。其次要怀疑发送端和接收端的“行为竞争”——比如A板在主循环里不断发送，B板的中断处理来不及清RXNE，导致溢出错误标志置位，后续数据全部丢失。
解决的路径是让接收端主动丢弃脏数据，并在USART初始化时打开溢出中断，在中断服务函数里及时清除ORE标志，不要让错误标志卡死接收流程。双板通信时建议给每块板子独立稳压供电，GND之间用粗线或短直线连接，必要时加磁珠滤除高频干扰。
5.4 现象：帧头正确但帧尾数据偶发错误
这是协议层问题，典型原因是接收缓冲区处理太慢。中断里把收到的字节塞进缓冲区后，主循环没来得及处理，缓冲区满了之后新的数据被丢弃。如果帧头恰好是空的，下一次解析就会把不完整的数据当成完整帧。
另一个原因是帧头帧尾定义得太短。比如帧头0xAA，数据体里恰好也有0xAA，接收端遇到帧头就重置接收位置，把正常数据打断了。解决方法是协议里加转义或使用长度字段，不要让解析器靠“找帧头”来确定帧边界。更稳妥的做法是：第一位放帧头，第二位放帧长度，后面跟数据体，最后放CRC或累加和。帧长度固定之后，接收端先收长度，再按长度收完整个帧，不需要依赖帧尾判断结束。
5.5 现象：代码逻辑正确，把波特率调高之后就丢失数据
这个现象在115200到230400之间比较典型。中断接收模式下，CPU处理中断和解析数据需要时间，如果波特率太高，在接收中断里做大量工作就会导致下一个字节到来时RXNE还没被处理，数据被覆盖。核心瓶颈在“中断服务函数执行时间”和“两个字节到达间隔”的竞争。
解决手段是提升到DMA接收，让外设直接把数据搬进内存，CPU只在DMA传输完成时收到一次中断。另一个做法是降低中断优先级或其他中断对CPU的抢占频率。如果非要在大波特率下用中断接收，就只能精简中断处理，只做数据搬运，解析全部丢到主循环。一句经验：中断里只放“搬数据”的代码，绝不放“处理数据”的代码。
5.6 现象：接上两块板子的地线后，通信正常了，但系统不稳定
这个问题出现在双电源供电时。两块板子的GND之间用一根细杜邦线连接，信号线上有电流流过时，GND线上的压降会让接收端的信号基准漂移。通信“基本正常”但偶尔出错，多半是共地不良。
处理方式是加粗地线，用多个地线触点并联，或者用铜排排线把两边的GND连起来。更彻底的做法是在通信线上加光耦隔离，让两块板子的电源域彻底分开。这个方案在工业场合很常见，但对实验环境来说，优先做好共地即可。双板之间的压差如果超过一定范围，单片机的引脚会通过内部保护二极管承受电流，时间一长会烧引脚，这一点需要警惕。
6. 从可靠到高效：DMA收发和帧协议设计让双机通信上一个台阶
用中断接收跑通双机通信只是第一步，真正在项目里落地，需要考虑两件事：收发效率和协议健壮性。DMA是解决“高波特率下丢数据”的标准方案，而帧协议是解决“通信干扰下错数据”的关键手段。
DMA接收的思路很简单：配置UART的RX引脚连接到DMA通道，数据字节到达时由DMA自动写入内存缓冲区，CPU完全不用参与。等接收完一帧，DMA传输完成中断通知CPU处理。下面是一段基于STM32标准外设库的DMA接收初始化示例：
#define RX_BUF_SIZE 128 uint8_t dma_rx_buf[RX_BUF_SIZE]; void USART1_DMA_Init(void) { DMA_InitTypeDef DMA_InitStructure; RCC_AHBPeriphClockCmd(RCC_AHBPeriph_DMA1, ENABLE); DMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)&USART1->DR; DMA_InitStructure.DMA_MemoryBaseAddr = (uint32_t)dma_rx_buf; DMA_InitStructure.DMA_DIR = DMA_DIR_PeripheralSRC; DMA_InitStructure.DMA_BufferSize = RX_BUF_SIZE; DMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable; DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable; DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Byte; DMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Byte; DMA_InitStructure.DMA_Mode = DMA_Mode_Circular; DMA_InitStructure.DMA_Priority = DMA_Priority_High; DMA_InitStructure.DMA_M2M = DMA_M2M_Disable; DMA_Init(DMA1_Channel5, &DMA_InitStructure); DMA_Cmd(DMA1_Channel5, ENABLE); USART_DMACmd(USART1, USART_DMAReq_Rx, ENABLE); }这里的关键是DMA_Mode_Circular，循环模式下DMA会自己回绕，缓冲区始终在接收。你需要记录数据写到了哪个位置，这通过DMA_GetCurrDataCounter获取当前剩余计数来推算。处理完一帧数据后，清一下标志位，缓冲区可以继续使用。注意DMA中断和UART中断是两回事，DMA配置的是DMA通道的中断，UART溢出错误仍然要靠UART的ORE标志判断，两者都要初始化。
DMA发送的逻辑类似，直接把内存里的数据交给DMA往外发，发送完成中断可以用于判断一帧是否发完。这样做的好处是CPU可以在DMA搬运数据的同时去做协议解析或状态管理，不需要每个字节进一次中断。
帧协议是DMA之外另一个需要提前设计的点。一个实用的小型帧格式可以是：
| 帧头(1) | 长度(1) | 数据(N) | 累加和(1) | | 0xA5 | N | ... | SUM |接收端读到0xA5后，再读长度字节，随后连续接收N个数据字节，最后验算累加和。累加和用所有数据字节的加和低8位即可，够用且实现成本极低。不要一开始就上CRC32，在小数据量的双机通信里，累加和已经能拦截绝大多数偶发错误。
最后一个习惯值得养成：每次改协议、换接线、调波特率之后，用逻辑分析仪抓一次完整的帧波形并存图。后续如果再出问题，翻对比图比翻聊天记录高效得多。我自己的习惯是有一张“踩坑记录表”，每次遇到诡异问题就记一行，包括现象、环境、根因、解决手段。半年之后再遇到串口问题，拿出这张表对照一遍，很多问题在十分钟内就能定位。希望这篇笔记能帮你少走这些弯路。
本文还有配套的精品资源，点击获取
