简介基于STM32F103C8T6HAL库STM32CubeMX的UART串口通信数据收发完整工程面向嵌入式初学者、STM32入门者及需要快速搭建串口通信原型的开发者重点解决CubeMX外设配置、HAL库驱动调用和收发验证等问题。压缩包共146个文件包含47个h头文件、20个c源文件、62个编译中间文件o/d/crf、1个ioc配置工程、1个hex可执行文件以及其他辅助调试内容约4.31MB目录对应Keil工程结构便于直接打开查看或二次修改。工程覆盖系统时钟HSEPLL至72MHz、USART引脚映射与波特率设置、HAL_UART_Transmit/HAL_UART_Receive收发调用并保留NV_USART相关实现及map/axf等构建产物方便对照初始化流程、调试排错和进一步扩展。已有6056人浏览学习适合直接在开发板上烧录验证也可作为串口通信项目的基础模板复用对掌握嵌入式通信基础和理解HAL库抽象层均有实际参考价值。1. 串口通信调不通的痛点这套基于STM32F103C8T6的资源能做什么调试单片机板子时最怕撞上的场景串口助手波特率反复调了三次发一个字节过去回显是满屏乱码甚至完全没反应。这套资源就是用STM32CubeMX加HAL库把STM32F103C8T6的UART串口通信数据收发从头到尾跑通解压后按步骤烧录回显、中断接收、数据互发都能在最小系统板上落地。项目核心解决的是“串口为什么不通”和“收发到底怎么组织”这两件事CubeMX完成引脚和时钟的图形化配置生成的HAL库代码处理寄存器细节开发者只需要在用户代码区写发送和接收逻辑。它适合刚接触STM32的嵌入式初学者也适合备赛、做上位机联调时需要一个能直接改的串口基座工程的开发者。拿到手里第一件事不是看代码而是先读工程里的.ioc文件和串口初始化逻辑确认它用的是哪一个USART、挂在哪个时钟树上。下面按这个顺序拆。2. 这份串口资源到底做了什么从板卡选型到工程目录拆解2.1 为什么是STM32F103C8T6加HAL库加CubeMX这三件套STM32F103C8T6是一颗Cortex-M3内核的单片机主频最高72MHz片上64KB Flash和20KB RAM集成三个USART。做串口通信这类基础外设验证它成本低、资料多、烧录方式灵活用一块蓝板加一个USB转TTL模块就能开始干活。HAL库在项目里的价值是把底层寄存器访问封装成结构体操作。想改波特率改huart1.Init.BaudRate想切换收发模式改huart1.Init.Mode。相比直接操作寄存器HAL库的代码更接近“填表”对第一次接触STM32的人来说出错时看API名就能猜出大概。CubeMX负责生成初始化代码包括时钟树、GPIO复用和中断配置生成的工程直接拖进Keil或者STM32CubeIDE就能编译。这套组合也有代价。HAL库会引入大量中间层最终编译出的固件体积比标准库大。F103C8T6只有64KB Flash只做串口收发时完全没有压力如果后面要塞进复杂的协议栈、显示屏驱动加多个传感器算法就要注意Flash占用。打算深入做产品化的场景下我一般会建议把HAL库裁剪或者局部改用LL库但作为学习资源和二次开发基座HAL库的易读性更重要。另外要留意C8T6的中容量定位。CubeMX生成工程时如果目标芯片选错成高容量型号代码同样能编译但链接脚本的Flash布局不同烧录后可能出现启动异常。这类资源拿到手后我第一件事是看芯片顶面丝印确认后缀是C8T6再开始配工程。2.2 解压后先看哪里CubeMX工程的目录结构与文件分工资源解压后是CubeMX生成的标准工程布局。先找到.ioc文件它是整个工程的“配置快照”双击打开能回到图形化界面重新配置外设重新生成代码时CubeMX只覆盖自动生成区域手工写在USER CODE BEGIN和USER CODE END之间的代码会保留这是二次开发时最重要的一个约定千万不要把代码写到这两个标记之外。stm32f103c8t6_uart/ ├── stm32f103c8t6_uart.ioc // CubeMX 配置文件双击可重新生成工程 ├── Core/ │ ├── Inc/ │ │ ├── main.h // 主头文件存放全局声明 │ │ └── usart.h // USART1 句柄声明 │ └── Src/ │ ├── main.c // 主循环、发送/接收逻辑入口 │ ├── usart.c // MX_USART1_UART_Init 初始化 │ ├── gpio.c // 引脚时钟和模式配置 │ └── stm32f1xx_hal_msp.c // 外设底层的时钟、GPIO、NVIC 配置 ├── Drivers/ │ ├── CMSIS/ │ └── STM32F1xx_HAL_Driver/ // HAL 库源码 ├── MDK-ARM/ // Keil 工程.uvprojx 从这里打开 │ └── stm32f103c8t6_uart.uvprojx └── README.md // 资源自述和运行说明这个目录结构里真正需要改的是Core/Src/main.c和usart.c。usart.c里是CubeMX生成的MX_USART1_UART_Init()配置项用结构体赋值完成main.c里是用户逻辑包括初始化后的发送语句、主循环轮询和中断回调。stm32f1xx_hal_msp.c比较容易被忽略它承担外设底层初始化比如开启USART1时钟、配置PA9/PA10为复用推挽输出、设置NVIC中断优先级很多“初始化成功但串口不动”的问题最后都出在这里。usart.h里声明了外部句柄extern UART_HandleTypeDef huart1;main.c和用户文件都能直接引用它。HAL_UART_HandleTypeDef内部包含Instance、Init、gState、RxState这些字段调试时可以在Keil的Watch窗口直接看gState状态值判断外设当前是否处于空闲或忙碌状态。提示CubeMX重新生成代码时只会保留USER CODE BEGIN与USER CODE END之间的内容业务代码务必放在这两个标记之间。2.3 串口资源选址USART1的引脚、总线时钟与中断关系F103C8T6的USART1默认映射到PA9和PA10PA9是TX发送引脚PA10是RX接收引脚。USART1挂在APB2总线上APB2的最高频率和系统主频相同都是72MHz这也是为什么配置完时钟树后串口波特率计算没有额外分频误差的主要原因。USART1的中断入口是USART1_IRQn。CubeMX在NVIC Settings里使能USART1 global interrupt后会在stm32f1xx_it.c中生成USART1_IRQHandler由它调用HAL库的HAL_UART_IRQHandler(huart)完成中断分发。中断触发条件包括RXNE接收寄存器非空、TXE发送寄存器空、ORE溢出错误等HAL库会把这些事件分类再回调到用户可重写的弱函数里。波特率由USARTDIV分频值决定F1的USART1可以用72MHz作为输入时钟。115200对应的分频值是72MHz除以115200HAL库会自动算好分频值写入BRR寄存器。如果把USART1误配到APB1的36MHz时钟上同一个波特率设置算出的分频值差一倍通信自然对不上。这也是排查乱码时先问“你的USART挂在哪个总线”的原因。如果是USART2或USART3对应引脚、挂载总线、中断向量都不一样。改资源里的通信口时要同时改.ioc里的引脚分配、时钟树里对应总线的分频系数和NVIC配置只改代码不改引脚映射是跑不起来的。现在这份资源只用了USART1理解了这一套对应关系后面换串口只是重复同样的配置流程。3. 核心模块拆解从CubeMX配置到中断收发的完整链路3.1 CubeMX配置阶段时钟树、USART1和NVIC的填表过程先看CubeMX侧需要确认的配置项。RCC里启用HSE外部高速时钟选择Crystal/Ceramic Resonator外部晶振按8MHz算时钟树里PLL Source选HSE把PLL倍频系数调到9得到72MHz的系统主频APB1 Prescaler选/2让APB1保持在36MHzAPB2 Prescaler保持/1这样USART1能拿到完整的72MHz时钟。USART1的配置页选择Asynchronous异步模式引脚自动分配PA9的USART1_TX和PA10的USART1_RX。常用参数是波特率115200、8位数据长度、无校验、1位停止位、无硬件流控这些参数要和上位机串口助手完全一致差一位停止位或者勾上了流控就会出现能发不能收或者乱码的怪问题。NVIC设置里使能USART1全局中断这是后面做中断接收的前提。CubeMX生成的初始化代码长这样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(); } }BaudRate、WordLength、StopBits、Parity这几个字段直接决定物理层格式。上位机串口助手里的设置要和这里一一对应比如这里UART_PARITY_NONE上位机就必须关掉校验。HwFlowCtl默认关闭硬件流控如果开了RTS/CTS而USB转TTL模块不支持硬件流控数据发送会一直等待握手信号看起来就像串口卡死。底层初始化在HAL_UART_MspInit里完成包括使能时钟、配置GPIO复用、设置中断优先级void HAL_UART_MspInit(UART_HandleTypeDef *huart) { GPIO_InitTypeDef GPIO_InitStruct {0}; if (huart-Instance USART1) { __HAL_RCC_USART1_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitStruct.Pin GPIO_PIN_9 | GPIO_PIN_10; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; // 复用推挽TX/RX 都按复用模式配置 GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); HAL_NVIC_SetPriority(USART1_IRQn, 0, 0); HAL_NVIC_EnableIRQ(USART1_IRQn); } }PA9和PA10都配置成GPIO_MODE_AF_PP复用推挽输出模式这句话很反直觉有人把RX引脚配成输入模式导致收不到数据。事实上在F1系列里USART的TX和RX引脚都要配置为复用推挽硬件的收发方向由USART外设自己控制不需要手动配置输入输出方向。HAL_NVIC_SetPriority(USART1_IRQn, 0, 0)设置抢占优先级0子优先级0如果后面加了更多中断要注意优先级分组方式保持一致。3.2 发送逻辑阻塞发送与printf重定向的两种写法发送数据最直接的方式是HAL提供的HAL_UART_Transmit属于阻塞式发送发送期间CPU一直等发送完成。初始化完成后发一串欢迎信息uint8_t tx_buf[] STM32 UART Ready\r\n; HAL_UART_Transmit(huart1, tx_buf, sizeof(tx_buf) - 1, 1000);参数里第一个是串口句柄第二个是待发送数据指针第三个是发送长度第四个是超时时间。这里用sizeof(tx_buf) - 1是为了把结尾的\0去掉字符串数组在定义时自动多出了一个结束符串口发送时不需要发\0。超时时间单位是毫秒1000表示最多等1秒如果1秒内没发完就返回HAL_TIMEOUT主程序可以用返回值判断通信是否异常。但实际调试时更常用printf往串口打数据。HAL库没有自带printf支持需要自己做fputc重定向把标准输出重定向到USART1#include stdio.h int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; }在Keil里使用MicroLIB或者在STM32CubeIDE里启用newlib-nanoprintf就能直接通过串口输出。这个重定向文件里如果同时存在多个串口fputc里可以按调试需要切换句柄但同一时刻只能有一个目标。重定向之后printf(count %d\r\n, count);就成了嵌入式里最常用的日志手段比LED闪烁和仿真器断点都要直观。3.3 接收逻辑单字节中断接收的接力写法接收侧不能在主循环里调用HAL_UART_Receive死等那样CPU会在阻塞中空转其他任务全部卡死。惯用且好用的做法是用HAL_UART_Receive_IT启动一次中断接收每收到一个字节触发一次回调回调处理完之后再次调用HAL_UART_Receive_IT启动下一轮接收形成接力。先把接收缓冲和标志位定义在文件顶部uint8_t rx_byte 0; // 每轮中断接收的单个字节 uint8_t rx_flag 0; // 收到新数据的标志位初始化时启动第一次接收HAL_UART_Receive_IT(huart1, rx_byte, 1);HAL_UART_Receive_IT的第二个参数是接收缓冲区地址第三个参数是期望接收的字节数。传1表示每接收完1个字节就触发一次HAL_UART_RxCpltCallback回调。使用时要特别注意这个函数只是启动接收不是轮询接收如果上一次接收还没完成重复调用会返回HAL_BUSY。然后在用户代码区重写回调函数void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { rx_flag 1; // 通知主循环有新数据 HAL_UART_Receive_IT(huart1, rx_byte, 1); // 立刻接力下一轮接收 } }回调里只做两件事置标志位、重新启动下一次接收。主循环通过轮询rx_flag来处理数据比如原样回显while (1) { if (rx_flag) { rx_flag 0; HAL_UART_Transmit(huart1, rx_byte, 1, 100); } }这里容易踩的坑点在于回调执行上下文是中断。回调里不要写耗时太长的操作更不要在里面调用printf或者做大数据拷贝中断处理时间过久会延迟下一次中断响应高速收发时会出现丢字节。重启动接收的调用必须放在回调末尾如果在主循环里重新调用HAL_UART_Receive_IT中间会存在一段空窗期这期间到达的字节会直接丢失。3.4 一条数据从进入到返回的完整时序把上面几段拼起来一条完整的数据链路是这样的上位机通过USB转TTL模块把字节送到PA10引脚USART外设移位寄存器逐位接收置起RXNE标志中断控制器响应USART1全局中断进入USART1_IRQHandlerHAL库的HAL_UART_IRQHandler识别事件类型是RXNE调用UART_Receive_IT把接收寄存器里的字节拷贝到rx_byte然后触发HAL_UART_RxCpltCallback回调里置rx_flag并立刻启动下一轮接收主循环检测到rx_flag后调用HAL_UART_Transmit把同一个字节写进发送移位寄存器数据从PA9发出回到上位机串口助手的接收框里。这条链路里每一环都有检查点。收不到数据先量PA10引脚有没有电平翻转再看RXNE标志有没有置起然后确认NVIC是否使能最后看回调有没有被调用。按这个顺序排查能把问题范围一步步缩小不会在一个错误的环节上反复试。4. 串口联调避坑指南乱码、丢帧与卡死的排查记录4.1 现象一波特率调了一遍又一遍收到的还是乱码现象是上位机发送hello接收框显示h?f或者无规律乱码波特率从9600试到115200甚至460800都一个样。如果每次都排除波特率设置问题真正原因往往在时钟配置上。原因是串口波特率由USART时钟和分频系数决定。CubeMX里HSE如果填了8MHz但实际板子焊接的是16MHz晶振或者HSE根本没起振导致系统跑在HSI 8MHz那么USART1的波特率计算全部偏掉。串口助手看到的现象就是“无论选哪个波特率都对不上”因为误差已经不是简单换挡能解决的。解决方式是回到CubeMX时钟树页面确认HSE输入频率与硬件一致确认PLL输出是72MHz。更快的判断方法是先看串口调试助手能不能收到引导信息如果上电后连STM32 UART Ready都是乱的优先怀疑系统时钟而不是波特率设置。从某次项目调试开始我每次拿到新板子都会先开一个GPIO翻转用示波器量实际主频确认时钟正常再碰串口。排查时还可以在调试器里直接看huart1.Init.BaudRate的当前值和CubeMX配置的是否一致排除代码被其他版本覆盖的情况。如果时钟和波特率都对换个USB转TTL模块交叉验证有些模块的晶振精度太差高位波特率下同样会乱码。4.2 现象二能发不能收HAL_UART_Receive_IT只触发一次现象是复位后第一帧数据能收到之后无论怎么发都没有新回显重新上电又恢复一次。这是HAL_UART_Receive_IT用得最典型的翻车点。原因是HAL_UART_Receive_IT是一次性接收函数完成指定长度后会恢复到空闲状态不再接收新数据。直接在初始化时调用一次后续没有在回调里重新调用第二次字节到达时接收流程没有启动数据自然全部丢弃。另一种情况是接收的过程中又重复调用HAL_UART_Receive_IT函数发现上次接收还没完成返回HAL_BUSY且启动失败。解决方式是在HAL_UART_RxCpltCallback回调末尾重新调用HAL_UART_Receive_IT让接收流程形成持续接力。同时可以在调用前检查huart1.gState有必要时打印一次启动结果if (HAL_UART_Receive_IT(huart1, rx_byte, 1) ! HAL_OK) { printf(receive start failed\r\n); }如果高速收发场景下发现回调频繁触发但数据还是丢需要检查是否发生了ORE溢出错误。可以重写HAL_UART_ErrorCallback在里面打印huart-ErrorCode如果看到HAL_UART_ERROR_ORE说明上一字节还没处理完下一字节就来了这时要提高中断优先级或者改DMA接收。从那以后我每次写串口中断接收都会检查一遍“回调里有没有再次启动”这个习惯避免了很多从能收到不能收的反复。4.3 现象三上位机一发数据板子就像被复位了一样现象是串口助手一勾选“发送新行”板子就重启或者第一次数据正常第二次带换行符的数据把整个程序打乱。如果用的是常见的USB转TTL模块这是DTR/RTS信号在捣乱。原因是不少USB转TTL模块会引出一路DTR和RTS信号它们可以控制目标板的复位引脚和BOOT0引脚。串口助手在“发送新行”时如果勾上了DTR/RTS联动或“打开串口时复位”就会在信号线上产生电平跳变等于给板子按了复位键。解决方式简单在串口助手的DTR/RTS选项里全部取消勾选或者用只接了TXD、RXD、GND三根线的模块。也注意不要在USB转TTL的RTS引脚上接了复位电路还反复调试硬件流控。出现“一发送板子就重启”这种玄学现象时先看信号线再看代码大部分时候是物理连线和助手的辅助信号配置问题。更隐蔽的一种情况是发送新行里的换行符是\r\n而板子程序只按\n做帧结束处理\r被当成正常数据收进缓冲。这时收进来的内容里会残留一个回车符字符串比较永远失败。解决方式是做帧解析时主动过滤\r或者上位机端只发送自定义帧格式不带多余控制字符。4.4 现象四程序卡死在HAL_UART_Transmit里现象是高波特率下连续发送一段较长数据程序停住不动调试器暂停时看到当前PC指针停在HAL_UART_Transmit内部等了很久也不返回。原因是处理逻辑里把大块数据的发送放在中断回调中执行。中断上下文里发长数据发送期间其他中断被阻塞而USART的后续中断可能和发送互相等待最终让程序陷入类似死锁的等待。HAL_UART_Transmit的阻塞发送机制内部会等待TXE标志超时设置得再长也解决不了优先级倒挂的问题。解决方式是遵循中断回调快进快出的原则。回调里只置标志位把发送放到主循环处理如果确实需要在中断里边收边发使用HAL_UART_Transmit_IT中断发送发送完成后会有HAL_UART_TxCpltCallback回调。发送大量日志数据时也可以先把数据拼到缓冲区再通过DMA搬运完全不占CPU。另外要注意中断优先级分组。如果工程里同时用了定时器中断和串口中断且分组方式用错了抢占优先级和子优先级的位数分配串口中断可能被其他高频中断持续抢占表现为串口时通时断。出现这种问题先统一检查HAL_NVIC_SetPriorityGrouping的设置确保所有中断的优先级定义在同一个分组体系下。5. 环境搭建与运行验证从解压到回显成功5.1 开发环境准备Keil MDK和F1器件支持包这套资源通常是用MDK-ARM工程形式提供的所以本机要装Keil MDK5并安装对应的STM32F1系列器件支持包。打开工程前建议先把整个压缩包解压到纯英文路径下不要放在带中文或空格的目录里MDK有时会在特殊字符路径下编译出错报错信息又很长很绕。双击.uvprojx打开工程后在Options for Target里的Device页面确认芯片型号显示的是STM32F103C8Tx。如果配置里选成了高容量型号链接器会按更大Flash的空间布局分配地址实际烧录到C8T6上会出现启动异常。第一次编译如果报缺头文件多半是支持包版本和工程使用的HAL库版本不一致重新安装当前版本的STM32F1xx_DFP即可。编译时遇到warning不用太紧张但要看一眼。常见的unused variable警告通常不影响运行而declaration follows execution statement警告在旧版C标准下可能掩盖真正的问题建议把C标准切到gnu11再编译。工程能零错误零警告通过再往下做烧录验证。5.2 接线与烧录交叉接线和下载方式选择串口通信的接线遵循“TX对RX、RX对TX”的交叉原则。板子的USART1_TX在PA9它要接USB转TTL模块的RXD板子的USART1_RX在PA10它要接USB转TTL模块的TXD。最重要的还有一条GND必须和电脑侧共地不共地时信号没有基准电位现象是时通时断、乱码、甚至完全无反应。板子引脚功能USB转TTL模块PA9USART1_TXRXDPA10USART1_RXTXDGND电源地GND烧录方式有两条路。用ST-Link做SWD下载时连接SWDIO、SWCLK、GND、3V3四根线BOOT0接地Keil里下载器选ST-Link即可。用串口ISP下载时BOOT0接3V3BOOT1接地用STM32CubeProgrammer选择UART方式连接注意串口ISP模式下PA9/PA10被占用下载完成后要把BOOT0拉回低电平并手动复位一次程序才会从Flash启动运行。很多初次上手的人把板子连好线Keil也显示下载成功程序却完全不跑原因常常是BOOT0还挂在3V3上上电后MCU进了ISP引导程序而不是用户程序。烧录成功和程序运行是两个概念复位后观察串口有没有打印上电信息是最快的验证方式。5.3 串口助手联调回显验证和关键参数打开串口助手选择正确的COM口波特率115200数据位8停止位1无校验关闭DTR/RTS。这些参数必须和上一章MX_USART1_UART_Init里的配置完全一致尤其是停止位上位机设置成2位停止位不会报错但接收时序对不上长数据时会出现偶发丢字节。向板子发送任意字符串预期收到相同的回显内容同时板载用户LED同步翻转一次。我习惯用一个固定格式做验证先发hello再发1234567890最后发控制字符。如果字符串回显正常说明字节级收发的物理链路已经打通如果只回显一部分再回到第四章检查是否漏了重新启动接收。调试时建议用文本模式和HEX模式互相验证。文本模式适合看可读字符串HEX模式适合确认实际字节值比如发送0x41文本模式显示AHEX模式显示41 0A两种模式交叉观察能更快定位是上位机转义问题还是板子解析问题。部分串口助手支持显示时间戳这个功能在分析粘包和间隔时间时很管用。5.4 如何判断资源里的工程真的跑起来了串口回显通过、LED动作正常只说明收发链路本身是通的。更严谨的验证是往上位机周期发送递增计数观察程序是否长时间稳定运行while (1) { printf(count %d\r\n, count); HAL_Delay(500); }如果计数能连续跑到几千甚至几万不卡顿说明HAL库的中断和主循环协作正常。接着在上位机连续快速发送数据观察有没有漏字节这一步能检验发送缓冲区和接收接力的健壮性。整套走完之后再把工程里的发送函数改成自己的业务帧格式二次开发就可以从完整验证过的底板上起步了。6. 二次开发改造思路从回显到自定义帧协议解析基础回显验证之后下一步通常是让串口不只回显而是能解析命令。改成帧协议接收时我一般会在回调里维护一个字节累积缓冲以\n作为一帧结束标志收到结束符后把帧交给解析函数#define FRAME_BUF_SIZE 64 static uint8_t frame_buf[FRAME_BUF_SIZE]; static uint8_t frame_index 0; static uint8_t frame_ready 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { if (rx_byte \n) { frame_buf[frame_index] \0; frame_ready 1; frame_index 0; } else if (frame_index FRAME_BUF_SIZE - 1) { frame_buf[frame_index] rx_byte; } HAL_UART_Receive_IT(huart1, rx_byte, 1); } }主循环里检测到frame_ready后对frame_buf做字符串匹配比如“LED1”点灯、“LED0”灭灯。这种简单状态机的好处是只依赖单字节中断不引入DMA逻辑都看得见适合小数据量控制命令。注意处理\r残留上位机发送\r\n时\r会被收进缓冲比较前先做一次过滤。如果通信数据量大、帧长不定再往前一步是换成DMA加空闲中断的接收方式。CubeMX里给USART1添加DMA接收通道NVIC里使能USART1全局中断启动用HAL_UARTEx_ReceiveToIdle_DMA数据接收完成或总线空闲时触发HAL_UARTEx_RxEventCallback。改动后先用串口助手连续发多帧数据验证分帧边界确认不会出现大数据包互相粘连。验证方法很简单用串口助手依次发送协议规定的命令帧观察板子回显和IO动作是否一一对应再故意发送一帧残缺数据和超长数据确认状态机能自动复位而不是卡死。改完后我每次都会强制自己走一遍“时钟—引脚—波特率—共地”四连查确认新加的中断和DMA没有和串口中断抢优先级再去写业务逻辑。这个习惯帮我少翻了很多次车希望帮到你。本文还有配套的精品资源点击获取
简介基于STM32F103C8T6HAL库STM32CubeMX的UART串口通信数据收发完整工程面向嵌入式初学者、STM32入门者及需要快速搭建串口通信原型的开发者重点解决CubeMX外设配置、HAL库驱动调用和收发验证等问题。压缩包共146个文件包含47个h头文件、20个c源文件、62个编译中间文件o/d/crf、1个ioc配置工程、1个hex可执行文件以及其他辅助调试内容约4.31MB目录对应Keil工程结构便于直接打开查看或二次修改。工程覆盖系统时钟HSEPLL至72MHz、USART引脚映射与波特率设置、HAL_UART_Transmit/HAL_UART_Receive收发调用并保留NV_USART相关实现及map/axf等构建产物方便对照初始化流程、调试排错和进一步扩展。已有6056人浏览学习适合直接在开发板上烧录验证也可作为串口通信项目的基础模板复用对掌握嵌入式通信基础和理解HAL库抽象层均有实际参考价值。1. 串口通信调不通的痛点这套基于STM32F103C8T6的资源能做什么调试单片机板子时最怕撞上的场景串口助手波特率反复调了三次发一个字节过去回显是满屏乱码甚至完全没反应。这套资源就是用STM32CubeMX加HAL库把STM32F103C8T6的UART串口通信数据收发从头到尾跑通解压后按步骤烧录回显、中断接收、数据互发都能在最小系统板上落地。项目核心解决的是“串口为什么不通”和“收发到底怎么组织”这两件事CubeMX完成引脚和时钟的图形化配置生成的HAL库代码处理寄存器细节开发者只需要在用户代码区写发送和接收逻辑。它适合刚接触STM32的嵌入式初学者也适合备赛、做上位机联调时需要一个能直接改的串口基座工程的开发者。拿到手里第一件事不是看代码而是先读工程里的.ioc文件和串口初始化逻辑确认它用的是哪一个USART、挂在哪个时钟树上。下面按这个顺序拆。2. 这份串口资源到底做了什么从板卡选型到工程目录拆解2.1 为什么是STM32F103C8T6加HAL库加CubeMX这三件套STM32F103C8T6是一颗Cortex-M3内核的单片机主频最高72MHz片上64KB Flash和20KB RAM集成三个USART。做串口通信这类基础外设验证它成本低、资料多、烧录方式灵活用一块蓝板加一个USB转TTL模块就能开始干活。HAL库在项目里的价值是把底层寄存器访问封装成结构体操作。想改波特率改huart1.Init.BaudRate想切换收发模式改huart1.Init.Mode。相比直接操作寄存器HAL库的代码更接近“填表”对第一次接触STM32的人来说出错时看API名就能猜出大概。CubeMX负责生成初始化代码包括时钟树、GPIO复用和中断配置生成的工程直接拖进Keil或者STM32CubeIDE就能编译。这套组合也有代价。HAL库会引入大量中间层最终编译出的固件体积比标准库大。F103C8T6只有64KB Flash只做串口收发时完全没有压力如果后面要塞进复杂的协议栈、显示屏驱动加多个传感器算法就要注意Flash占用。打算深入做产品化的场景下我一般会建议把HAL库裁剪或者局部改用LL库但作为学习资源和二次开发基座HAL库的易读性更重要。另外要留意C8T6的中容量定位。CubeMX生成工程时如果目标芯片选错成高容量型号代码同样能编译但链接脚本的Flash布局不同烧录后可能出现启动异常。这类资源拿到手后我第一件事是看芯片顶面丝印确认后缀是C8T6再开始配工程。2.2 解压后先看哪里CubeMX工程的目录结构与文件分工资源解压后是CubeMX生成的标准工程布局。先找到.ioc文件它是整个工程的“配置快照”双击打开能回到图形化界面重新配置外设重新生成代码时CubeMX只覆盖自动生成区域手工写在USER CODE BEGIN和USER CODE END之间的代码会保留这是二次开发时最重要的一个约定千万不要把代码写到这两个标记之外。stm32f103c8t6_uart/ ├── stm32f103c8t6_uart.ioc // CubeMX 配置文件双击可重新生成工程 ├── Core/ │ ├── Inc/ │ │ ├── main.h // 主头文件存放全局声明 │ │ └── usart.h // USART1 句柄声明 │ └── Src/ │ ├── main.c // 主循环、发送/接收逻辑入口 │ ├── usart.c // MX_USART1_UART_Init 初始化 │ ├── gpio.c // 引脚时钟和模式配置 │ └── stm32f1xx_hal_msp.c // 外设底层的时钟、GPIO、NVIC 配置 ├── Drivers/ │ ├── CMSIS/ │ └── STM32F1xx_HAL_Driver/ // HAL 库源码 ├── MDK-ARM/ // Keil 工程.uvprojx 从这里打开 │ └── stm32f103c8t6_uart.uvprojx └── README.md // 资源自述和运行说明这个目录结构里真正需要改的是Core/Src/main.c和usart.c。usart.c里是CubeMX生成的MX_USART1_UART_Init()配置项用结构体赋值完成main.c里是用户逻辑包括初始化后的发送语句、主循环轮询和中断回调。stm32f1xx_hal_msp.c比较容易被忽略它承担外设底层初始化比如开启USART1时钟、配置PA9/PA10为复用推挽输出、设置NVIC中断优先级很多“初始化成功但串口不动”的问题最后都出在这里。usart.h里声明了外部句柄extern UART_HandleTypeDef huart1;main.c和用户文件都能直接引用它。HAL_UART_HandleTypeDef内部包含Instance、Init、gState、RxState这些字段调试时可以在Keil的Watch窗口直接看gState状态值判断外设当前是否处于空闲或忙碌状态。提示CubeMX重新生成代码时只会保留USER CODE BEGIN与USER CODE END之间的内容业务代码务必放在这两个标记之间。2.3 串口资源选址USART1的引脚、总线时钟与中断关系F103C8T6的USART1默认映射到PA9和PA10PA9是TX发送引脚PA10是RX接收引脚。USART1挂在APB2总线上APB2的最高频率和系统主频相同都是72MHz这也是为什么配置完时钟树后串口波特率计算没有额外分频误差的主要原因。USART1的中断入口是USART1_IRQn。CubeMX在NVIC Settings里使能USART1 global interrupt后会在stm32f1xx_it.c中生成USART1_IRQHandler由它调用HAL库的HAL_UART_IRQHandler(huart)完成中断分发。中断触发条件包括RXNE接收寄存器非空、TXE发送寄存器空、ORE溢出错误等HAL库会把这些事件分类再回调到用户可重写的弱函数里。波特率由USARTDIV分频值决定F1的USART1可以用72MHz作为输入时钟。115200对应的分频值是72MHz除以115200HAL库会自动算好分频值写入BRR寄存器。如果把USART1误配到APB1的36MHz时钟上同一个波特率设置算出的分频值差一倍通信自然对不上。这也是排查乱码时先问“你的USART挂在哪个总线”的原因。如果是USART2或USART3对应引脚、挂载总线、中断向量都不一样。改资源里的通信口时要同时改.ioc里的引脚分配、时钟树里对应总线的分频系数和NVIC配置只改代码不改引脚映射是跑不起来的。现在这份资源只用了USART1理解了这一套对应关系后面换串口只是重复同样的配置流程。3. 核心模块拆解从CubeMX配置到中断收发的完整链路3.1 CubeMX配置阶段时钟树、USART1和NVIC的填表过程先看CubeMX侧需要确认的配置项。RCC里启用HSE外部高速时钟选择Crystal/Ceramic Resonator外部晶振按8MHz算时钟树里PLL Source选HSE把PLL倍频系数调到9得到72MHz的系统主频APB1 Prescaler选/2让APB1保持在36MHzAPB2 Prescaler保持/1这样USART1能拿到完整的72MHz时钟。USART1的配置页选择Asynchronous异步模式引脚自动分配PA9的USART1_TX和PA10的USART1_RX。常用参数是波特率115200、8位数据长度、无校验、1位停止位、无硬件流控这些参数要和上位机串口助手完全一致差一位停止位或者勾上了流控就会出现能发不能收或者乱码的怪问题。NVIC设置里使能USART1全局中断这是后面做中断接收的前提。CubeMX生成的初始化代码长这样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(); } }BaudRate、WordLength、StopBits、Parity这几个字段直接决定物理层格式。上位机串口助手里的设置要和这里一一对应比如这里UART_PARITY_NONE上位机就必须关掉校验。HwFlowCtl默认关闭硬件流控如果开了RTS/CTS而USB转TTL模块不支持硬件流控数据发送会一直等待握手信号看起来就像串口卡死。底层初始化在HAL_UART_MspInit里完成包括使能时钟、配置GPIO复用、设置中断优先级void HAL_UART_MspInit(UART_HandleTypeDef *huart) { GPIO_InitTypeDef GPIO_InitStruct {0}; if (huart-Instance USART1) { __HAL_RCC_USART1_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitStruct.Pin GPIO_PIN_9 | GPIO_PIN_10; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; // 复用推挽TX/RX 都按复用模式配置 GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); HAL_NVIC_SetPriority(USART1_IRQn, 0, 0); HAL_NVIC_EnableIRQ(USART1_IRQn); } }PA9和PA10都配置成GPIO_MODE_AF_PP复用推挽输出模式这句话很反直觉有人把RX引脚配成输入模式导致收不到数据。事实上在F1系列里USART的TX和RX引脚都要配置为复用推挽硬件的收发方向由USART外设自己控制不需要手动配置输入输出方向。HAL_NVIC_SetPriority(USART1_IRQn, 0, 0)设置抢占优先级0子优先级0如果后面加了更多中断要注意优先级分组方式保持一致。3.2 发送逻辑阻塞发送与printf重定向的两种写法发送数据最直接的方式是HAL提供的HAL_UART_Transmit属于阻塞式发送发送期间CPU一直等发送完成。初始化完成后发一串欢迎信息uint8_t tx_buf[] STM32 UART Ready\r\n; HAL_UART_Transmit(huart1, tx_buf, sizeof(tx_buf) - 1, 1000);参数里第一个是串口句柄第二个是待发送数据指针第三个是发送长度第四个是超时时间。这里用sizeof(tx_buf) - 1是为了把结尾的\0去掉字符串数组在定义时自动多出了一个结束符串口发送时不需要发\0。超时时间单位是毫秒1000表示最多等1秒如果1秒内没发完就返回HAL_TIMEOUT主程序可以用返回值判断通信是否异常。但实际调试时更常用printf往串口打数据。HAL库没有自带printf支持需要自己做fputc重定向把标准输出重定向到USART1#include stdio.h int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; }在Keil里使用MicroLIB或者在STM32CubeIDE里启用newlib-nanoprintf就能直接通过串口输出。这个重定向文件里如果同时存在多个串口fputc里可以按调试需要切换句柄但同一时刻只能有一个目标。重定向之后printf(count %d\r\n, count);就成了嵌入式里最常用的日志手段比LED闪烁和仿真器断点都要直观。3.3 接收逻辑单字节中断接收的接力写法接收侧不能在主循环里调用HAL_UART_Receive死等那样CPU会在阻塞中空转其他任务全部卡死。惯用且好用的做法是用HAL_UART_Receive_IT启动一次中断接收每收到一个字节触发一次回调回调处理完之后再次调用HAL_UART_Receive_IT启动下一轮接收形成接力。先把接收缓冲和标志位定义在文件顶部uint8_t rx_byte 0; // 每轮中断接收的单个字节 uint8_t rx_flag 0; // 收到新数据的标志位初始化时启动第一次接收HAL_UART_Receive_IT(huart1, rx_byte, 1);HAL_UART_Receive_IT的第二个参数是接收缓冲区地址第三个参数是期望接收的字节数。传1表示每接收完1个字节就触发一次HAL_UART_RxCpltCallback回调。使用时要特别注意这个函数只是启动接收不是轮询接收如果上一次接收还没完成重复调用会返回HAL_BUSY。然后在用户代码区重写回调函数void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { rx_flag 1; // 通知主循环有新数据 HAL_UART_Receive_IT(huart1, rx_byte, 1); // 立刻接力下一轮接收 } }回调里只做两件事置标志位、重新启动下一次接收。主循环通过轮询rx_flag来处理数据比如原样回显while (1) { if (rx_flag) { rx_flag 0; HAL_UART_Transmit(huart1, rx_byte, 1, 100); } }这里容易踩的坑点在于回调执行上下文是中断。回调里不要写耗时太长的操作更不要在里面调用printf或者做大数据拷贝中断处理时间过久会延迟下一次中断响应高速收发时会出现丢字节。重启动接收的调用必须放在回调末尾如果在主循环里重新调用HAL_UART_Receive_IT中间会存在一段空窗期这期间到达的字节会直接丢失。3.4 一条数据从进入到返回的完整时序把上面几段拼起来一条完整的数据链路是这样的上位机通过USB转TTL模块把字节送到PA10引脚USART外设移位寄存器逐位接收置起RXNE标志中断控制器响应USART1全局中断进入USART1_IRQHandlerHAL库的HAL_UART_IRQHandler识别事件类型是RXNE调用UART_Receive_IT把接收寄存器里的字节拷贝到rx_byte然后触发HAL_UART_RxCpltCallback回调里置rx_flag并立刻启动下一轮接收主循环检测到rx_flag后调用HAL_UART_Transmit把同一个字节写进发送移位寄存器数据从PA9发出回到上位机串口助手的接收框里。这条链路里每一环都有检查点。收不到数据先量PA10引脚有没有电平翻转再看RXNE标志有没有置起然后确认NVIC是否使能最后看回调有没有被调用。按这个顺序排查能把问题范围一步步缩小不会在一个错误的环节上反复试。4. 串口联调避坑指南乱码、丢帧与卡死的排查记录4.1 现象一波特率调了一遍又一遍收到的还是乱码现象是上位机发送hello接收框显示h?f或者无规律乱码波特率从9600试到115200甚至460800都一个样。如果每次都排除波特率设置问题真正原因往往在时钟配置上。原因是串口波特率由USART时钟和分频系数决定。CubeMX里HSE如果填了8MHz但实际板子焊接的是16MHz晶振或者HSE根本没起振导致系统跑在HSI 8MHz那么USART1的波特率计算全部偏掉。串口助手看到的现象就是“无论选哪个波特率都对不上”因为误差已经不是简单换挡能解决的。解决方式是回到CubeMX时钟树页面确认HSE输入频率与硬件一致确认PLL输出是72MHz。更快的判断方法是先看串口调试助手能不能收到引导信息如果上电后连STM32 UART Ready都是乱的优先怀疑系统时钟而不是波特率设置。从某次项目调试开始我每次拿到新板子都会先开一个GPIO翻转用示波器量实际主频确认时钟正常再碰串口。排查时还可以在调试器里直接看huart1.Init.BaudRate的当前值和CubeMX配置的是否一致排除代码被其他版本覆盖的情况。如果时钟和波特率都对换个USB转TTL模块交叉验证有些模块的晶振精度太差高位波特率下同样会乱码。4.2 现象二能发不能收HAL_UART_Receive_IT只触发一次现象是复位后第一帧数据能收到之后无论怎么发都没有新回显重新上电又恢复一次。这是HAL_UART_Receive_IT用得最典型的翻车点。原因是HAL_UART_Receive_IT是一次性接收函数完成指定长度后会恢复到空闲状态不再接收新数据。直接在初始化时调用一次后续没有在回调里重新调用第二次字节到达时接收流程没有启动数据自然全部丢弃。另一种情况是接收的过程中又重复调用HAL_UART_Receive_IT函数发现上次接收还没完成返回HAL_BUSY且启动失败。解决方式是在HAL_UART_RxCpltCallback回调末尾重新调用HAL_UART_Receive_IT让接收流程形成持续接力。同时可以在调用前检查huart1.gState有必要时打印一次启动结果if (HAL_UART_Receive_IT(huart1, rx_byte, 1) ! HAL_OK) { printf(receive start failed\r\n); }如果高速收发场景下发现回调频繁触发但数据还是丢需要检查是否发生了ORE溢出错误。可以重写HAL_UART_ErrorCallback在里面打印huart-ErrorCode如果看到HAL_UART_ERROR_ORE说明上一字节还没处理完下一字节就来了这时要提高中断优先级或者改DMA接收。从那以后我每次写串口中断接收都会检查一遍“回调里有没有再次启动”这个习惯避免了很多从能收到不能收的反复。4.3 现象三上位机一发数据板子就像被复位了一样现象是串口助手一勾选“发送新行”板子就重启或者第一次数据正常第二次带换行符的数据把整个程序打乱。如果用的是常见的USB转TTL模块这是DTR/RTS信号在捣乱。原因是不少USB转TTL模块会引出一路DTR和RTS信号它们可以控制目标板的复位引脚和BOOT0引脚。串口助手在“发送新行”时如果勾上了DTR/RTS联动或“打开串口时复位”就会在信号线上产生电平跳变等于给板子按了复位键。解决方式简单在串口助手的DTR/RTS选项里全部取消勾选或者用只接了TXD、RXD、GND三根线的模块。也注意不要在USB转TTL的RTS引脚上接了复位电路还反复调试硬件流控。出现“一发送板子就重启”这种玄学现象时先看信号线再看代码大部分时候是物理连线和助手的辅助信号配置问题。更隐蔽的一种情况是发送新行里的换行符是\r\n而板子程序只按\n做帧结束处理\r被当成正常数据收进缓冲。这时收进来的内容里会残留一个回车符字符串比较永远失败。解决方式是做帧解析时主动过滤\r或者上位机端只发送自定义帧格式不带多余控制字符。4.4 现象四程序卡死在HAL_UART_Transmit里现象是高波特率下连续发送一段较长数据程序停住不动调试器暂停时看到当前PC指针停在HAL_UART_Transmit内部等了很久也不返回。原因是处理逻辑里把大块数据的发送放在中断回调中执行。中断上下文里发长数据发送期间其他中断被阻塞而USART的后续中断可能和发送互相等待最终让程序陷入类似死锁的等待。HAL_UART_Transmit的阻塞发送机制内部会等待TXE标志超时设置得再长也解决不了优先级倒挂的问题。解决方式是遵循中断回调快进快出的原则。回调里只置标志位把发送放到主循环处理如果确实需要在中断里边收边发使用HAL_UART_Transmit_IT中断发送发送完成后会有HAL_UART_TxCpltCallback回调。发送大量日志数据时也可以先把数据拼到缓冲区再通过DMA搬运完全不占CPU。另外要注意中断优先级分组。如果工程里同时用了定时器中断和串口中断且分组方式用错了抢占优先级和子优先级的位数分配串口中断可能被其他高频中断持续抢占表现为串口时通时断。出现这种问题先统一检查HAL_NVIC_SetPriorityGrouping的设置确保所有中断的优先级定义在同一个分组体系下。5. 环境搭建与运行验证从解压到回显成功5.1 开发环境准备Keil MDK和F1器件支持包这套资源通常是用MDK-ARM工程形式提供的所以本机要装Keil MDK5并安装对应的STM32F1系列器件支持包。打开工程前建议先把整个压缩包解压到纯英文路径下不要放在带中文或空格的目录里MDK有时会在特殊字符路径下编译出错报错信息又很长很绕。双击.uvprojx打开工程后在Options for Target里的Device页面确认芯片型号显示的是STM32F103C8Tx。如果配置里选成了高容量型号链接器会按更大Flash的空间布局分配地址实际烧录到C8T6上会出现启动异常。第一次编译如果报缺头文件多半是支持包版本和工程使用的HAL库版本不一致重新安装当前版本的STM32F1xx_DFP即可。编译时遇到warning不用太紧张但要看一眼。常见的unused variable警告通常不影响运行而declaration follows execution statement警告在旧版C标准下可能掩盖真正的问题建议把C标准切到gnu11再编译。工程能零错误零警告通过再往下做烧录验证。5.2 接线与烧录交叉接线和下载方式选择串口通信的接线遵循“TX对RX、RX对TX”的交叉原则。板子的USART1_TX在PA9它要接USB转TTL模块的RXD板子的USART1_RX在PA10它要接USB转TTL模块的TXD。最重要的还有一条GND必须和电脑侧共地不共地时信号没有基准电位现象是时通时断、乱码、甚至完全无反应。板子引脚功能USB转TTL模块PA9USART1_TXRXDPA10USART1_RXTXDGND电源地GND烧录方式有两条路。用ST-Link做SWD下载时连接SWDIO、SWCLK、GND、3V3四根线BOOT0接地Keil里下载器选ST-Link即可。用串口ISP下载时BOOT0接3V3BOOT1接地用STM32CubeProgrammer选择UART方式连接注意串口ISP模式下PA9/PA10被占用下载完成后要把BOOT0拉回低电平并手动复位一次程序才会从Flash启动运行。很多初次上手的人把板子连好线Keil也显示下载成功程序却完全不跑原因常常是BOOT0还挂在3V3上上电后MCU进了ISP引导程序而不是用户程序。烧录成功和程序运行是两个概念复位后观察串口有没有打印上电信息是最快的验证方式。5.3 串口助手联调回显验证和关键参数打开串口助手选择正确的COM口波特率115200数据位8停止位1无校验关闭DTR/RTS。这些参数必须和上一章MX_USART1_UART_Init里的配置完全一致尤其是停止位上位机设置成2位停止位不会报错但接收时序对不上长数据时会出现偶发丢字节。向板子发送任意字符串预期收到相同的回显内容同时板载用户LED同步翻转一次。我习惯用一个固定格式做验证先发hello再发1234567890最后发控制字符。如果字符串回显正常说明字节级收发的物理链路已经打通如果只回显一部分再回到第四章检查是否漏了重新启动接收。调试时建议用文本模式和HEX模式互相验证。文本模式适合看可读字符串HEX模式适合确认实际字节值比如发送0x41文本模式显示AHEX模式显示41 0A两种模式交叉观察能更快定位是上位机转义问题还是板子解析问题。部分串口助手支持显示时间戳这个功能在分析粘包和间隔时间时很管用。5.4 如何判断资源里的工程真的跑起来了串口回显通过、LED动作正常只说明收发链路本身是通的。更严谨的验证是往上位机周期发送递增计数观察程序是否长时间稳定运行while (1) { printf(count %d\r\n, count); HAL_Delay(500); }如果计数能连续跑到几千甚至几万不卡顿说明HAL库的中断和主循环协作正常。接着在上位机连续快速发送数据观察有没有漏字节这一步能检验发送缓冲区和接收接力的健壮性。整套走完之后再把工程里的发送函数改成自己的业务帧格式二次开发就可以从完整验证过的底板上起步了。6. 二次开发改造思路从回显到自定义帧协议解析基础回显验证之后下一步通常是让串口不只回显而是能解析命令。改成帧协议接收时我一般会在回调里维护一个字节累积缓冲以\n作为一帧结束标志收到结束符后把帧交给解析函数#define FRAME_BUF_SIZE 64 static uint8_t frame_buf[FRAME_BUF_SIZE]; static uint8_t frame_index 0; static uint8_t frame_ready 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { if (rx_byte \n) { frame_buf[frame_index] \0; frame_ready 1; frame_index 0; } else if (frame_index FRAME_BUF_SIZE - 1) { frame_buf[frame_index] rx_byte; } HAL_UART_Receive_IT(huart1, rx_byte, 1); } }主循环里检测到frame_ready后对frame_buf做字符串匹配比如“LED1”点灯、“LED0”灭灯。这种简单状态机的好处是只依赖单字节中断不引入DMA逻辑都看得见适合小数据量控制命令。注意处理\r残留上位机发送\r\n时\r会被收进缓冲比较前先做一次过滤。如果通信数据量大、帧长不定再往前一步是换成DMA加空闲中断的接收方式。CubeMX里给USART1添加DMA接收通道NVIC里使能USART1全局中断启动用HAL_UARTEx_ReceiveToIdle_DMA数据接收完成或总线空闲时触发HAL_UARTEx_RxEventCallback。改动后先用串口助手连续发多帧数据验证分帧边界确认不会出现大数据包互相粘连。验证方法很简单用串口助手依次发送协议规定的命令帧观察板子回显和IO动作是否一一对应再故意发送一帧残缺数据和超长数据确认状态机能自动复位而不是卡死。改完后我每次都会强制自己走一遍“时钟—引脚—波特率—共地”四连查确认新加的中断和DMA没有和串口中断抢优先级再去写业务逻辑。这个习惯帮我少翻了很多次车希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
