STM32C542 UART配置与printf重定向实战指南-开发者社区

1. 从一颗新芯片开始：为什么我选了STM32C542做UART调试

先用一句话交代背景：这次项目用的是STM32C542，C系列相对大家更熟悉的F系列来说，内核升级到了Cortex-M33，主频能跑到110MHz左右，外设也做了不少改动。第一部分我主要是点亮系统时钟、跑通基本GPIO，到了第二部分已经在捣鼓中断和定时器了。今天这篇是第三篇，核心内容就两个：怎么把UART配置好，以及怎么让printf老老实实从串口吐出来。这两个看起来是基本功，但如果你是从F1、F4直接跳过来用C542的，有几个细节值得提前知道，不然会被一些“隐性差异”卡住半天。

先说为什么UART配置是所有调试工作的起点。我这个板子没有板载调试器以外的交互通道，跑着裸机代码，最痛的不是逻辑写不出来，而是看不到中间状态。你要么用SWD调试器打断点看变量，要么用printf扔日志。但SWD打断点这招在某些场景下并不好用——比如时序敏感、正在和外部设备通信的中断服务函数里，你断下来系统就死了，问题不一定复现。而串口日志是异步的、非侵入式的，逻辑跑飞之前能留下最后的遗言，所以UART基本是嵌入式开发的“生命线”。

这篇内容如果你正在用STM32C542或者其他C系列芯片，可以直接照着抄作业。用老F系列的朋友也可以看，很多思路是通的，但有几个寄存器、时钟和HAL库版本的差异，我会单独标志出来。

我的开发环境如下：

芯片：STM32C542R8T6
开发工具：STM32CubeIDE 1.17.x（用的HAL库）
串口工具：USB转TTL模块（CH340），串口助手推荐用MobaXterm或Vofa+，后面讲为什么
调试器：板载ST-Link

硬件上我只做了一件非常简单的事：把USART1的TX/RX接到USB转TTL模块，再连到电脑。就这么点事，中间其实藏了好几个值得说清楚的地方，下面挨个讲。

2. UART配置的核心思路和传统写法的差异

2.1 C542的UART外设到底强在哪

STM32C542上的UART和F1、F4不太一样。它内部用的是叫LPUART和USART的组合，其中我们常用的USART支持了更多可配置能力，比如：

可编程的数据位（7、8、9位可选）
同步模式和单线半双工模式
硬件流控（RTS/CTS）
FIFO（发送和接收各16字节，注意不是所有C系列型号都有，具体看参考手册的“USART implementation”章节）
过采样方式可选（16倍或8倍过采样）

这些能力如果只是当普通日志口用，确实没啥感觉。但后面如果你要接一个需要RS485收发控制脚的设备，或者要跑一个要求高精度的DMX512协议，那C系列硬件的可配置性优势就出来了。配置错误也不会立刻报错，但底层的波特率误差会直接影响通信成功率。

有一个差异一定要强调：**C542的UART时钟源并不默认挂在APB2上，你需要自己去查时钟树。**F1时代USART1在APB2，USART2/3在APB1，很多人已经背下来了。C542虽然也是类似分配，但Cortex-M33带来的总线矩阵重构导致外设时钟的开关方式、复位方式都变了。如果你照搬旧工程的RCC时钟使能代码，大概率编译能过，运行起来串口就是不出数据。

2.2 直接操作寄存器还是用HAL？成年人全都要

很多人一上来就纠结：用寄存器还是HAL库？我的观点：**调试阶段用HAL库快速跑通，稳定之后如果有性能瓶颈，再针对性换寄存器。**这不是摸鱼，这是效率最大化。

举一个具体例子：你用HAL库初始化完毕之后，整个UART的发送接收其实都围绕着几个句柄和回调函数转，非常方便。但到了低功耗模式切换、批量发送数据、DMA与中断协同工作的时候，HAL库封装带来的额外函数调用开销和上下文切换就不可忽视了。C542主频110MHz，看起来挺高，但如果你在中断里用HAL_UART_Transmit做日志，每发一个字节都要查状态标志、做超时判断、可能还要等待发送完成，时间就浪费在这些“看不见”的环节里。所以我的实操经验是：

初始化、引脚复用、中断配置全部用HAL，代码生成快，不容易错。
数据发送的“热路径”（比如每秒几百次的日志输出）直接操作寄存器，或者使用HAL库提供的高级发送函数。

具体到寄存器层面，C542的USART发送有个标志位叫TXE（发送数据寄存器空）和TC（发送完成），很多初学者只判断TXE就急着写下一个字节，结果最后一字节没发完就把外设关了，数据尾丢了。处理方式是：发完所有数据后，必须等待TC置1再关或再切模式。这个坑后面会详细说。

2.3 时钟树配置里的隐藏扣分项

这块是我此次踩得最深的一个坑，必须单独拿出来讲。

STM32C542的UART挂在哪条总线上，不是看“常识”，而是要看两个东西：一是参考手册里的时钟树图，二是在CubeMX里实际生成出来的RCC配置。我这边用的是USART1，CubeMX里默认给了APB2时钟源（PCLK2）。你看CubeMX的“Clock Configuration”页，USART1的时钟输入默认是PCLK2，而PCLK2最大110MHz。如果你用的外部晶振是8MHz，PLL配置不当，出来的PCLK2可能是55MHz或110MHz。这直接影响波特率计算。

波特率计算公式如下：

对于USART，发送/接收的时钟源为PCLK（这里假设你选择的是PCLK2），常用公式为：

BaudRate = PCLK / (USARTDIV * 16)

当过采样为16时，USARTDIV是一个包含整数和小数部分的寄存器值。反过来推算：

USARTDIV = PCLK / (BaudRate * 16)

举个例子：PCLK2 = 110MHz，目标波特率115200，那么：

USARTDIV = 110000000 / (115200 * 16) = 59.679...

BRR寄存器里存的其实是USARTDIV乘以16之后的值，也就是说整数部分是59，小数部分是0.679*16≈10.86，四舍五入取11。这样实际分频系数是59 + 11/16 = 59.6875，实际波特率约为：

110000000 / (59.6875 * 16) ≈ 115183

误差只有0.015%，完全没问题。

但如果PCLK2不是110MHz而是55MHz，算出来误差可能到0.14%左右，常规通信也能跑，但长帧、高波特率下误码率会增加。所以我的建议是：**把CubeMX时钟树截图截图，串口波特率计算这一步自己手算一遍，不要盲目信任库函数。**HAL库在初始化时确实会根据你填的波特率自动配BRR，但它不会告诉你因为时钟源精度不足导致的误差有多大。

另外注意：C542的UART还允许使用PCLK、PLL2、PLL3、HSI、CSI或LSE作为内核时钟。在某些低功耗场景下，你可能希望串口在STOP模式下还能接收，那就要把UART时钟切到LSE或CSI。这一点L4系列用户应该很熟，但从F1跳过来的人往往会忽略。

3. 实操：从CubeMX生成到第一个Hello World

3.1 CubeMX里的具体配置项

先说一下我的CubeMX配置步骤，非常具体，你可以照着点一遍。

打开STM32CubeMX，选择STM32C542R8T6，进入“Pinout & Configuration”页面：

左侧找到“Connectivity” -> “USART1”，勾选“Asynchronous”模式。此时芯片视图上PA9（USART1_TX）和PA10（USART1_RX）会自动被复用，但注意C542的PA9/PA10不一定是你唯一的选择，有些封装引脚更多，USART1还能映射到PB6/PB7。查一下数据手册的AFIO表。
在“Parameter Settings”里，主要改这几项：

Baud Rate：115200
Word Length：8 Bits（含校验位选择None）
Parity：None
Stop Bits：1
其他保持默认即可

在“NVIC Settings”页，勾选“USART1 global interrupt”。如果你后面要用中断接收，必须在这里把中断打开，否则HAL_UART_Receive_IT会一直超时或永不触发回调。
如果你要开FIFO，去“Parameter Settings”下拉找到“FIFO Mode”。我试过开启后连续收发都更顺畅，但有一个副作用：用HAL库的接收中断回调时，因为FIFO的存在，会出现一次中断收到多个字节的情况。如果上层按“一字节一回调”的逻辑处理，就要小心。裸机+简单日志不需要开FIFO，所以我没有开启。
时钟树配置，我选择：外部高速时钟（HSE 8MHz）→ PLL倍频到系统时钟110MHz，然后APB1分频到55MHz（保证APB1外设不超频），APB2不分频保持110MHz。USART1挂APB2，波特率115200，误差计算如上，可以。

CubeMX生成代码后，工程里应该已经有了MX_USART1_UART_Init()函数，代码如下（HAL库版本生成的典型代码）：

static 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; huart1.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE; huart1.Init.ClockPrescaler = UART_PRESCALER_DIV1; huart1.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT; if (HAL_UART_Init(&huart1) != HAL_OK) { Error_Handler(); } }

如果你用的是更新版本的HAL库，你会发现结构体里多了ClockPrescaler和AdvancedInit字段。这不是你的程序错了，是因为新HAL库把更多硬件特性暴露出来了，没用到就初始化成默认。不需要手动删除。

3.2 引脚复用与GPIO初始化：不要手动再配一遍

很多人会犯一个错误：CubeMX生成代码后，自己又在main函数里用HAL_GPIO_WritePin控制PA9，或者自己改GPIO模式。结果调试了半天，发现串口完全没输出。

原因在于：CubeMX已经为USART1生成了GPIO初始化代码，内容是：

GPIO_InitStruct.Pin = GPIO_PIN_9 | GPIO_PIN_10; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; GPIO_InitStruct.Alternate = GPIO_AF1_USART1; HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

注意里面的Alternate = GPIO_AF1_USART1。这个值看起来只是枚举，但如果你手动在别的工程里用老版本HAL库，可能会把AF编号搞错。C542的USART1复用功能编号是AF1，这个去参考手册的“Alternate function mapping”表查一下。如果AF编号错了，你量引脚上是有电平的，但它就是不走串口模块，死活没有输出。

再补一个细节：GPIO速度设置成了GPIO_SPEED_FREQ_LOW。对于115200这种低速波特率，LOW完全够用，而且还能减少EMI。有些人看网上教程把GPIO速度全部设成HIGH，那是针对SPI、SDIO这类高速接口的，UART这边没必要，设成LOW反而稳。

3.3 第一个发送函数：HAL_UART_Transmit

CubeMX配置好、生成代码后，在main函数里写一个最简单的发送测试：

int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART1_UART_Init(); uint8_t test[] = "Hello from STM32C542\r\n"; HAL_UART_Transmit(&huart1, test, sizeof(test) - 1, 1000); while (1) { } }

HAL_UART_Transmit最后一个参数是超时时间，单位毫秒。这里传1000表示最多等1秒。如果串口模块有问题、引脚没接好、或者波特率完全错乱，函数会返回HAL_TIMEOUT，你可以用返回值判断然后处理错误。很多人一开始不检查返回值，程序看起来是“跑飞”了，实际是卡在某个外设等待上。

实测下来，这个最简单的调用在C542上是直接可用的，没有任何额外的寄存器配置。如果你看到串口助手收到了乱码，别急着改代码，先查波特率、时钟树、USB转TTL模块的地线是否共地。这三个问题占了乱码故障的90%以上。

4. printf重定向：为什么直接改fputc会失效

4.1 编译器与C库的三种重定向方案

UART能发数据了，但每次调用HAL_UART_Transmit要传长度和超时，太麻烦。我们希望在代码里愉快地写printf("temp=%d\r\n", temperature)，这就需要重定向stdio的底层输出函数。

但是，**重定向printf并没有一个全平台通用的方案，它和你的编译器、C库密切相关。**我在STM32C542上用了三种方式，分别对应不同场景：

方案一：Keil MDK + MicroLIB

如果你用的是Keil MDK，并在Options for Target里勾选了“Use MicroLIB”，那么重定向非常简单。在任意一个.c文件里写：

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

MicroLIB是一个精简版C库，它提供的printf会调用fputc来逐字符输出。注意超时时间我写的是0xFFFF，意思是一直等，防止高波特率下UART发送队列塞满时超时返回，导致printf输出中断。MicroLIB模式下代码量小，RAM占用少，特别适合C542这种内部Flash只有64KB/128KB的型号。缺点是它不支持C99的一些高级特性，比如snprintf的某些格式符支持不完整，但在嵌入式日志打印场景完全够用。

方案二：ARM Compiler 6 + 标准C库（不勾选MicroLIB）

如果你没有勾选MicroLIB，用的默认标准C库，则不能用fputc。因为ARM Compiler 6的标准库不直接使用fputc，而是用更底层的一套机制。你需要自己实现_sys_write或在连接阶段使用“半主机（semihosting）”的重定向方式。有一个相对简洁的写法：

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

这在AC5（ARMCC）下可行，但到了AC6（armclang）下，标准库与fputc的关联就变得不那么直接。你可能会发现编译能过，但printf根本没有输出。此时建议使用__asm(".global __use_no_semihosting");来关闭半主机模式，否则程序运行到printf时会跳到调试器的半主机通道，表现为程序卡死。

我在这里给出一段在AC6下经过实测的代码，放在工程任意源文件里均可：

#include <stdio.h> #if defined(__ARMCC_VERSION) && (__ARMCC_VERSION >= 6010050) // 关闭半主机模式，防止printf进入调试通道 __asm(".global __use_no_semihosting"); void _sys_exit(int x) { x = x; } void _ttywrch(int ch) { (void)ch; } int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; } #endif

注意_sys_exit和_ttywrch在标准库内部可能会被引用，编译器要求在关闭半主机之后提供这些符号，否则链接报错。这种做法在MDK AC5/AC6、STM32CubeIDE自带的GCC下也能用，但GCC有一套完全不同的方法。

方案三：STM32CubeIDE / GCC环境下的syscall重写

如果你和我一样用STM32CubeIDE，底层工具链是arm-none-eabi-gcc，那fputc不是不能用，而是需要配合_write或_write_r函数。基于newlib的printf最终会调用_write系统调用，所以重定向方式如下：

#include <stdio.h> int _write(int file, char *ptr, int len) { HAL_UART_Transmit(&huart1, (uint8_t *)ptr, len, 0xFFFF); return len; }

这段代码放到工程任意位置即可。它会接管所有底层字符输出，printf、puts、fprintf都会走到这里。实测时发现一个细节：如果你在中断里调用printf，HAL_UART_Transmit会不断等待TXE标志，可能和其他中断优先级产生竞争，表现为输出偶尔丢字符。后面会讲解决方案。

4.2 重定向printf后的缓冲区与浮点问题

重定向之后，还有一个被忽略的问题：**printf默认是行缓冲还是全缓冲？**在嵌入式C库中，printf的缓冲行为和C库实现有关。MicroLIB下，printf本质上是一次调用fputc输出一个字符，每输出一个字符都要经过HAL库的发送函数，速度慢但实时性好。GCC的newlib标准库在默认情况下，stdout是全缓冲的，只有在缓冲区满或者调用fflush时才会真正输出。

你可能遇到过这种现象：程序跑了一半，串口上一个字符都没打印，突然某个时刻整段输出全部涌出来。这就是全缓冲在起作用。解决方法有两种：

每次printf后手动fflush(stdout);，最直接，但会牺牲效率。
在main开头调用setvbuf(stdout, NULL, _IONBF, 0);把stdout设为无缓冲。这样每个printf都会立刻输出到串口，延迟最小。

我个人偏好方案二。嵌入式日志最重要的是实时性，宁可输出慢一点也不能让日志“攒着不发”。否则程序死机时，缓冲区里那几个字节永远吐不出来，你连现场都看不到。

浮点格式化是另一个坑。printf里写%f，在默认不启用浮点支持的情况下，编译出来的程序会显示“0.000”或者什么都不显示。这不是你代码写错了，而是C库为了节省空间，默认不链接浮点格式化代码。

解决办法：

Keil MDK + MicroLIB：会自动带上浮点格式化，不需要特殊配置。
STM32CubeIDE/GCC：在链接选项里加-u _printf_float，或者在CubeIDE的project properties -> C/C++ Build -> Settings -> MCU GCC Linker -> Miscellaneous里加入-u _printf_float，否则printf里的%f就是无效的。
如果不想动链接选项，另一个办法是用整数运算自己换算小数部分，比如：

int int_part = (int)(value); int frac_part = (int)((value - int_part) * 1000); printf("%d.%03d", int_part, frac_part);

这个技巧适用于拿不到浮点printf的裸机环境。

4.3 printf的线程安全与中断安全

很多嵌入式工程师没意识到，printf并不是中断安全的。假如你的主循环在调用printf，同时串口接收中断里也调用了printf，两个线程会同时操作huart1的发送状态，轻则字符交错，重则HAL_UART_Transmit内部状态机错乱，导致后续所有发送全部卡死。

解决思路有两种：

用一个互斥标志保护UART发送。在裸机环境下，最简单的做法是定义一个全局变量volatile uint8_t uart_busy;，发送前判断，如果忙就等待或丢弃。
把UART发送改成中断发送模式，即调用HAL_UART_Transmit_IT，在发送完成回调里清除标志。这样主循环和中断不会同时操作同一个外设，因为中断发送是异步的，不会阻塞调用方。

对于C542这种主频110MHz的芯片，如果日志量不大，用方式1最简单，同步阻塞式发送避免了状态机复杂度，代价是CPU偶尔会被阻塞几十微秒，但对日志来说完全可以接受。如果日志量很大（比如每秒20KB），建议使用DMA发送。HAL库对应是HAL_UART_Transmit_DMA。DMA发送需要配置DMA通道，同时要处理发送完成回调。

实测下来，C542的DMA发送比F1爽很多，因为DMA支持突发传输，而且中断处理路径更快，CPU负载显著下降。但DMA也会引入一个新坑：如果数据更新太快，上次DMA还没发完，下次你又改了缓冲区内容，会导致串口发出脏数据。规范的写法是用一个“发送中”标志，配合双缓冲，在一块缓冲区发送时往另一块缓冲区写入新数据。

5. 核心环节实现：轮询、中断和DMA三级跳

5.1 轮询模式：简单直接，适合日志输出

如果只是调试日志，轮询模式最省心。核心函数就是HAL_UART_Transmit。我封装了一个log函数：

void log_msg(const char *fmt, ...) { char buf[128]; va_list args; va_start(args, fmt); vsnprintf(buf, sizeof(buf), fmt, args); va_end(args); HAL_UART_Transmit(&huart1, (uint8_t *)buf, strlen(buf), 0xFFFF); }

这里有几个细节：

vsnprintf是C标准库提供的格式化输出函数，比sprintf安全，因为限制了目标缓冲区大小，防止格式化超长导致栈溢出。
缓冲区大小选择128字节。如果日志内容经常超过128，建议改成分段发送，比如先发送前半段再发后半段。不要无限增大栈数组，虽然C542有挺大的SRAM，但裸机工程里栈大小通常设置为0x400或0x800，一个128字节的局部数组其实有点占空间。不过实测平时也够用。

这个函数用起来很顺手：

log_msg("Temp: %d, Humi: %d\r\n", temp, humi);

丢进中断里会有风险吗？我在写日志不多的情况下实测过，低负载下没问题，但如果日志量大，建议把log_msg包装一层中断安全锁。

5.2 中断接收：用回调函数处理单字节

接收方面，如果想做成“来一个字节，处理一个字节”，HAL库最标准的方式是：

uint8_t rx_byte; HAL_UART_Receive_IT(&huart1, &rx_byte, 1);

然后在回调函数里处理：

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART1) { process_byte(rx_byte); HAL_UART_Receive_IT(&huart1, &rx_byte, 1); // 重新启用下一次接收 } }

这个方式在C542上实测非常好用，中断响应及时，CPU占用低。但有一个必须注意的坑：HAL库的UART接收中断是一次性的，接收完指定的字节数后，不会再自动开启下一次接收。如果你忘记在回调里再次调用HAL_UART_Receive_IT，串口就只能收到第一个字节，后面的数据全部丢失。这个坑在F1时代就有，各型号都一样，但我发现很多新手在C542上仍然会踩。

另外，如果你的接收数据是变长的，比如一条命令的长度从几个字节到几十个字节不等，怎么知道一条命令结束了呢？常用的方式是空闲中断（IDLE），也就是串口线空闲一段时间后，触发中断，此时把缓冲区里的数据当一条完整消息处理。STM32C542的UART外设支持IDLE检测。但HAL库默认没有把IDLE中断暴露给用户，你需要自己处理：

__HAL_UART_ENABLE_IT(&huart1, UART_IT_IDLE);

然后在中断服务函数里判断：

void USART1_IRQHandler(void) { HAL_UART_IRQHandler(&huart1); if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(&huart1); process_rx_line(); } }

注意IDLE标志要在UART_IRQHandler之后判断，因为HAL库在处理完自己的事件之后，会清掉某些标志位。实测发现，如果你调换了顺序，IDLE标志可能已经被清零，你就永远等不到“一条完整消息结束”的通知。

5.3 DMA接收：从“收到多少读多少”到“收满一帧再处理”

如果你想在C542上做更大数据量的串口接收，DMA是必须掌握的方式。DMA接收需要两个缓冲区：一个给UART硬件搬运数据，一个给应用程序处理数据。典型的应用就是双缓冲乒乓：

#define BUF_SIZE 256 uint8_t dma_buf1[BUF_SIZE]; uint8_t dma_buf2[BUF_SIZE]; HAL_UART_Receive_DMA(&huart1, dma_buf1, BUF_SIZE);

当DMA收到256字节后，触发HAL_UART_RxCpltCallback，此时你切换到dma_buf2继续接收，同时处理dma_buf1中的数据。这个机制能保证数据不丢，但要注意：如果DMA接收256字节需要的时间很长，而中途产生了空闲，你可能希望先把已经收到的部分数据拿出来处理，这时候就要结合空闲中断来做了。

DMA+IDLE这种组合在STM32圈子里是很经典的“不定长接收方案”，网上很多代码，但大多是针对F1/F4的。C542上DMA的请求映射和中断向量表不同，建议直接看HAL库自动生成的DMA初始化代码，不要手抄旧代码。另外，C542在使用CubeMX生成DMA代码时，要留意DMA的通道优先级设置。如果优先级太低，在串口高速接收时可能被其他DMA请求抢占，导致数据错位或丢失。

5.4 发送完成回调的边界情况

用DMA发送时，HAL_UART_TxCpltCallback是最关键的回调。它标志着一帧数据已经完整发送出去。但要注意一个边界情况：在C542上，如果发送时开启了FIFO模式，DMA发送完成中断触发时机可能比最后一个字节真正从引脚上发出去要早。因为数据还在FIFO里排队。如果你在回调里立刻切换GPIO模式（比如RS485方向控制），可能会截断最后一个字节。

解决方法是：在FIFO模式开启的情况下，不要仅依赖DMA发送完成回调，还要等待USART的TC标志。HAL库提供了一个函数HAL_UART_GetState，你可以轮询状态直到不再处于HAL_UART_STATE_BUSY_TX，或者直接读huart->gState。实测下来，先清TC标志，再等TC置位，是靠谱的做法：

__HAL_UART_CLEAR_FLAG(&huart1, UART_FLAG_TC); while (!__HAL_UART_GET_FLAG(&huart1, UART_FLAG_TC));

这样写虽然有一点点阻塞，但能保证最后一次数据确实从引脚送出去了。

6. 实测遇到的高频问题：乱码、卡死、输出格式异常一次说清

6.1 串口完全没有输出的排查清单

每次换新板子，我都会按一个固定的顺序排查串口问题，效率极高，分享出来：

检查USB转TTL模块的TXD是否连接到MCU的RX引脚（PA10），RXD是否连接到MCU的TX引脚（PA9）。这两个接反是最大的坑，很多模块上标了TXD/RXD，但初学者容易把“TXD接TXD”想当然，结果是完全没有任何输出。
检查是否共地。USB转TTL模块的GND必须和STM32C542开发板的GND相连，否则电平参考点不一致，输出大概率乱码或完全无反应。
测引脚电平。用示波器或万用表量PA9引脚，如果板上电后引脚有跳变，说明UART至少在工作；如果一直是高电平，可能是GPIO复用配置问题或时钟没使能。
核对波特率。串口助手设置的波特率必须和初始化代码完全一致。如果你初始化时忘了填115200，用了9600，输出自然是乱码。
检查cube生成的时钟树。用逻辑分析仪看TX引脚有没有脉冲，没有则回查PCLK2是否正常输出，时钟配置是否卡在SystemClock_Config里。
检查是否被其他外设抢占引脚。比如PA9/PA10如果同时被配置成GPIO输出或别的复用功能，UART也会失效。

实测有一次我花了一个小时，最后发现是CubeMX里不小心把PA9也勾选成了GPIO_Output。CubeMX允许一个引脚有多个复用选项，但它在生成代码时不会警告你冲突。遇到问题先回头检查引脚配置是一个高效习惯。

6.2 printf输出乱码、丢字符、重复字符

乱码的根源，绝大部分是波特率误差，其次是电平不匹配。你手算过时钟配置后，如果误差在0.5%以内，不会乱码；超过了2%，长帧数据（比如含很多字符的日志）就会开始在中间位置出现错位，表现为部分字符乱码。

丢字符则常见于以下场景：

你在中断里调用printf，发送阻塞时间太长，导致其他中断被推迟，看起来像是丢数据。
你用的USB转TTL模块质量不好，没有流控，在高波特率下缓冲区溢出。
你的程序在fputc里用的HAL_UART_Transmit超时时间太短（比如10ms），发送未完成就超时返回，后续字节被丢弃。

重复字符是FIFO和DMA配合时偶尔出现的，主要原因是发送缓冲区被修改得太快，DMA读取到的数据和实际想发的数据不一致，导致同样的字节被发两次。改用双缓冲可以解决。

6.3 printf输出了，但开发板运行变慢

这个问题容易被忽视：printf是一个同步、阻塞调用，尤其在你还没有用DMA的情况下，HAL_UART_Transmit会等待每个字节发送完成。115200波特率下，每字节大约86.8微秒，一个100字节的日志就要8.7毫秒。如果你的日志打印频率是每10毫秒一条，光printf就占了87%的CPU时间，运行变慢就不奇怪了。

优化方向有三个：

换更快的波特率，比如460800或921600。C542的UART在8倍过采样模式下，可以跑到更高波特率，但需要匹配的是USB转TTL模块能不能稳定支持。
减少日志量，把调试日志分级，只有开发阶段才打印全量信息。
使用DMA发送，把日志发送放到后台，CPU只在发送启动时做一次配置。这是最终方案。

6.4 经典但鲜有人提的一个坑：PA9/PA10和SWD复用

C542这颗芯片，如果你的终端设备对引脚复用比较敏感，注意PA13、PA14是SWDIO、SWCLK，通常不能动。PA9/PA10本身不是调试口，但在某些开发板设计中，PA9可能连接了板载的其他功能，比如LED、按键或CAN收发器，导致你接USB转TTL时信号被拉低或干扰。

我手上这块板子，PA9位置附近同时焊了一个跳线帽，一开始我还以为只是普通排针，后来才发现它连着板载CAN收发器的TXD引脚。结果就是串口输出时有时无，后来拔掉跳线帽就好了。遇到“串口输出奇怪地不稳定”的情况，先查原理图，看看PA9/PA10旁边还有什么外设。

7. 一点小总结：关于C542这份UART经验的延展

做了这么多配置和实验，我个人最大的感受是：STM32C542的UART配置工具链已经非常成熟，HAL库可以让你在5分钟内跑通基本收发，但能走多远，取决于你是否理解时钟树和底层标志位的语义。

如果你接下来要在C542上做低功耗设备，可以继续往两个方向探索：一是用UART的WUF（Wakeup from Stop Mode）功能，让串口在STOP模式下保持可唤醒；二是用LPUART替代普通USART，这样在低功耗模式下依然能接收数据。这两个功能在C系列上都有硬件支持，实际代码做法和F系列有一些差异，等我把低功耗部分跑通了再单独写一篇。

最后分享一个我自己的调试小习惯：把开发板上的USART1固定当作调试串口，所有日志默认都走这里，应用程序的通信串口另找一组UART。这样代码里只需要一套printf重定向逻辑，排查问题的时候也只需要盯一个串口，非常省心。

我试过最复杂的场景是“UART1接GPS模块，UART2接4G模块，同时用printf打日志到UART3”。如果不加区分，三个串口的日志混在一起，完全没法调试。用这套统一日志方案之后，一切回归简单：所有设备的数据都进同一个日志流，按时间戳排序，一屏看清楚系统状态。希望这篇UART配置与printf重定向的记录，能帮你少踩几个坑。