STM32 HAL库串口重定向printf：从阻塞到DMA的实战优化-平芜编程栈

1. 项目缘起：为什么我们需要串口重定向printf？

在嵌入式开发，尤其是STM32这类MCU的项目中，调试信息的输出是贯穿整个开发周期的生命线。早期，我们可能依赖点灯大法，或者通过串口发送特定的十六进制数据包，再在PC端用串口助手解析，过程繁琐且效率低下。后来，大家发现如果能像在PC上写C程序一样，直接使用printf函数将变量、字符串格式化输出到串口，那将是多么惬意的一件事。这就是“串口重定向printf”的核心诉求：将标准C库的printf函数输出流，从默认的控制台（对于嵌入式系统通常不存在）重定向到我们指定的硬件串口上。

然而，理想很丰满，现实却需要自己铺路。STM32的标准外设库（Standard Peripheral Library）时代，重定向需要改写fputc等底层函数，虽然步骤固定，但每次新建工程都得手动操作一遍。到了HAL库（Hardware Abstraction Layer）成为ST主推的开发方式后，底层硬件操作被进一步封装，重定向的“接口”看似更清晰，但实际配置中却藏着不少细节，比如中断与轮询模式的选择、HAL库自身的机制理解不透彻导致的发送卡死、以及如何兼顾效率与稳定性等。

网上教程很多，但往往只给代码片段，缺了“为什么这么做”的上下文，更缺少实际项目中的踩坑经验。今天，我就结合自己多年在STM32 HAL库项目中的实战，从头到尾拆解如何实现稳定、可靠的串口数据发送与printf重定向，并分享那些教程里不会写的“坑点”和优化技巧。

2. 工程创建与串口外设基础配置

在开始写代码之前，正确的工程配置是成功的基石。这里我以STM32CubeIDE（ST官方免费工具）和一款常见的STM32F103C8T6核心板为例，但原理适用于所有STM32系列。

2.1 使用STM32CubeMX进行图形化初始化

虽然可以直接写代码配置，但我强烈建议，尤其是初学者，从STM32CubeMX开始。它不仅能生成初始化代码，更能帮你可视化地理解时钟树和外设引脚分配，避免低级错误。

芯片选择与工程创建：在CubeMX中选择你的目标芯片（如STM32F103C8），创建一个新工程。系统会提示你是否初始化所有外设为默认模式，选择“是”可以快速进入。
配置系统时钟（SYS）：在SYS调试部分，将Debug设置为Serial Wire。这非常重要，它不仅启用了SWD下载调试接口，也释放了被JTAG占用的某些引脚（如PA13, PA14），避免与你的串口引脚冲突。很多新手发现串口没输出，第一步就该检查这里。
配置时钟树（RCC）：根据你的硬件晶振，配置系统时钟。对于F103，通常使用8MHz外部高速晶振（HSE），然后通过PLL倍频到72MHz。在时钟配置图中，确保HCLK（系统时钟）达到你期望的频率。稳定的时钟是串口波特率准确的基础。
配置串口（USART）：在左侧外设列表中找到你要用的串口，比如USART1。
- 模式（Mode）：选择Asynchronous（异步通信），这是最常用的模式。
- 基础参数（Basic Parameters）：
  - Baud Rate：设置为你的目标波特率，如115200。这个值需要和PC端串口助手保持一致。
  - Word Length：8 Bits。通常我们以字节为单位发送数据。
  - Parity：None。无奇偶校验，简化通信。
  - Stop Bits：1。一位停止位。
- 引脚分配（Pin Configuration）：软件会自动分配默认的TX/RX引脚（如USART1是PA9/PA10）。务必确认这些引脚没有被其他功能（如SPI、I2C）冲突占用。你可以点击引脚查看其当前功能状态。
- NVIC设置（中断）：这是一个关键选择。展开NVIC Settings，你会看到USART1 global interrupt选项。
  - 如果你计划使用printf且输出频率不高：可以不开启中断，使用轮询（Polling）模式。HAL库的轮询发送函数HAL_UART_Transmit是阻塞的，它会等待整个数据发送完成才返回。在printf重定向中，这通常可以接受，因为printf本身也不是用于高速实时流。
  - 如果你需要非阻塞发送，或准备用串口接收大量数据：务必勾选开启全局中断，并设置合适的抢占优先级和子优先级。我们将使用中断模式或DMA模式来实现非阻塞操作，这在主循环需要快速响应的系统中是必需的。

注意：很多教程只教轮询模式，因为它简单。但在实际项目中，尤其是产品级代码，阻塞式发送会拖慢整个系统响应，比如在中断服务函数里调用printf，如果使用轮询发送，可能会导致中断执行时间过长或与其他中断冲突。因此，理解中断和DMA方式至关重要。

生成工程代码：点击Project Manager标签，设置工程名称、路径、IDE（STM32CubeIDE）和堆栈大小。特别要注意Linker Settings中的Minimum Heap Size和Minimum Stack Size，使用printf可能会消耗较多栈空间，建议将堆（Heap）大小至少设置为0x600（1536字节），栈（Stack）设置为0x400（1024字节）或更大，否则可能导致程序硬故障。最后，点击GENERATE CODE。

2.2 解读生成的HAL库串口初始化代码

生成代码后，打开主工程，找到main.c，你会看到main函数里调用了MX_USART1_UART_Init()。这个函数定义在usart.c中，其核心是初始化一个UART_HandleTypeDef结构体huart1，并调用HAL_UART_Init。

// usart.c 中自动生成的部分 UART_HandleTypeDef huart1; void MX_USART1_UART_Init(void) { 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; if (HAL_UART_Init(&huart1) != HAL_OK) { Error_Handler(); } }

这个结构体huart1就是后续所有串口操作的句柄。HAL_UART_Init函数内部会进一步调用HAL_UART_MspInit来初始化底层GPIO和时钟等，这些代码也在usart.c中，是CubeMX根据你的图形配置生成的。至此，串口的硬件初始化就完成了。

3. 实现阻塞式（轮询）串口数据发送

在实现printf重定向前，我们先掌握最基础的串口发送函数，这有助于理解HAL库的工作机制。

3.1 HAL_UART_Transmit函数详解

HAL库提供了HAL_UART_Transmit函数用于阻塞式发送。所谓阻塞，就是函数会一直等待，直到指定长度的数据全部发送完毕，或者超时，才会返回。

HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout);

huart: 串口句柄指针，如&huart1。
pData: 要发送的数据缓冲区首地址。
Size: 要发送的数据长度（字节数）。
Timeout: 超时时间（毫秒）。如果设置为HAL_MAX_DELAY（0xFFFFFFFF），则会无限等待直到完成。

一个简单的发送字符串的例子：

char msg[] = "Hello, STM32!\r\n"; // \r\n是回车换行，方便串口助手显示 HAL_UART_Transmit(&huart1, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY);

为什么需要(uint8_t*)强制转换？因为pData参数类型是uint8_t *（无符号8位指针），而msg是char型数组。在STM32的编译环境中，char通常默认为signed char，直接传递会导致类型不匹配的警告。进行强制转换是良好的编程习惯。

3.2 阻塞发送的优缺点与适用场景

优点：

简单直观：调用一行函数，数据就发出去了，无需管理状态。
时序确定：函数返回时，数据肯定已经进入发送移位寄存器，甚至已经发送完成（取决于Timeout设置）。

缺点：

效率低下：CPU在数据发送期间被“挂起”，无法执行其他任务。发送115200波特率的一个字节大约需要87微秒，发送一个20字节的字符串就要消耗约1.74毫秒，这对于实时性要求高的系统是不可接受的。
可能引起系统卡顿：如果在中断服务程序（ISR）或高优先级任务中使用阻塞发送，会严重延长中断响应时间，可能导致其他中断丢失或系统看门狗复位。

适用场景：

初始化阶段的调试信息输出。
对实时性要求极低，或只是偶尔发送数据的应用。
初学者快速验证串口硬件是否工作。

实操心得：即使你打算最终使用中断或DMA，也建议先用阻塞发送写一个最简单的测试程序，比如在main函数的while(1)循环前发送一个“System Start”字符串。用串口助手（如XCOM、SSCOM）正确接收到这个信息，能第一时间确认你的硬件连接（TX/RX线序、CH340等USB转串口驱动）、波特率配置、CubeMX工程生成没有根本性错误。这是硬件调试的“第一盏灯”。

4. 重定向printf至串口：改写fputc与链接器配置

让printf工作，需要解决两个问题：一是告诉printf最终把字符送到哪里（重定向），二是确保编译后的程序包含了printf所需的底层代码（链接库）。

4.1 重定向原理：钩住_fputc

在ARM Compiler（包括Keil MDK和STM32CubeIDE使用的GCC for ARM）中，printf家族函数最终会调用一个名为_write（或fputc，取决于编译器和库的实现）的底层函数，将字符写入文件描述符。在嵌入式无操作系统的环境下，我们需要自己实现这个函数，将其输出指向我们的串口。

对于GCC ARM（STM32CubeIDE），我们需要重写的是_write函数。在工程中任意一个.c文件（通常放在main.c或专门的文件如retarget.c中）添加以下代码：

#include <unistd.h> // 提供 _write 的函数声明 #include “main.h” // 确保包含了 huart1 的声明 extern UART_HandleTypeDef huart1; // 如果 huart1 在 main.c 定义，需要 extern 声明 int _write(int file, char *ptr, int len) { if (file != STDOUT_FILENO && file != STDERR_FILENO) { errno = EBADF; return -1; } // 调用HAL库阻塞发送函数，将数据发送到串口1 HAL_UART_Transmit(&huart1, (uint8_t*)ptr, len, HAL_MAX_DELAY); // 返回成功发送的字节数 return len; }

file参数是文件描述符。STDOUT_FILENO（标准输出）和STDERR_FILENO（标准错误）通常对应到printf和fprintf(stderr, ...)。我们只处理这两个。
ptr是指向要输出字符串的指针，len是长度。
我们直接使用之前介绍的HAL_UART_Transmit函数，以阻塞方式发送数据。

对于Keil MDK（ARMCC），通常需要重写fputc函数：

#include <stdio.h> #include “main.h” extern UART_HandleTypeDef huart1; int fputc(int ch, FILE *f) { // 发送单个字符 HAL_UART_Transmit(&huart1, (uint8_t*)&ch, 1, HAL_MAX_DELAY); return ch; }

4.2 链接器与库配置：启用半主机模式与微库

仅仅重写了底层函数还不够，编译器默认可能使用“半主机（Semihosting）”模式，这是一种通过调试器将标准输入输出重定向到主机PC的方式，它需要调试器支持且效率极低，不适合独立运行。我们必须关闭它，并告诉链接器使用我们自己的实现。

在STM32CubeIDE（GCC）中：

右键点击工程，选择Properties。
进入C/C++ Build->Settings。
在Tool Settings标签下，找到MCU GCC Linker->Libraries。
在Libraries (-l)一栏，添加nosys和c（如果还没有）。nosys库提供了不依赖操作系统的_write等桩函数，但最终会被我们重写的版本覆盖。
更关键的是，在MCU GCC Compiler->Preprocessor的Defined symbols中，添加-D开头的宏定义：-D_GNU_SOURCE。有时为了彻底禁用半主机，还需要在代码中添加：
```
// 在main.c开头，包含头文件之后 void _initialise_monitor_handles(void) __attribute__((weak)); void _initialise_monitor_handles(void) {}
```
但通常，正确实现_write并链接nosys库就足够了。

在Keil MDK中：

点击魔术棒按钮（Options for Target）。
进入Target标签，勾选Use MicroLIB。MicroLib是Keil为嵌入式系统优化的一个精简C库，它默认不使用半主机，并且对printf的支持更友好，代码体积也更小。
如果你不使用MicroLib，则需要手动在代码中禁用半主机，并确保链接了正确的库，过程更复杂。因此，在Keil下，强烈建议直接勾选Use MicroLIB。

4.3 测试你的printf重定向

完成以上步骤后，就可以进行测试了。在main函数的初始化部分（while(1)之前）添加测试代码：

#include <stdio.h> // 别忘了包含这个头文件 int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART1_UART_Init(); // ... 其他外设初始化 printf(“\r\n===== System Boot =====\r\n”); printf(“Clock: %lu Hz\r\n”, HAL_RCC_GetSysClockFreq()); int count = 0; float voltage = 3.3f; while (1) { HAL_Delay(1000); // 延时1秒 count++; printf(“[%d] Hello, World! ADC Value: %d, Voltage: %.2f V\r\n”, count, some_adc_value, voltage); // 注意：如果 some_adc_value 和 voltage 是真实变量，需要先有读取ADC的代码 } }

打开串口助手，选择正确的COM口（设备管理器里查看），波特率设为115200，数据位8，停止位1，无校验。复位开发板，你应该能看到启动信息和每秒递增的计数信息。

踩坑记录：最常见的两个问题。一是没输出：检查TX/RX线是否接反；检查CubeMX中串口引脚配置是否正确，特别是Debug设置是否冲突；检查_write/fputc函数是否正确定义并调用到了HAL_UART_Transmit；检查链接库配置。二是输出乱码：99%的原因是系统时钟配置错误，导致串口波特率发生器计算的分频值不准。请回头仔细检查CubeMX中时钟树的配置，尤其是HSE/PLL的倍频分频设置，确保HCLK是你预期的频率。可以用printf(“SysClk: %lu\r\n”, HAL_RCC_GetSysClockFreq());来打印验证。

5. 进阶：非阻塞发送与DMA传输提升效率

当你的系统需要频繁打印日志，或者主循环需要处理其他紧急任务时，阻塞式printf就成了瓶颈。我们需要将其改造为非阻塞方式。

5.1 中断发送模式

HAL库提供了HAL_UART_Transmit_IT函数，它以中断方式启动发送。函数调用后立即返回，数据发送在后台由串口发送完成中断（TC）或发送数据寄存器空中断（TXE）来驱动。

首先，在CubeMX中必须开启该串口的全局中断（NVIC Settings）。然后，代码需要做以下调整：

定义一个发送缓冲区：因为中断发送是异步的，你必须确保在发送完成前，源数据缓冲区不能被修改或释放。通常定义一个全局或静态数组作为缓冲区。
启动中断发送：调用HAL_UART_Transmit_IT。
处理发送完成回调：发送完成后，HAL库会调用HAL_UART_TxCpltCallback函数。你可以重写这个函数来处理发送完成事件（例如，释放缓冲区、启动下一次发送）。

然而，直接将printf重定向到中断发送是危险的，因为printf可能在任何地方（包括中断里）被调用，并且它输出的数据长度是不定的。直接重定向会导致缓冲区管理极其复杂，且可能发生重入问题。

更实用的方案是：实现一个线程安全的环形缓冲区（FIFO）和后台发送任务。

printf不再直接调用串口发送函数，而是将格式化后的字符串写入一个环形缓冲区。
在main函数的while(1)循环中，或在一个低优先级的RTOS任务中，不断检查环形缓冲区是否有数据，如果有，则取出一定长度，调用HAL_UART_Transmit_IT启动中断发送。
在HAL_UART_TxCpltCallback中，判断如果环形缓冲区还有数据，则再次启动中断发送，直到缓冲区清空。

这种方式实现了“生产者（printf）-消费者（后台发送任务）”模型，printf调用几乎不阻塞，后台任务负责异步发送。这是产品级代码中常见的日志输出架构。

5.2 DMA发送模式（终极优化）

DMA（直接存储器访问）是比中断更高效的传输方式。它可以在不占用CPU的情况下，自动将内存中的数据搬运到串口的数据寄存器中。CPU只需要启动DMA传输，就可以去处理其他事情，直到DMA传输完成产生中断通知CPU。

使用DMA发送printf数据的思路与中断模式类似，但底层使用HAL_UART_Transmit_DMA函数。

CubeMX配置：在串口配置页面，找到DMA Settings，点击Add添加一个DMA请求。对于发送（Transmit），通常选择USARTx_TX。模式（Mode）选择Normal（发送一次）或Circular（循环发送，适用于特定场景如连续波形输出）。优先级（Priority）根据系统需求设置。
代码实现：同样采用环形缓冲区+后台DMA发送任务的架构。当需要发送时，从环形缓冲区拷贝数据到一个DMA发送缓冲区，然后调用HAL_UART_Transmit_DMA。在HAL_UART_TxCpltCallback（DMA发送完成回调）中处理后续数据。
巨大优势：对于大量数据的发送，DMA几乎零CPU占用。例如，发送1KB的日志，CPU只需发起一次DMA请求，剩下的时间可以全力处理其他任务。

深度优化技巧：对于printf，频繁的DMA启动（每次发送都配置DMA）也有开销。一个高级技巧是使用串口空闲中断（IDLE）配合DMA接收的反向思路来优化发送：配置DMA为循环模式（Circular），指向一个较大的发送缓冲区。printf将数据填入缓冲区，并更新写指针。一个后台任务或定时器检查到有新增数据，就计算长度，然后通过修改DMA传输数量（CNDTR）来“启动”对新数据的发送。这种方式减少了频繁调用HAL_UART_Transmit_DMA的开销。但这属于更高级的用法，需要对DMA和串口有深入理解。

5.3 中断/DMA模式下的重定向实现示例（简化版）

这里给出一个基于中断和简单全局缓冲区的简化版重定向，仅供理解原理，生产环境需要更完善的缓冲区管理和互斥保护。

// printf_uart.c #include “main.h” #include <stdio.h> #include <string.h> #define TX_BUF_SIZE 256 extern UART_HandleTypeDef huart1; static uint8_t tx_buffer[TX_BUF_SIZE]; static volatile uint16_t tx_write_idx = 0; static volatile uint16_t tx_read_idx = 0; static volatile uint8_t tx_busy = 0; // 发送状态标志 // 将数据放入缓冲区 static int uart_putbuf(const uint8_t *data, uint16_t len) { uint16_t i; for(i = 0; i < len; i++) { uint16_t next = (tx_write_idx + 1) % TX_BUF_SIZE; if(next == tx_read_idx) { // 缓冲区满 return -1; // 可以在这里选择丢弃最旧数据或等待，简化处理返回错误 } tx_buffer[tx_write_idx] = data[i]; tx_write_idx = next; } // 尝试启动发送 uart_start_tx(); return len; } // 尝试从缓冲区取数据并启动发送 static void uart_start_tx(void) { if(tx_busy || (tx_read_idx == tx_write_idx)) { return; // 正在发送或缓冲区空 } // 计算连续可发送的数据长度（简化处理，未处理环形缓冲区折返） uint16_t len_to_send; if(tx_write_idx > tx_read_idx) { len_to_send = tx_write_idx - tx_read_idx; } else { len_to_send = TX_BUF_SIZE - tx_read_idx; } tx_busy = 1; HAL_UART_Transmit_IT(&huart1, &tx_buffer[tx_read_idx], len_to_send); } // 重定向的_write函数 int _write(int file, char *ptr, int len) { if (file != STDOUT_FILENO && file != STDERR_FILENO) { return -1; } // 将数据存入缓冲区 return uart_putbuf((uint8_t*)ptr, len); } // 串口发送完成中断回调函数 void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if(huart->Instance == USART1) { // 更新读指针 tx_read_idx = (tx_read_idx + huart->TxXferSize) % TX_BUF_SIZE; tx_busy = 0; // 发送完成后，检查是否还有数据要发送 uart_start_tx(); } } // 在主循环中，可以定期调用 uart_start_tx()，或者依靠上述回调自动链式发送。

这个示例展示了核心思想：printf写入缓冲区，中断回调驱动发送并管理缓冲区指针。实际项目中，你需要考虑多任务/中断环境下的缓冲区互斥（关中断或使用信号量）、缓冲区满的策略（阻塞、丢弃新数据或丢弃旧数据）以及处理环形缓冲区的折返发送问题。

6. 实战中的调试技巧与性能考量

掌握了基本方法后，如何在复杂的项目中用好printf，还需要一些实战技巧。

6.1 格式化输出的性能陷阱

printf是一个很强大的函数，但也是一个“重量级”函数，特别是浮点数格式化（%f）和长整型格式化。在资源紧张的STM32上，频繁调用printf输出浮点数可能导致明显的延迟和代码体积膨胀。

代码体积：使用printf及其浮点支持，会显著增加编译后的程序大小（可能增加几十KB）。如果芯片Flash紧张，需要谨慎。
执行时间：一次包含浮点数的printf调用，可能需要数毫秒甚至更长的执行时间。

优化建议：

避免在中断服务程序中使用printf：中断中应执行最精简的代码。如果非要输出调试信息，可以设置一个标志位，在主循环中检查并打印。
减少格式化输出的频率和复杂度：不要在每个高速循环中都调用printf。可以累积一定量的数据，或者仅在状态变化时输出。
使用简化版的打印函数：自己实现一个只支持%d，%u，%x，%s的轻量级my_printf函数，可以大大节省空间和时间。网上有很多开源实现（如tinyprintf）。
将浮点运算转换为整数输出：例如，ADC值对应的电压，可以在MCU端先乘以1000转为整数毫伏值，然后用%d输出，在PC端再除以1000显示。这避免了在MCU端进行浮点格式化。

6.2 使用条件编译管理调试输出

在产品开发的不同阶段，调试信息的详细程度不同。最终发布时，通常需要关闭大部分调试输出以提升性能和安全性。使用条件编译是标准做法。

// 在头文件中定义调试级别 #define DEBUG_LEVEL 1 // 0:关闭， 1:错误， 2:警告， 3:信息， 4:详细 #if (DEBUG_LEVEL >= 1) #define LOG_E(fmt, ...) printf(“[E] “ fmt “\r\n”, ##__VA_ARGS__) #else #define LOG_E(fmt, ...) #endif #if (DEBUG_LEVEL >= 3) #define LOG_I(fmt, ...) printf(“[I] “ fmt “\r\n”, ##__VA_ARGS__) #else #define LOG_I(fmt, ...) #endif // 在代码中使用 LOG_I(“System started, Clock = %lu”, SystemCoreClock); if(error_occurred) { LOG_E(“Sensor communication failed!”); }

通过修改DEBUG_LEVEL宏，编译器会在预处理阶段将不需要的日志语句完全移除，不生成任何代码，不影响发布版本的性能。

6.3 结合SEGGER RTT等高级调试工具

对于追求极致调试体验的开发者，printf重定向到串口虽然经典，但也有缺点：需要占用一个硬件串口，需要连接线缆，速度受限于波特率。

像SEGGER RTT（Real Time Transfer）这样的工具，通过调试器（如J-Link）的SWD接口，在内存中开辟一块区域作为上行（到PC）和下行（到MCU）的通道。它不需要额外的硬件串口，速度极快（可达MB/s级别），并且可以在MCU运行时（即使中断被关闭）输出信息。

在HAL库工程中集成RTT也非常方便，通常只需添加几个源文件，然后将printf重定向到RTT的上行通道即可。这对于调试实时性要求高、串口资源紧张或需要高速日志输出的项目，是更优的选择。当然，这需要特定的调试器（J-Link）支持。

7. 总结与个人经验谈

回顾整个过程，从最基础的阻塞发送，到重定向printf，再到为了追求效率引入中断和DMA，并辅以环形缓冲区，最后考虑性能优化和调试管理，这是一个典型的嵌入式开发技能演进路径。

我个人在项目中最常用的模式是：在开发初期，使用简单的阻塞式printf重定向，快速验证想法和排查硬件问题。当项目复杂度增加，特别是引入了RTOS或多重中断后，会迅速切换到“环形缓冲区 + 中断/DMA发送任务”的架构。这个架构的缓冲区大小通常设置为512字节或1KB，足以应对一般的调试日志输出。对于最终产品，会通过条件编译将信息级（INFO）以下的日志全部关闭，只保留错误（ERROR）日志，并且错误日志的输出函数也会做优化，确保在极端情况下（如内存错误）也能有最基本的输出能力。

还有一个容易忽略的点是线程安全。如果你的系统中有多个任务或中断都可能调用printf，那么向缓冲区写入数据的操作必须是原子的。在无RTOS的系统中，通常通过关中断来实现；在使用RTOS（如FreeRTOS）的系统中，则使用互斥信号量（Mutex）来保护共享的缓冲区。

最后，关于HAL库本身，它通过高度的封装简化了开发，但也隐藏了细节。理解其背后的机制（比如huart->gState和huart->RxState这些状态变量），对于排查“为什么发送一次后就卡住了”这类问题至关重要。当你深入使用中断或DMA时，仔细阅读HAL库的源码和注释，往往是解决问题的唯一捷径。串口通信作为嵌入式世界的“嘴巴”和“耳朵”，把它调稳定了，项目的调试之路就成功了一大半。