STM32串口通信详解：USART配置、中断DMA与调试排错

1. USART与UART的本质区别：为什么时钟配置决定一切

很多人第一次用STM32的串口时都会有个疑问：芯片手册上写着USART，代码里也到处是USART1、USART2，但有的教程又管它叫UART，这俩到底是不是一回事？

结论是：USART比UART多了一个“同步”能力。USART全称是Universal Synchronous/Asynchronous Receiver/Transmitter，注意中间有Synchronous这个词。也就是说，它在异步通信（就是我们最常用的串口收发）之外，还支持同步模式——可以向外输出一个时钟信号SCLK，配合收发数据线，去直接驱动某些SPI从设备，甚至支持LIN总线、智能卡ISO 7816协议、红外IrDA等扩展功能。而UART（Universal Asynchronous Receiver/Transmitter）只能做异步通信，没有时钟输出能力。STM32的芯片资源表里，标注为USART的外设支持完整功能，标注为UART的通常是精简版，只能走异步。比如STM32F103系列有USART1、USART2、USART3和UART4、UART5，后面两个名字上就叫UART，因为不对外提供SCLK时钟线。

绝大多数项目用到的都只是USART的异步模式，所以从使用上看，你完全可以把它当UART去理解。但差异引出了一个更重要的问题：异步通信最关键的是收发双方波特率一致，而这个波特率是怎么来的？答案是：由外设时钟分频而来。

USART的波特率生成器挂在APB外设总线上，它用一个分频计数器把外设时钟降到你想要的波特率。对于STM32F1来说，USART1挂载在APB2上，最大时钟是72MHz；USART2和USART3挂载在APB1上，最大时钟是36MHz。到了F4系列，APB1和APB2的整体时钟频率更高，但每个USART的具体挂载位置不同，分频配置也就有所差异。

这个“外设时钟源头”必须优先搞清楚。很多工程里，默认的时钟初始化代码用的是HSE外部晶振，但如果某次调试时你为了省事直接把系统时钟配置成了内部的HSI（比如某些电源管理场景），或者修改了PLL分频参数，串口波特率就会跟着漂移。我曾经遇到过一个很奇怪的现象：程序里明明配置的是9600波特率，但逻辑分析仪实测出来大概在9600到9700之间跳动，字与字之间间隔不稳定，上位机时而收到乱码时而收不到。最后定位到原因是客户板子上没有外接晶振，代码却默认用HSE，时钟初始化失败后系统跑在HSI的默认频率上，所有外设时钟全部偏离了预设值。

所以，配置USART之前，建议先把SystemClock_Config这个时钟初始化函数彻底确认一遍：外部晶振频率、PLL倍频系数、AHB/APB预分频。这也是我说“时钟配置决定一切”的原因——你调的是USART的参数，但实际管着波特率的，是它上游的时钟树。

2. 从零配置一个最小USART收发通道

2.1 配置流程梳理

在STM32的HAL库体系里，初始化一个USART的步骤可以拆成四步：

1. 使能USART外设时钟和对应GPIO口的时钟
2. 把TX、RX引脚配置成复用功能推挽模式
3. 填充UART_HandleTypeDef结构体并调用HAL_UART_Init
4. 启动外设，开始收发

第一步和第二步看似基础，但特别容易被忽略。很多新手会以为只要调用了HAL_UART_Init就算配置完了，结果发现程序里发出来的数据波形不对，或者是引脚电平始终没有翻转。实际上，GPIO如果不切到复用功能（Alternate Function）模式，它就是一个普通IO口，电平状态根本不受USART外设控制。

以最常见的STM32F103C8T6为例，USART1的TX在PA9，RX在PA10，对应的GPIO配置是这样的：

__HAL_RCC_USART1_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitTypeDef GPIO_InitStruct = {0}; GPIO_InitStruct.Pin = GPIO_PIN_9 | GPIO_PIN_10; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; // 复用推挽 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; // 高速模式 HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

注意，这里一个很容易踩的坑是TX和RX都配置成复用推挽了，但有些芯片的某些USART引脚在输入模式下需要配置成复用开漏。通用情况下，接收引脚在复用推挽模式下也能正常工作，因为输入功能并不受输出模式影响。我一般习惯性把RX也配成AF_PP，省事，但如果你的硬件设计上拉电阻有特殊需求，改成AF_OD也是合法的。

2.2 USART参数初始化

然后是最核心的HAL_UART_Init：

UART_HandleTypeDef huart1; huart1.Instance = USART1; huart1.Init.BaudRate = 115200; huart1.Init.WordLength = UART_WORDLENGTH_8B; huart1.Init.StopBits = UART_STOPBITS_1; huart1.Init.Parity = UART_PARITY_NONE; huart1.Init.Mode = UART_MODE_TX_RX; huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE; huart1.Init.OverSampling = UART_OVERSAMPLING_16; HAL_UART_Init(&huart1);

这里面几个参数值得细讲。

• 波特率：最常用的就是9600和115200。如果你的项目只在调试阶段用串口打印日志，115200没毛病；如果是和某些工控设备、传感器通信，一定先确认对方设备的默认波特率，别一上来就按自己的喜好配。
• 字长：串口协议里数据位一般有两种，8位和9位。8位最常见。如果你选择了9位数据位，再用奇偶校验，那校验位是包含在这9位里的，有效数据其实只有8位。这一点官方手册写得明白，但很多人在2Mbps和工业现场项目里因为位宽配置不对导致校验一直失败。
• 停止位：1位、1.5位、2位。1位是绝大多数场景的默认值。1.5位这个选项在常规异步帧格式里比较罕见，通常用在某些特定协议里，比如ISO 7816智能卡。
• 奇偶校验：None是常态。开了校验之后，每一帧会多一个校验位，波特率参数计算也会隐含变化。
• 硬件流控：RTS和CTS两根线。如果不用，一定配置成UART_HWCONTROL_NONE。有些开发板没有接流控引脚，但你如果在初始化里误开了，芯片会在真正发送数据前等待CTS信号，结果就是数据卡在缓冲区里发不出来，代码看着没问题，实际上一句话都发不出去。

配置完之后，调用HAL_UART_Transmit就能发数据，调用HAL_UART_Receive就能收数据，都是阻塞轮询模式。收发一个字节的使用方法：

uint8_t tx_buf[] = "Hello STM32\r\n"; HAL_UART_Transmit(&huart1, tx_buf, sizeof(tx_buf) - 1, 1000); uint8_t rx_byte = 0; HAL_UART_Receive(&huart1, &rx_byte, 1, HAL_MAX_DELAY);

2.3 为什么最小系统也要串口

进程里“S死神百态”，有“crowded marriage”《女性身体数据管理》，有各种意外嵌套和错乱的设定。但实际上串口几乎是每个嵌入式工程师最依赖的调试工具——它不需要仿真器，不需要复杂的IDE调试环境，只要一个USB转TTL模块，你就能看到程序运行的实时状态。加一行printf，你就能知道某个函数有没有被调用，某个变量值是多少。

也正因如此，我建议所有准备开始STM32项目的人都先搭一个“串口打印最小工程”：板子能跑、串口能输出、按键能触发、LED能闪烁。别一上来就研究各种外设的高级用法，先把这条底层的“调试生命线”打通。后面你写ADC、I2C、SPI、FreeRTOS的时候，全靠它反馈信息。

3. 收发效率进阶：中断与DMA的正确打开方式

3.1 轮询、中断、DMA怎么选

最简单的串口收发是轮询。但轮询有一个致命问题：阻塞。调用HAL_UART_Transmit时，如果缓冲区没发完，这个函数会一直占用CPU等待。如果你在主循环里轮询接收，更要命——在等待一个字节到来时，你几乎干不了别的活，除非你用了复杂的超时判断和状态机。

实际项目中，串口收发有三种常见方式：

低频的调试打印用轮询就够了。项目真正跑业务逻辑，建议接收用中断或DMA，发送根据数据量决定。

3.2 中断接收的核心：空闲中断

串口中断接收，最核心的技巧是“空闲中断”。什么叫空闲中断（IDLE）？就是串口在一段时间内没有收到新的起始帧时，硬件会在总线“空闲”的瞬间触发一个中断标志。这个特性特别适合用来判断“一帧数据接收结束”。

为什么这么说？因为串口本身是一个字节一个字节传的，没有专门的帧结束标志。而你从上位机发过来的数据往往是一整串，比如“AT+GMR\r\n”。如果只开接收中断，每个字节都会进一次中断，你必须自己判断这一串数据什么时候结束。最简单可靠的做法就是：把数据收进一个缓冲区，同时开启空闲中断，一旦总线长时间没有新数据，就认为这一帧收完了，然后去处理缓冲区里的完整数据。

这个思路在HAL库里的实现方式大概长这样：

uint8_t rx_buffer[256]; uint8_t rx_index = 0; uint8_t rx_complete_flag = 0; void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart->Instance == USART1) { rx_index = Size; rx_complete_flag = 1; } } // 主循环里先这样启动接收 HAL_UARTEx_ReceiveToIdle_IT(&huart1, rx_buffer, sizeof(rx_buffer));

HAL_UARTEx_ReceiveToIdle_IT这个函数是HAL库专门为“收到空闲就回调”设计的，它会在收到空闲中断时调用HAL_UARTEx_RxEventCallback，并且通过Size参数告诉你这一轮总共收到了多少字节。相比自己写中断服务函数手工清标志，这套封装省心很多。

用中断接收有一个容易被忽视的点：每次处理完一帧数据后，你必须重新调用一次接收函数，让它重新“上线”。否则中断被关掉了，下一批数据进来时你不会收到任何通知。

3.3 DMA接收与环形缓冲区

当数据量进一步增大，或者数据连续不断进来时，中断方式就显得有点奢侈了——每来一个字节CPU都要跳进中断函数，保存现场、恢复现场。DMA（Direct Memory Access）就是用来解放CPU的。

配置DMA接收的过程不复杂，HAL库封装得很好：

HAL_UART_Receive_DMA(&huart1, dma_rx_buf, DMA_BUFFER_SIZE);

数据会直接由DMA控制器从USART的数据寄存器搬到dma_rx_buf内存数组中，整个过程不需要CPU逐字节干预。CPU可以在主循环里做自己的事，等DMA传输完成的回调通知你“缓冲区满了”，再去取数据处理。

传统做法是DMA接收长度固定，收到指定数量字节后产生回调。但真实场景里我们往往不知道一帧数据有多长。所以更实用的方案是“DMA + 空闲中断”组合：用DMA在大内存缓冲区里持续搬运数据，用空闲中断来标记一帧数据的结束点。这个方案是工业级串口通信的常见标配，既能大流量收发，又能精确切分数据帧。

要注意的是DMA缓冲区的大小设置。如果你预期的单帧数据最大是128字节，缓冲区就不要设成64。缓冲区过小会导致数据被覆盖，而判断覆盖往往非常困难——因为你不知道丢的是哪一段。我一般设成预期的最大单帧长度的2倍，留足余量。

3.4 中断服务函数里别干重活

这是个老生常谈但总有人踩的坑：中断回调函数里千万不要做耗时操作，比如字符串处理、浮点运算、文件系统写入。中断里干活的时间越长，CPU响应其他中断的延迟就越大，对于串口这种实时性要求比较高的外设，很容易造成数据覆盖或者丢失。

正确做法是：在中断回调里只做标记，把数据标记为“已接收完成”，具体的解析和业务逻辑放到主循环里去处理。我见过有人把解析GPS协议的整套状态机直接写进了串口中断回调，结果一旦定位信号好、数据连续输出，程序卡死，主循环几乎不跑。这种问题排查起来非常隐蔽，因为从现象看像死机，但从仿真器看，CPU其实一直“活”在中断里。

4. printf重定向到USART的实用做法

4.1 原理与最小实现

几乎每个嵌入式工程师都想在STM32上直接用printf打印调试信息。要达成这个效果，关键在理解C标准库的printf在底层做了什么。

printf本身只是格式化函数，它最终如何输出，取决于底层你有没有提供一个字符输出接口。在ARM Keil MDK环境下，这个接口是fputc函数。所以最简单的重定向方法是自己重新实现fputc：

#include <stdio.h> int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; }

加了这个函数之后，你再调用printf("temp=%d\r\n", temp)，输出就会直接走USART1发送到电脑串口助手了。

但这里有几个细节，很多教程不会讲透：

第一，在MDK工程里，如果你没有勾选MicroLIB，连接器默认会把你链接到标准C库。标准C库的printf会调用_sys_open、_sys_write这些底层文件系统接口，如果你的工程里没有为这些接口提供实现，编译链接可能报错，运行时也可能因为半主机模式（Semihosting）而卡死。最直接的解法就是勾选“Use MicroLIB”（微库）。微库是ARM专门为嵌入式环境裁剪的C库，精简掉了文件系统等重组件，重定向fputc也更容易。

如果你不想用微库，那就得通过设置或者修改启动文件来禁用半主机模式。我当年第一次在这个坑里折腾了一个下午，最后老老实实勾了微库。只要你不是在做一个必须用完整标准库的项目，微库足够了。

第二，重定向之后，printf会因为缓存机制出现“第一次输出丢字符”或者“输出顺序不对”的情况。这是因为标准库的stdout默认有行缓存。解决办法是调用setvbuf(stdout, NULL, _IONBF, 0)关闭缓冲区，或者每次输出后强制fflush。在嵌入式环境里，这个问题的典型表现是：第一次调用printf，字符串没打印出来，第二次第三次又正常了，特别迷惑。我个人的做法是在USART初始化完成后直接调用一次setvbuf。

4.2 printf在中断和RTOS环境下的坑

上面的重定向是通用的，但一旦你的代码里既有中断又在调用printf，问题就来了。HAL_UART_Transmit是阻塞函数，而且内部会检查串口是否正忙。如果在某个中断里调用printf，恰好主循环也在调用printf，两个地方同时访问同一个串口，就可能导致数据交错或者丢失。这是老牌问题：共享外设并发访问。

解决思路有几个：

• 低级方案：全局关中断，打印前关闭IRQ，打印后恢复。简单但粗暴，会拉长中断响应时间。
• 简单方案：用一个互斥锁或者临界区保护整个printf调用。
• 推荐方案：在RTOS环境下，为串口打印加一个互斥锁，并且把打印放到专门的线程里执行。如果不用RTOS，就用一个简单的“忙标志”来判断：主循环打印时如果接收到串口中断，中断里只往一个共享的环形缓冲区写数据，主循环再统一处理，避免两个上下文同时访问UART寄存器。

我踩过一次比较深的坑：在FreeRTOS的一个任务里用printf打印调试信息，另一个更高优先级任务会偶尔调用printf，结果两边交替往一个DMA缓冲区写数据，DMA发送指针错乱，串口输出成了一堆随机字节。后来我把所有printf包在一个互斥锁里，才彻底稳定下来。

4.3 printf只能发不能收怎么办

有些时候你还想和上位机做交互：上位机发一个“on”，下位机回一句“ack”。printf只能解决下行的格式化输出，上行数据得靠串口接收。所以在项目里，我倾向于把printf当作“单向调试日志工具”，它主要负责输出系统状态；真正的指令交互、协议通信，走独立的串口接收解析流程。

这样划分的好处是把“调试”和“业务”解耦。调试日志打印得多繁重都不影响协议解析的稳定性，协议解析坏了也不会让整个日志系统塞满垃圾数据。

5. 高级场景实战：协议帧、RS485与低功耗唤醒

5.1 设计一个可靠的帧协议

串口通信最经典的问题不是“怎么收发数据”，而是“这一串字节到底是什么意思”。如果你只是上位机发“1”下位机亮灯，那无所谓；但一旦字段变多，比如指令包含设备地址、功能码、数据长度、数据区、校验码，你就必须设计帧协议。

一个最小可用的帧格式建议包含以下部分：

帧头的作用是“同步”。数据从中间开始接收时，你能通过寻找连续的两个0xAA 0x55找回帧的起点。

校验一般用累加和或者CRC。累加和实现简单，适合速率不高的场景；CRC16虽然实现复杂一点点，但抗干扰能力强很多。如果通信链路长且环境复杂（比如工业现场），我更推荐CRC16。

5.2 接收状态机的一个标准模板

解析帧协议最常见的错误做法是：收到一个字节就判断是不是帧头，收齐了再一次性判断。但如果不加状态机，很容易在“帧头丢失”“长度字段出错”时彻底卡死。

我推荐用状态机，状态切换逻辑大概这样：

typedef enum { FRAME_WAIT_HEAD1, FRAME_WAIT_HEAD2, FRAME_WAIT_CMD, FRAME_WAIT_LEN, FRAME_WAIT_DATA, FRAME_WAIT_CRC } Frame_State; Frame_State state = FRAME_WAIT_HEAD1;

每收到一个字节就switch一次状态。如果某一步校验失败，直接回到WAIT_HEAD1，重新寻找帧头。这样网络中的噪声、乱码、丢字节，都不会把解析器搞瘫痪。

这个状态机的代码看起来简单，但要在中断回调里做，就要注意一个问题：不要在主循环里处理这堆逻辑的时候把下一个字节漏了。所以正确姿势是中断里只管把字节塞进环形缓冲区，状态机在主循环里从缓冲区逐字节取出并解析。缓冲区的读写可以用最简单的读索引和写索引维护，在单片机上实现环形缓冲区不算难，网上模板也很多，我这里就不贴整套代码了。

5.3 RS485的方向切换，最后一步容易翻车

RS485是工业现场最常见的串口总线形式。它的电气特性和普通TTL串口不同，差分信号抗干扰强，通信距离可以达到上千米，但它的硬件上有一个方向控制问题：收发器通常有DE和RE引脚，需要你控制它是发送模式还是接收模式。

控制策略很简单：发送前拉高DE，发送完拉低DE，回到接收状态。但关键问题在于“发送完”的时机。很多人写完HAL_UART_Transmit之后就立刻把DE拉低，结果最后一个字节发了一半就被硬件掐断了。因为HAL_UART_Transmit返回时，串口数据寄存器可能已经清空，但移位寄存器里可能还在往外送最后一个字节。正确做法是等“发送完”的标志位，或者统计发送完成中断，确认移位寄存器彻底空了之后再拉低DE。

在HAL库里，你可以用HAL_UART_GetState和HAL_UART_TxCpltCallback来判断，或者干脆用HAL_UART_AbortTransmit_IT等待发送完成。这个坑是RS485通信最常见的翻车点，我见过好几个工程师调了一整天，逻辑上怎么都找不出错，最后发现就是这“最后一个字节”。

5.4 低功耗场景下的USART唤醒

如果你的设备是电池供电的，平时需要进入STOP模式省电，但还想让串口在收到唤醒命令时恢复工作，STM32的USART支持从STOP模式唤醒的机制。原理很简单：USART接口在检测到RX引脚上一个有效的起始位时，产生一个唤醒事件，把MCU从STOP模式拉回正常运行。

但这种用法有个坑：唤醒后，芯片时钟需要一段时间重新稳定，而USART波特率生成器依赖的时钟如果尚未稳定，接收到的第一个字节可能是乱的。所以很多低功耗产品的设计是“唤醒字节不算数据”，它只负责把系统唤醒，真正的业务数据从第二个字节开始接收。

我建议实现上分两层：低功耗唤醒由USART的唤醒事件完成，唤醒之后主循环再重新初始化USART接收。或者更稳妥的方案是唤醒后加一个小的软件延时（比如等待时钟源稳定），然后主动丢弃接收缓冲区里的脏数据，再开始正常通信。

6. 真实项目中的串口排错经验

6.1 波特率误差是怎么算出来的

如果你用的上位机工具显示数据乱码，第一反应通常是“波特率不对”。但你可能不知道，串口通信允许一定范围的波特率误差，只要收发双方的误差控制在容忍范围内，通信就能正常工作。

USART波特率的计算过程就是外设时钟除以分频系数，分频系数是整数和小数的组合。比如STM32F1系列，如果系统时钟72MHz，配置成115200波特率，实际生成的波特率是多少？用工具算了之后你会发现误差很小，约0.02%。这种误差远在允许范围内。

但如果你的系统时钟来源不是标准频率，比如用HSI调出来的频率是64MHz而非72MHz，误差就可能爬到2%、3%，这时通信大概率出问题。解决办法有两种：换一个能“整除”的波特率，或者使用外置高精度晶振。手工计算分频系数不现实，CubeMX里配置完时钟树后，点一下UART配置页面，它会直接提示实际生成的波特率是多少，这个数值要仔细看一眼。

6.2 引脚冲突与重映射

STM32的引脚复用非常多，同一个外设可以用到好几组不同的引脚上。比如USART1可以是PA9/PA10，也可以是PB6/PB7。这就带来了一个经典问题：别的外设把引脚占了。

我遇到过一次特别费时间的排查：客户程序里开了USART1，但调试时发现TX引脚的电平始终不动，查了引脚配置、时钟、波特率都没问题，最后才发现PB6/PB7被一个I2C外设占了，初始化的代码里把复用关系搞乱了。这种情况下，用逻辑分析仪看引脚电平是最快的——你会发现发送时一个被占用的引脚上根本没波形。

用CubeMX的好处就是它能直观地提示冲突。如果你手写寄存器初始化，最好对一下芯片数据手册的引脚复用表，别想当然。

6.3 中断优先级：为什么偶尔丢数据

有些时候串口通信看起来正常，但在特定操作（比如按下某个按键）时就会丢一两个字节。排查到后面发现，串口的中断优先级太低，被其他外设的长时间中断抢占。数据寄存器里新到的字节没来得及读走，下一个字节又到了，覆盖寄存器，硬件置溢出错误位，数据直接丢失。

解决方法是把串口中断优先级适当调高，尤其是接收中断。但也不能调到最高，否则它可能会打断其他更紧急的中断。这里没有银弹，需要根绝项目的实时性需求去平衡。

另外特别提醒一下：如果开了串口接收中断但没有处理溢出中断，一旦发生溢出，串口接收功能可能永久性卡死。在中断回调里，除了常规的数据接收处理，最好加一个对ORE（Overrun Error）标志的检查和清除，防止“偶发一次丢字节就再也收不到数据”的诡异现象。

6.4 硬件层面的几个实用建议

串口通信不稳定，有时候不是软件问题，是硬件设计问题。

• 电平匹配：STM32的IO是3.3V逻辑，如果你的外部设备是5V逻辑，特别是工业串口设备，中间一定要加电平转换芯片，不能直连。运气好能跑，但长时间工作随时可能打死IO口。
• 耦合电容：在串口线靠近MCU端可以加一个小电容（比如100pF）抑制高频噪声，但别加太大，否则会把信号边沿拉平，导致波特率高的场景下误码。
• ESD防护：在工业环境或者需要经常插拔串口的场合，串口引脚上最好加TVS管或者ESD保护二极管，这些小元件能救回你的板子。
• 共地问题：两个设备用串口直连，必须共地。如果两边电源不共地，可能会通过串口形成地环路，轻则通信乱码，重则损坏IO。长距离通信更推荐用RS485或者隔离串口。

6.5 调试工具的用法心得

串口调试助手人人都用，但真正高效的调试方法是：先用“自发自收”——把TXRX短接，看看MCU发出的数据能不能原样收回来。如果能收到，说明USART硬件通路没问题；如果收不到，问题在初始化侧。第二步再用USB转TTL接电脑，配合上位机看波形或者数据分析工具，确认上位机收到的字节有没有错乱。

有条件的话，逻辑分析仪在这种排错场景下价值极高。它能看到每一个字节的时序、波特率是否准确、发送间隙是否正常，比在代码里加打印信息高效得多。现在的逻辑分析仪很便宜，百元左右就能买到好用的，建议每个嵌入式工程师都备一个。

踩过这么多次坑之后，我的体会是：串口通信的问题，80%出在时钟、引脚、中断和硬件底子上，而不是数据解析逻辑。先把物理层跑通，再去纠结协议问题，排查效率会高很多。这也是这篇文章花了大量篇幅讲基础配置的原因——那些看起来最不起眼的参数，往往是整个项目里最隐蔽的陷阱。