1. 拿到新板子，先把串口用起来
1.1 串口打印解决的不只是“输出”
这周在调一块STM32C542R的板子，固件能烧、LED能闪，但串口助手那边一点反应都没有。我猜不少人在新芯片上会撞到类似的情况——程序不知道跑没跑、跑到哪里、变量值对不对，全凭猜。这种时候，串口打印就是第一根探针。
STM32C542R这颗料属于ST后面推的C5系列，Cortex-M33内核，很多人还不熟。但不管内核怎么换，开发调试的第一步几乎永远是先把串口打印拉通。原因很简单：点灯只能告诉你“代码到这了”，串口却能把“代码里发生了什么”完整传出来。尤其裸机阶段，没有RTOS的日志系统，也没有JLINK的实时变量监控，printf就是最直接的手段。
我在正式写外设驱动之前，都会先花十分钟把调试串口搞定。这一步看起来简单，实际上牵扯到引脚映射、时钟树、外设初始化、printf重定向、串口助手连接方式，任何一个环节没对齐，输出就是黑的或乱的。这篇就按我实际的配置顺序，从头到尾捋一遍。
1.2 先查引脚映射，再打开CubeMX
很多教程一上来就让你打开CubeMX选引脚，但我建议顺序反过来：先翻数据手册，把调试串口的引脚映射确认了再动手。
以USART1为例，最常用的映射是TX=PA9、RX=PA10。但是STM32C542R这类新料，引脚功能映射不一定和F103那条老线完全一致，同一个外设在不同的封装上可能有多个Alternative Function映射，CubeMX里引脚的颜色也不总是一眼就能看懂。所以我的习惯是：
- 打开数据手册的“Alternate function mapping”章节，找到USART1_TX和USART1_RX可能的引脚。
- 确认你当前封装上有这几个引脚，并且没有和板子的其他功能（LED、按键、外部Flash）冲突。
- 再去CubeMX里把对应引脚设为串口功能。
这么做的好处是少走弯路。曾经我在一块板子上默认用了PA9/PA10，结果PA10被板上一个电路接死了，调试口只有发没有收。如果当时先查引脚，就不会花一下午去怀疑代码。
1.3 USB转TTL：注意电平、地线和交叉
硬件连接这部分看着基础，出问题概率却最高。USB转TTL模块和STM32C542R之间需要接三根线：TX、RX、GND。
关键点有三个：
- 电平必须匹配。C5系列和绝大多数STM32一样，串口引脚是3.3V电平，USB转TTL模块要选3.3V供电那种，千万别把5V直接怼到串口引脚上。模块上的跳线帽如果可以让VCC输出3.3V或5V，务必确认输出3.3V。
- TX和RX要交叉。模块的TX接芯片的RX，模块的RX接芯片的TX。这是新手最常见的错误，因为两端都标着TX/RX，很容易做成TX接TX。
- GND必须共地。没有共地，串口电平就没有参考点，数据根本对不齐。我见过有人只接TX和RX不接GND，输出全乱码，就是这个原因。
接好线之后，设备管理器里会多出一个COM口。打开串口助手，波特率先设成115200，8位数据、无校验、1位停止位，这个是后面CubeMX里的默认配置，先保持一致。
2. 时钟树与波特率：源头错了必乱码
2.1 波特率的“准确性”取决于总线时钟
串口打印出错时，我第一个怀疑的永远是时钟。波特率不是你想设多少就正好多少，它是由串口所在总线的时钟频率分频得到的。
比如USART1在STM32的很多系列上挂在APB2下面，如果APB2时钟不是整数，BRR寄存器的分频值就会产生误差。误差在可接受范围内（一般小于1%~2%）问题不大，但如果APB2时钟配置得比较离谱，波特率误差超过一定值，接收端解出来的位就不对了，表现出来就是乱码。
C5系列的新时钟树比F1复杂不少，HSI、HSE、MSI、PLL各级分频倍频链路很长。CubeMX虽然能自动算，但前提是你得告诉它你板上的外部晶振是多少MHz。我通常会在RCC配置里选择Crystal/Ceramic Resonator，并填好HSE的实际频率。如果你图省事直接用HSI内部振荡器，也不是不行，只是后面如果涉及USB、以太网这类对时钟精度敏感的外设，迟早要回头改。
2.2 在CubeMX里把时钟树补全
新建工程选择STM32C542R之后，CubeMX左侧会有一堆外设选项。我们需要做的：
- 在System Core里找到RCC，把High Speed Clock（HSE）设为Crystal/Ceramic Resonator。
- 把Debug设为Serial Wire，否则后面烧录器可能因为引脚被复用而连不上（这个坑也比较常见，我一般上来就设好）。
- 在Connectivity里找到USART1，勾选Asynchronous异步模式。
然后切到Clock Configuration页面，观察APB1、APB2的总线频率。如果你的USART1挂在APB2上，就盯着APB2的值。CubeMX里可以左右调节各分频系数，尽量让串口总线时钟保持一个整数值，比如80MHz、160MHz之类，这样计算波特率时误差会小很多。
我之前遇到过一个很隐蔽的情况：CubeMX自动生成的时钟树里，APB2外设时钟设成了一个带小数点的值，串口115200波特率出来实际波形频率差了将近两个百分点，单独看好像不大，但连续传几十字节之后接收端就开始掉位。后来把PLL的分频系数调了一下，让APB2变成整数频率，乱码立刻消失。
3. 从CubeMX到代码生成：串口初始化怎么才算“配好”
3.1 外设参数面板怎么填
CubeMX里点开USART1的Configuration，会看到Parameter Settings面板。这里我默认的填法：
- Mode：Asynchronous
- Baud Rate：115200
- Word Length：8 Bits
- Parity：None
- Stop Bits：1
如果只是调试打印，这些参数已经够了。硬件流控（Hardware Flow Control）保持Disable，它对应的是CTS/RTS引脚，我们不用。方向（Direction）选TX and RX，虽然只打印的话理论上只开TX就行，但我习惯把RX也开上，因为后面可能要写命令交互。
再往下可以看到Configuration里的NVIC Settings。如果是轮询方式调用HAL_UART_Transmit，可以不开中断；但如果之后想用串口接收，建议这里把USART1 global interrupt勾上。优先级我一般给3或5，不要给0，因为调试串口优先级太高容易把系统实时性打乱。
3.2 生成代码之后，最少需要动哪几处
CubeMX生成工程之后，main函数里已经自动创建了MX_USART1_UART_Init()的调用。正常情况下代码已经可以往串口塞数据，比如：
HAL_UART_Transmit(&huart1, (uint8_t*)"Hello\r\n", 7, 1000);这一行能把字符串发出去。但注意，它每次要指定长度和超时时间，用起来还是麻烦。我们真正想要的是直接printf("Hello")，这就要做重定向，我放到下一节专门讲。
除此之外，生成代码里暂时不用改别的地方。有一点值得注意：如果你后面想在中断里打印日志，千万不要在中断回调函数里直接调用HAL_UART_Transmit的阻塞版本，它可能会卡死等发送完成。正确做法是设一个标志位，在主循环里处理，或者改用DMA发送。这个我最后一部分会再提。
4. printf重定向：把标准库变成你的日志工具
4.1 三个开发环境各自的写法
C标准库的printf最终会调用一个底层的字符输出函数。我们的思路就是把这个底层函数重定向到串口上。
在MDK（Keil）的ARMCC环境下，最常用的做法是重写fputc：
#include <stdio.h> int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; }当printf执行的时候，每个字符都会经过fputc发送到USART1，打印就通了。注意强制转成uint8_t指针时取的是ch的地址，一次发一个字节。
如果你用的是STM32CubeIDE或者任何GCC工具链，环境里没有fputc这个约定，需要重写的是_write函数：
int _write(int file, char *ptr, int len) { HAL_UART_Transmit(&huart1, (uint8_t *)ptr, len, 0xFFFF); return len; }GCC的printf最终会调用_write，把整块缓冲区一次性交给我们发出去，这样效率还更高一些。如果用的是IAR，则通常是重写fputc或__write，具体看IAR版本和链接库配置。
4.2 半主机模式是个大坑
MDK下用printf最常见的“代码没问题但串口没输出”原因就是半主机模式。半主机是ARM处理器上一种把C库输入输出重定向到调试器的机制，printf会先尝试往调试器发数据。调试器没接或者没使能这个功能时，程序就卡在某个底层等待状态，现象是：程序像死了一样，串口一个字节都不出。
解决办法有两条路：
最简单的是在MDK的Options for Target -> Target标签页里勾选Use MicroLIB。MicroLIB是一个精简版C库，默认不走半主机，配合fputc重定向即可工作。
如果不想用MicroLIB，可以在代码里关掉半主机并定义底层需要的符号：
#pragma import(__use_no_semihosting) struct __FILE { int handle; }; FILE __stdout; FILE __stdin; void _sys_exit(int x) { x = x; while(1); } int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; }这段代码在F1时候我就一直在用。其实没那么玄，就是告诉链接器“请不要帮我实现那些调试相关的半主机功能”。如果你第一次配串口打印，建议直接勾MicroLIB，省心，后面碰到浮点格式化问题再回头再说。
4.3 浮点打印和体积问题
你可能还会遇到一个经典问题：printf打印整数没问题，打印浮点数时什么都没有，或者显示成一个奇怪的空格式。这是MDK标准库默认不支持浮点格式化处理导致的，为了省空间，printf的浮点支持是默认关闭的。
在MDK里可以在Options for Target -> Target标签页勾选“Use MicroLIB”时，MicroLIB默认也不支持浮点。这时候有两个选择：
- 把浮点转成整数打印，例如：
float temp = 25.6f; printf("temp=%d.%d\r\n", (int)temp, (int)((temp - (int)temp) * 10));- 或者自己重写一个浮点格式化函数。大多数调试场景下，方法一已经够用。
对了，还有一个体积问题。开启完整printf浮点之后，固件体积会明显增加几KB到十几KB，对C5这种Flash容量充足的新片子上其实无所谓，但如果做产品需要控Flash，就该思考是不是所有日志都用printf。我后面会讲分级的日志管理思路。
5. 实测中常见的“没输出”和“乱码”排查链路
5.1 乱码：优先怀疑时钟和波特率
串口助手打出乱码，很多人第一反应是换波特率，在9600、115200、460800之间来回试，运气好能试出来，但我建议按下面的顺序排查：
第一步看时钟树。CubeMX时钟配置页里APB1/APB2的时钟频率是不是整数。不是整数的话，优先调整PLL分频系数。具体做法是把HSE频率填对，再让PLL输出频率和APB分频后的值尽量落在整数上。C5系列时钟树可以图形化调节，左上角有每次调整后的频率预览。
第二步看串口助手波特率是否和CubeMX里的Baud Rate一致。这个最简单，但也最容易忽略。有些串口助手每次打开会默认9600，和你代码里115200不一致，自然乱码。
第三步用示波器或逻辑分析仪看TX引脚的波形。正常115200波特率下，一个数据位大约8.68us。如果测出来的实际位宽偏差很大，说明总线时钟配置有问题。这个手段比盲试波特率靠谱得多。
还有一个常见情况：板子上电瞬间打印出来几个乱码字符，后面恢复正常。这个大概率是电源还没有稳定，芯片复位后GPIO在配置完成之前，RX或TX引脚处于不确定状态，USB转TTL模块收到了电平跳变噪声。真正的程序输出其实是正常的。这种情况不需要过度处理，如果追求完美，可以在printf初始化代码前加几百毫秒延时，或者确保电源稳定后再连接串口助手。
5.2 没输出：从TX引脚往回查
完全没输出，我用这套链路查，效率最高：
先确认为什么没有。在main函数开头，HAL_Init之后、整个时钟树和外设初始化完成之前，直接用HAL_UART_Transmit发一个固定字符串，看有没有输出。如果有，说明串口初始化ok，问题在之后的流程或者printf重定向；如果没有，说明串口本身或者硬件链路有问题。
量TX引脚的静态电平。串口在空闲状态时，TX应该保持高电平。如果用万用表或者示波器量到TX一直是低电平，多半是引脚模式配错了，或者引脚被其他外设占用了。
检查引脚有没有被复用冲突。CubeMX里如果某引脚被两个外设同时选中，会有红色警告。我曾经在配置SPI的时候不小心把PA9分配给别的功能，USART1_TX就不工作了，而且代码编译不会报错。
检查printf重定向的底层函数是否真的被链接进去了。很多编译优化级别下，如果代码里没有显式调用printf，链接器可能把fputc优化掉。可以在初始化后加一句printf("test\r\n")，确认调用存在。
检查是否真的进入主循环。如果是系统卡死在前面，比如某个外设初始化HAL_TIMEOUT，那串口自然没东西。这种时候可以配合Semihosting或者调试器里的breakpoint判断代码位置。
5.3 串口助手本身也有讲究
串口助手不是随便选一个就能用好的。首先是编码格式，默认大家都用ASCII/UTF-8，如果你发送中文字符，串口助手的显示编码和源文件编码不一致就会乱。调试环境下我一般都只打英文和数字，省得编码问题干扰判断。
其次是换行符。C代码里的\r\n和串口助手的显示设置要对应。有些串口助手默认“发送新行”只发\r或只发\n，接收端显示就会变成阶梯式换行。嵌入式printf建议统一用\r\n，因为很多串口终端没有自动加回车。
最后是流控。如果你的USB转TTL模块或串口助手里打开了RTS/DTS流控，而硬件上没接CTS/RTS线，很容易出现“只能发不能收”的诡异现象。排查的时候可以看串口助手右下角的状态指示，如果一直显示CTS信号无效，基本就是流控开关被误开了。
6. 给串口打印加点工程思维
6.1 带时间戳的日志
基础printf能用了之后，我建议你做一个简单的日志封装，至少包含时间戳和级别两个信息。
在裸机程序里拿到当前时间戳通常依赖SysTick。STM32 HAL库本身会维护一个uwTick计数器，每隔1ms加一次。我们可以直接用它：
extern volatile uint32_t uwTick; void log_info(const char *msg) { printf("[%010lu] %s\r\n", uwTick, msg); }这样打印出来的日志会自带毫秒时间点。某个驱动初始化耗时过长、某个状态切换发生的时间点，一眼就能看出来。真实项目里这个习惯会帮你省大量时间。
如果想打印函数名和行号，GCC和MDK都支持ANSI C的__FILE__和__LINE__宏，可以做一个带位置的宏：
#define LOG_INFO(fmt, ...) \ do { printf("[%s:%d] " fmt "\r\n", __FILE__, __LINE__, ##__VA_ARGS__); } while(0)6.2 长日志的分块处理
HAL_UART_Transmit默认是阻塞发送，如果日志字符串很长，比如几百字节，发送过程会占用CPU很久。这在调试阶段无所谓，但在实际功能调试时，如果发送期间正好错过了外部中断，你会看到一个假象：主逻辑“卡顿”了。
解决思路有几个。最简单的是减少日志量，调试只打印关键状态变化，不打印高频数据。中等方案是设置一个发送缓冲区，通过DMA把日志交给外设发送，CPU在DMA传输期间可以继续跑。最高效的方案是使用一个环形缓冲区加空闲中断，把日志生产和消费解耦。
对于C5系列这种新料，DMA通道资源池配置和F1不一样，CubeMX里生成DMA配置也要注意通道和请求映射，这个我后面写DMA专门笔记再展开。调试阶段我强烈建议先用阻塞发送，把程序逻辑调对了再说优化，过早优化调试代码只会增加问题排查的复杂度。
6.3 从“打印”到“轻量级调试协议”
串口打印只是单向的。等你想在板上动态修改参数或者强制状态机跳转，就得在打印的基础上加一个简单的命令解析。一个很常见的模式是：串口助手发送一条以\r\n结尾的ASCII命令，MCU的串口接收中断把收到的字符放进缓冲区，主循环里解析匹配，执行对应操作后把结果打印出来。
这样你就能实现“在命令行里输入led=1然后回车，板子上的LED亮起来”的效果。对于驱动验证和硬件调试，这种交互方式非常有用，比反复改代码重新烧录高效得多。
不过这就是下一阶段的活了。我先把串口打印这部分踩过的坑和经验完整记下来，希望对你也有用。
