STM32串口通信实战：从CubeMX配置到HAL库三种发送模式详解

1. 项目概述：从零到一打通STM32的“嘴巴”

搞嵌入式开发，尤其是玩STM32的，串口通信绝对是第一个要啃下来的硬骨头。你可以把它想象成单片机的“嘴巴”和“耳朵”，是它和外部世界（比如你的电脑、另一个单片机或者各种传感器模块）对话最基本、最直接的方式。很多新手在点完LED灯之后，第一个想实现的功能就是让单片机通过串口说一句“Hello World”，这标志着你从控制硬件IO，迈入了数据通信的世界。

这次我们聚焦在STM32CubeMX这个强大的图形化配置工具上，目标是使用UART1（也就是第一个串口）实现数据发送功能。为什么是UART1？因为在绝大多数STM32系列芯片的引脚定义里，UART1对应的TX（发送）和RX（接收）引脚（通常是PA9和PA10）在默认情况下与ST-Link调试器的VCP（虚拟串口）功能是连接好的。这意味着你只需要一根ST-Link的USB线连接到电脑，就同时完成了供电、程序下载和串口通信的物理连接，几乎不需要额外接线，对新手和快速验证想法来说极其友好。整个过程就像搭积木：用CubeMX配置好时钟、引脚和串口参数，生成代码框架，然后我们只需要在合适的地方写上几句“说话”的代码，编译下载，就能在电脑上的串口调试助手里看到单片机发来的信息了。这不仅是调试利器（打印变量值、程序状态），更是后续实现更复杂通信（如GPS解析、蓝牙指令、Wi-Fi数据传输）的基石。

2. 核心思路与CubeMX工程创建

在动手写代码之前，清晰的思路能避免很多弯路。我们的目标是让STM32通过UART1发送数据，那么整个流程可以拆解为三个核心环节：硬件资源配置、通信参数协商、软件驱动调用。STM32CubeMX的价值就在于，它通过图形化界面帮我们高效、准确地完成了前两个环节，并生成了第三个环节的底层驱动代码，我们只需关注应用层逻辑。

2.1 工程创建与芯片选型

首先，打开STM32CubeMX，点击“New Project”。在芯片选择器里，输入你的芯片型号，例如我手头用的是STM32F103C8T6（经典的“蓝色药丸”核心板），就直接搜索“F103C8”。选中具体型号后，芯片示意图会显示出来，双击它创建工程。

进入工程界面后，第一步不是急着找串口，而是先给芯片“上电”——配置系统时钟。对于串口通信，稳定的时钟源是准确计算波特率的基础。在左侧“System Core”里找到“RCC”（复位和时钟控制）。对于F1系列，通常在高速度时钟（HSE）选择“Crystal/Ceramic Resonator”，这意味着我们使用外部晶振（通常是8MHz）作为时钟源。这样系统时钟才能被正确倍频到72MHz（以F103为例），为外设提供精准的时钟。

注意：很多新手会忽略这一步，直接使用内部RC振荡器（HSI）。虽然HSI也能工作，但它的精度相对较差（通常±1%），在较高的波特率（如115200）下可能会累积误差，导致通信乱码或失败。对于可靠的串口通信，强烈建议使用外部晶振（HSE）。

2.2 UART1外设的图形化配置

时钟配好后，就可以配置主角UART1了。在左侧“Connectivity”分类下，找到“USART1”。点击它，工作模式默认为“Disable”，我们需要将其切换为“Asynchronous”（异步通信模式），这是最常用的串口模式。

一旦模式启用，右侧的芯片引脚图上，PA9和PA10通常会自动被标记为“USART1_TX”和“USART1_RX”。CubeMX自动为我们分配了这两个引脚作为串口1的发送和接收功能，这和我们之前说的硬件设计惯例是一致的。有时候引脚可能被其他功能占用（比如调试接口），如果没自动分配，你也可以手动点击对应的引脚，从弹出的功能列表中选择“USART1_TX”或“USART1_RX”。

接下来是核心的参数配置，点击USART1进入其参数设置面板。这里有几个关键参数，它们决定了通信双方能否“听懂”彼此的话：

1. 波特率（Baud Rate）：这是通信速度，表示每秒传输的符号数。常见值有9600， 115200等。必须和电脑端串口调试助手设置的波特率完全一致，否则接收到的全是乱码。我们这里填115200。
2. 字长（Word Length）：选择“8 Bits”。一个字节（Byte）是8位，这是最通用的设置。
3. 停止位（Stop Bits）：选择“1 Stop Bit”。这是标准配置。
4. 校验位（Parity）：选择“None”。为了简单起见，我们不使用校验。
5. 硬件流控制（Hardware Flow Control）：选择“Disable”。我们的简单通信不需要使用RTS/CTS这类流控信号。

其他参数如“过采样”保持默认的“16倍”即可。这些参数共同构成了一个通信协议：每发送一个8位的数据字节，前后会加上1位起始位（低电平）和1位停止位（高电平），所以实际在线上传输的是10位符号。配置好后，整个串口通信的底层时序、中断、DMA等都由CubeMX生成的HAL库代码来管理，我们无需关心具体的寄存器操作。

2.3 项目生成与代码结构预览

在转到代码生成步骤前，建议先在“Project Manager”标签页设置好项目名称、存储路径、以及最重要的“Toolchain/IDE”。如果你使用Keil MDK，就选择“MDK-ARM”；如果使用STM32CubeIDE，就选择它对应的选项。

关键设置在于“Code Generator”部分。我个人的习惯是勾选“Generate peripheral initialization as a pair of ‘.c/.h’ files per peripheral”，这样每个外设（如USART1）的初始化代码会单独放在usart.c和usart.h里，结构更清晰。然后点击右上角的“GENERATE CODE”，CubeMX就会生成完整的项目文件。

打开生成的项目，进入Core/Src目录，你会找到main.c，usart.c等文件。在main.c中，SystemClock_Config()函数配置了我们之前设置的时钟树，而MX_USART1_UART_Init()函数则包含了所有我们刚刚在图形界面设置的串口参数。这些初始化代码在main()函数开始时被调用，确保了硬件一上电就准备好了。至此，硬件和底层驱动的配置全部由CubeMX完成，我们接下来的工作就是在应用代码中调用HAL库提供的API来发送数据。

3. HAL库发送数据的三种姿势与代码实现

STM32的HAL库提供了不同粒度的发送函数，适用于不同的场景。理解它们的区别，能让你在项目中游刃有余。

3.1 阻塞式发送：最简单直接的HAL_UART_Transmit

这是最基础、最常用的发送函数。它的特点是“阻塞”，即函数会一直等待，直到指定长度的数据全部发送完毕，或者超时，函数才会返回。在这期间，CPU不能执行其他任务。

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

• huart: 串口句柄，对于我们配置的UART1，就是&huart1。
• pData: 要发送的数据缓冲区首地址。
• Size: 要发送的数据长度（字节数）。
• Timeout: 超时时间（毫秒）。如果发送在指定时间内未完成，函数会返回HAL_TIMEOUT。

实战代码：在main函数的while循环前发送字符串我们希望在程序一开始就发送一条欢迎信息。在main.c的main()函数中，找到while (1)循环，在它之前添加如下代码：

/* USER CODE BEGIN 2 */ char msg[] = "Hello World from STM32 UART1!\r\n"; // \r\n是回车换行，让串口助手能换行显示 HAL_UART_Transmit(&huart1, (uint8_t*)msg, strlen(msg), 1000); // 阻塞发送，超时1秒 /* USER CODE END 2 */

注意：strlen函数计算字符串长度（不包括结尾的‘\0’）。这里超时设为1000ms，对于发送短短几十个字节在115200波特率下绰绰有余。阻塞式发送的优点是简单可靠，代码直观。缺点是会“卡住”程序。如果你在发送一个很长的数据包（比如一张图片的二进制流），期间系统就无法响应按键、传感器等中断事件。因此，它适合在初始化阶段发送少量数据，或者在不关心实时性的简单任务中使用。

3.2 中断式发送：不耽误干活的HAL_UART_Transmit_IT

为了解决阻塞式发送占用CPU时间的问题，我们可以使用中断模式。调用这个函数后，它只是启动发送（发出第一个字节），然后就立即返回了。剩下的数据会在后台由串口发送完成中断（TXE）和发送完成中断（TC）来驱动发送。在此期间，CPU可以自由地去执行其他任务。

HAL_StatusTypeDef HAL_UART_Transmit_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size);

函数参数去掉了Timeout，因为它不等待。那么，我们如何知道数据发完了呢？HAL库使用回调函数机制。当一帧数据全部发送完成时，会触发HAL_UART_TxCpltCallback回调函数。我们需要重写这个回调函数来处理发送完成后的工作（比如点亮一个LED，或者启动下一次发送）。

实战代码：在中断回调中处理发送完成事件首先，在main.c的/* USER CODE BEGIN 4 */和/* USER CODE END 4 */之间（这是HAL库预留的用户回调函数编写区），重写发送完成回调：

/* USER CODE BEGIN 4 */ void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if(huart->Instance == USART1) // 判断是哪个串口触发的回调 { // 在这里处理USART1发送完成后的逻辑 HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_0); // 例如，翻转一个LED灯的状态，指示发送完成 } } /* USER CODE END 4 */

然后，在while(1)循环中，我们可以用中断方式发送数据：

char msg_it[] = "Interrupt Mode Transmission!\r\n"; HAL_UART_Transmit_IT(&huart1, (uint8_t*)msg_it, strlen(msg_it)); // 函数调用后立即返回，不会阻塞 HAL_Delay(1000); // 模拟CPU在这1秒内可以做其他事情

中断方式的优点是解放了CPU，提高了系统效率。但编程模型变得稍复杂，需要理解中断和回调机制。同时，缓冲区（msg_it）在发送完成前必须保持有效（通常是全局变量或静态变量），不能是函数内的局部变量（函数返回后局部变量内存可能被覆盖）。

3.3 DMA发送：极致效率的HAL_UART_Transmit_DMA

当需要发送大量数据（如音频流、图像数据）时，即使是中断方式，每个字节都触发一次中断，开销也很大。此时，直接内存访问（DMA）就是终极武器。DMA控制器就像一个“数据搬运工”，可以在不打扰CPU的情况下，自动将内存中的数据搬运到串口的数据寄存器中。CPU只需要配置好DMA的源地址、目标地址和数据长度，然后启动它，就可以完全撒手不管了。

配置步骤：

1. 回到STM32CubeMX，在USART1的配置中，找到“DMA Settings”标签页。
2. 点击“Add”，选择“USART1_TX”。在生成的DMA请求配置中，模式通常选择“Normal”（发送一次），而不是“Circular”（循环发送）。优先级根据系统需要设置。
3. 重新生成代码。CubeMX会自动在usart.c中初始化DMA，并将DMA与USART1的发送通道关联起来。

代码实现： DMA发送的函数原型和中断发送很像：

HAL_StatusTypeDef HAL_UART_Transmit_DMA(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size);

使用方式也类似：

char big_data[1024]; // 假设这是一个1KB的数据缓冲区 // ... 填充big_data ... HAL_UART_Transmit_DMA(&huart1, (uint8_t*)big_data, 1024); // 调用后立即返回，CPU和中断都几乎无负担

发送完成的通知也是通过回调函数，不过名字是HAL_UART_TxHalfCpltCallback（发送一半完成）和HAL_UART_TxCpltCallback（全部发送完成）。DMA方式是大量数据连续发送场景下的性能王者。

4. 串口数据格式化输出：printf的重定向

直接发送字符串常量或字节数组虽然直接，但不够灵活。我们调试时经常需要打印变量值，比如“ADC Value: 2048”，这就需要格式化输出。最自然的方式就是使用我们熟悉的printf函数。但标准库的printf默认输出到标准输出（通常是显示器），我们需要将其“重定向”到串口。

4.1 重写_write函数（针对GCC/ARM Compiler 6）

如果你使用STM32CubeIDE或ARM Compiler 6（AC6），重定向需要重写底层_write系统调用。在main.c文件中，添加以下代码：

/* USER CODE BEGIN 1 */ #include <stdio.h> // 必须包含 /* USER CODE END 1 */ /* ... 其他代码 ... */ /* USER CODE BEGIN 4 */ // 重写_write函数，将输出重定向到UART1 int _write(int file, char *ptr, int len) { HAL_UART_Transmit(&huart1, (uint8_t*)ptr, len, HAL_MAX_DELAY); // 使用阻塞发送，无限等待 return len; // 返回成功写入的字符数 } /* USER CODE END 4 */

HAL_MAX_DELAY是一个宏，表示无限等待，确保printf能完整输出。这样配置后，你就可以在代码中像在PC上一样使用printf了：

int sensor_value = 1234; float temperature = 25.6; printf("Sensor: %d, Temp: %.1f C\r\n", sensor_value, temperature);

4.2 使用微库（MicroLIB）与重定向fputc（针对Keil MDK）

如果你使用Keil MDK且启用了微库（MicroLIB，一个为嵌入式优化的小型C库），重定向方式略有不同。首先确保在Keil的“Target”选项里勾选了“Use MicroLIB”。然后在main.c中重写fputc函数：

/* USER CODE BEGIN 0 */ #include <stdio.h> #ifdef __GNUC__ #define PUTCHAR_PROTOTYPE int __io_putchar(int ch) #else #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f) #endif PUTCHAR_PROTOTYPE { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); // 发送单个字符 return ch; } /* USER CODE END 0 */

实操心得：printf虽然方便，但内部会调用malloc等函数，有体积和性能开销。在资源极其紧张（Flash/RAM很小）或对实时性要求极高的场合，建议使用sprintf先将字符串格式化到缓冲区，再用HAL_UART_Transmit发送缓冲区内容，这样更可控。

5. 硬件连接与软件调试全流程

代码写好了，但要看到效果，还需要正确的硬件连接和PC端软件配合。

5.1 ST-Link连接与驱动安装

对于最常见的STM32核心板（如F103C8T6），使用ST-Link V2调试器是最方便的方案。连接通常只需要四根线：

• SWCLK->SWCLK(时钟线)
• SWDIO->SWDIO(数据线)
• 3.3V->3.3V(电源)
• GND->GND(地线)

注意：ST-Link的3.3V输出电流有限（通常约150mA），如果核心板外设较多，最好使用外部电源单独给核心板供电，ST-Link仅连接SWD和GND进行调试。

将ST-Link插入电脑USB口后，系统可能会自动安装驱动。如果没有，需要去ST官网下载“STSW-LINK009”即ST-Link驱动并安装。安装成功后，在设备管理器的“端口（COM和LPT）”下应该能看到一个类似“STMicroelectronics STLink Virtual COM Port (COMx)”的设备，记住这个COM号（如COM3），这就是我们程序里UART1映射出来的虚拟串口。

5.2 串口调试助手的选择与配置

PC端需要一个软件来接收和显示串口数据，这就是串口调试助手。这类软件很多，如SSCOM、XCOM、Putty、甚至Arduino IDE的串口监视器。选择一款你顺手的即可。

以SSCOM为例，关键配置步骤如下：

1. 打开软件，在“串口”下拉框中选择设备管理器中看到的COM号（如COM3）。
2. 设置波特率为115200，数据位8，停止位1，校验位无，流控制无。这些参数必须和CubeMX中的配置一字不差。
3. 点击“打开串口”。

5.3 编译、下载与观察结果

回到你的IDE（Keil或CubeIDE），编译工程（0错误，0警告）。将核心板通过ST-Link连接好，点击下载（Download/Debug）按钮将程序烧录到芯片中。复位或重新上电后，程序开始运行。

此时，观察串口调试助手的接收区。如果一切顺利，你应该能看到程序发送的“Hello World from STM32 UART1!”等信息。如果使用的是中断或DMA方式，并且你按照示例代码添加了LED翻转，还能看到LED在闪烁，这直观地证明了发送是在后台完成的，主循环没有被阻塞。

6. 深度避坑指南与高级技巧

掌握了基本操作，下面这些从实际项目中踩坑总结的经验，能帮你走得更稳。

6.1 乱码问题排查四步法

串口通信最常见的故障就是接收端显示乱码。别慌，按以下顺序排查：

1. 检查波特率：这是乱码的“头号嫌犯”。99%的乱码都是因为收发双方波特率不匹配。请逐位核对CubeMX配置和串口助手设置的波特率数值，确保完全相同。即使是115200和1152000（多一个零）这种细微差别也会导致完全无法识别。
2. 检查时钟源：确认系统时钟源是否使用了外部晶振（HSE）。如前所述，内部HSI的精度可能导致波特率偏差。在CubeMX的“Clock Configuration”标签页，检查系统时钟（SYSCLK）是否是从HSE倍频而来，并且主频是否是你芯片支持的正确频率（如F103的72MHz）。
3. 检查硬件连接：确认TX和RX线是否接反。STM32的TX应接对方（如USB转TTL模块）的RX，RX接对方的TX。同时检查地线（GND）是否可靠连接，共地是通信的基础。
4. 检查代码和缓冲区：如果发送的是变量或通过printf输出，检查数据缓冲区是否有效，printf重定向是否成功。可以尝试先发送一个简单的、固定的字符串（如“TEST”），如果固定字符串正常而变量输出乱码，问题就出在格式化或数据源上。

6.2 多串口管理与资源分配

一个项目里常常不止一个串口。例如，UART1连接电脑调试，UART2连接GPS模块，UART3连接蓝牙模块。在CubeMX中配置多个串口的方法完全一样，只需分别使能USART2、USART3等，并配置各自的引脚和参数。

在代码中，每个串口都有一个独立的句柄（huart1，huart2，huart3）。调用发送函数时，指定正确的句柄即可：

HAL_UART_Transmit(&huart2, gps_data, len, 100); // 发送给GPS模块 HAL_UART_Transmit(&huart3, bt_cmd, cmd_len, 100); // 发送给蓝牙模块

对于中断和DMA方式，回调函数需要通过判断句柄来区分是哪个串口触发的，就像我们在HAL_UART_TxCpltCallback里做的那样。

6.3 稳定性与抗干扰考量

产品化项目中，串口通信的稳定性至关重要。

• 增加超时与重发：对于重要指令，不要只发送一次。可以在应用层实现一个简单的“发送-等待应答-超时重发”机制。
• 使用数据帧与校验：不要只发送原始数据流。定义简单的帧结构，例如[帧头 0xAA] [长度] [数据] [校验和] [帧尾 0x55]。接收方通过帧头帧尾判断数据包边界，通过校验和（如所有字节累加和取低8位）验证数据完整性。CRC校验是更严谨的选择。
• 硬件滤波与保护：在通信线较长或环境恶劣时，可以在TX/RX线上串联一个几十欧姆的电阻，并加上对地的TVS二极管，以抑制浪涌和静电。对于RS-485通信（使用UART+MAX485芯片），必须处理好使能信号（DE/RE）的切换时序，这是另一个常见坑点。

6.4 性能优化与内存管理

• 避免在中断回调中做复杂操作：HAL_UART_TxCpltCallback是在中断上下文中被调用的。在这里应只做标志设置、缓冲区指针移动等轻量级操作，把复杂逻辑（如数据处理、下一包准备）放到主循环中根据标志位来执行。
• DMA双缓冲（乒乓缓冲）：对于持续不断的高速数据流（如音频），可以配置DMA为循环模式（Circular），并配合双缓冲区。当DMA在发送缓冲区A时，CPU填充缓冲区B；DMA发送完A后自动切换至B发送，同时CPU填充A。如此循环，实现无缝数据流。
• 动态内存慎用：在中断或DMA回调中，避免使用malloc/free，因为标准库的这些函数可能不是线程/中断安全的，容易导致堆碎片或死锁。嵌入式开发中，更推荐使用静态数组或内存池来管理通信缓冲区。

从在CubeMX里点点鼠标配置参数，到在串口助手看到第一行“Hello World”，这个过程打通了STM32与外界通信的“任督二脉。它不仅仅是发送几个字符，而是建立起一套可靠的、可扩展的调试和信息输出通道。后续无论是连接传感器、上传物联网数据，还是进行多机通信，其底层核心都离不开今天实践的这些基本操作。理解阻塞、中断、DMA这三种模式的适用场景，掌握printf重定向的便捷，再结合避坑指南里的实战经验，你就能让手中的STM32清晰、稳定地“说话”了。