1. 项目概述从“单打独斗”到“协同作战”在嵌入式开发的世界里让两块STM32单片机“开口说话”通过串口进行数据交换这几乎是每个工程师都会遇到的经典场景。这不仅仅是简单的数据收发它背后涉及的是系统架构的升级——从单一设备的独立运行到多设备协同工作的分布式系统雏形。无论是主从控制的机器人关节、双核备份的冗余系统还是传感器数据采集与核心逻辑处理的分离串口通信都是实现这些功能最直接、最经济、也最可靠的桥梁之一。我见过不少项目初期为了图省事把所有功能都塞进一颗MCU里结果代码臃肿、调试困难后期想扩展功能时束手无策。而如果一开始就规划好通信架构用两块或多块STM32各司其职整个系统的灵活性、可维护性和可靠性都会得到质的提升。本文将带你深入两块STM32串口通信的每一个细节从硬件连接到软件协议从基础收发到高级应用分享我踩过的坑和总结出的实战经验让你能快速、稳健地实现设备间的“对话”。2. 通信方案选型与硬件连接详解2.1 为什么首选串口对比其他通信方式在决定使用串口之前我们有必要快速审视一下STM32家族的其他内部通信外设这能帮助我们更坚定地选择串口或者在某些特殊场景下做出更优的选择。SPISerial Peripheral Interface它的特点是高速、全双工、同步通信。时钟线由主机提供数据传输速率轻松达到几十Mbps。但它通常是一主多从的结构需要额外的片选线CS来寻址从机。如果你需要极高的数据传输速率比如驱动高速TFT屏、读写SD卡且通信距离很短通常板级内SPI是更好的选择。但对于两块需要平等对话、或有物理距离的STM32SPI的连线复杂性和抗干扰能力在长距离下的劣势就显现出来了。I2CInter-Integrated Circuit它凭借仅需两根线SDA数据、SCL时钟就能支持多主多从的优势在连接多个传感器、EEPROM时非常流行。但其协议开销较大速度通常限于标准模式100kbps或快速模式400kbps且总线上挂载设备过多时时序容易变得脆弱。对于仅有两块STM32点对点通信且对速率有一定要求的场景I2C的速率可能成为瓶颈。CANController Area Network这是工业级和汽车电子的宠儿拥有强大的多主、仲裁、错误检测和故障界定机制抗干扰能力极强适合复杂的电磁环境和长距离通信。但它的硬件和协议栈相对复杂成本也更高。如果你的项目是实验室环境或消费电子用CAN有点“杀鸡用牛刀”。相比之下USART/UART异步串行通信的优势非常突出点对点连接极其简单通常只需TX、RX、GND三根线协议简单透明数据按字节流发送没有复杂的帧结构和时钟同步要求调试时用个USB转串口工具就能直接“窥探”通信内容对软件资源消耗小配置简单通信距离相对较远在适当的波特率下通过RS-232或RS-485电平转换可以轻松实现几十米甚至上百米的可靠通信。因此对于绝大多数两块STM32之间的中低速、可靠、易调试的数据交换任务串口是不二之选。2.2 硬件连接的正确姿势避开那些“坑”连接两块STM32的串口核心原则就一句话交叉连接TX和RX。即设备A的TX发送引脚连接设备B的RX接收引脚设备A的RX连接设备B的TX。地线GND必须共接为信号提供统一的参考电平。听起来很简单但新手常犯以下几个错误忘记共地这是最致命也最容易被忽略的错误。如果没有共地两个设备处于不同的电势参考点接收方可能完全无法正确识别高低电平导致通信彻底失败或者出现随机乱码。务必、务必、务必将两块开发板的GND用导线连接起来。引脚复用冲突STM32的串口引脚通常是复用功能AF。你需要查阅芯片的数据手册Datasheet和引脚定义图确认你选择的USARTx_TX和USARTx_RX引脚没有被其他功能如I2C、SPI、普通IO占用。在CubeMX中配置时如果引脚显示为黄色通常意味着有冲突需要你重新规划。电平匹配问题STM32的GPIO引脚是3.3V的TTL电平。直接连接两块STM32的TTL电平是没问题的。但如果你需要通过RS-232芯片如MAX3232连接DB9接口或者通过RS-485芯片如MAX485进行长距离差分传输就必须注意电平转换。TTL电平直接接入RS-232接口会损坏芯片上拉电阻考虑STM32的USART引脚内部通常已经有弱上拉或下拉。在一般应用中直接连接即可。但在干扰较强的环境或者线路较长时在RX引脚外部增加一个4.7kΩ到10kΩ的上拉电阻到3.3V可以帮助稳定空闲时的高电平状态减少因干扰误触发起始位的概率。注意在连接线路之前最好先用万用表的通断档检查一下你的杜邦线或焊接点。我遇到过好几次通信不通折腾半天软件最后发现是一根杜邦线内部断了。3. 软件驱动层配置从HAL库到寄存器3.1 使用STM32CubeMX进行快速初始化对于大多数应用特别是快速原型开发STM32CubeMXHAL库是最高效的组合。假设我们使用USART1进行通信。配置步骤在Pinout Configuration标签页中找到Connectivity-USART1。将Mode设置为Asynchronous异步模式。右侧会自动分配USART1_TX如PA9和USART1_RX如PA10引脚。在Parameter Settings子标签页中配置核心参数Baud Rate:115200(这是一个最常用、兼容性最好的波特率。务必确保通信双方完全一致)Word Length: 8 Bits (最常用)Parity: None (无校验)Stop Bits: 1 (1个停止位)Over Sampling: 16 Samples (默认即可)在NVIC Settings中如果你打算使用中断方式接收数据务必勾选USART1 global interrupt使能全局中断并设置合适的抢占优先级和子优先级。生成代码。CubeMX会自动生成初始化函数MX_USART1_UART_Init()并在main()中调用。关键参数解析波特率Baud Rate这是通信速度的基石。115200意味着每秒传输115200个二进制位bit。计算实际字节传输速率时要考虑到每个字节有8个数据位加上起始位和停止位通常按10位算一个字节帧。所以115200波特率约合每秒11520字节约11.2KB/s。这个速率对于传输传感器数据、控制指令绰绰有余。选择更高的波特率如921600可以提高吞吐量但对时钟精度和线路质量要求也更高。数据位、停止位、校验位8N18数据位、无校验、1停止位是最常见的配置。校验位奇校验或偶校验可以用于简单的错误检测但会增加协议复杂度在要求不高的场合可以不用。停止位可以是1、1.5或2位1位是标准。3.2 数据收发轮询、中断与DMA三种模式实战HAL库提供了三种收发方式选择哪种取决于你的数据量、实时性要求和系统负载。1. 轮询模式Polling这是最简单、最直接的方式。发送时调用HAL_UART_Transmit(huart1, pData, Size, Timeout)函数会一直等待直到数据发送完毕或超时才会返回。接收同理调用HAL_UART_Receive(huart1, pData, Size, Timeout)。// 轮询发送示例 uint8_t tx_buffer[] Hello STM32!; HAL_UART_Transmit(huart1, tx_buffer, sizeof(tx_buffer)-1, 1000); // 超时1秒 // 轮询接收示例等待接收5个字节 uint8_t rx_buffer[5]; if(HAL_UART_Receive(huart1, rx_buffer, 5, 1000) HAL_OK) { // 成功接收到5个字节 }心得轮询模式会阻塞程序运行。如果你的应用除了通信还有其他重要任务如按键扫描、LED闪烁长时间阻塞在UART接收上会导致系统反应迟钝。因此轮询模式仅适用于数据量极少、或对实时性要求极低、或是在初始化阶段进行简单通信的场景。2. 中断模式Interrupt这是最常用的模式。它不会阻塞主程序。当发送完成或接收到数据时会触发中断在中断服务程序ISR中处理。发送调用HAL_UART_Transmit_IT(huart1, pData, Size)启动中断发送函数立即返回。数据会在后台通过中断逐个字节发送发送完成后会触发HAL_UART_TxCpltCallback()回调函数。接收调用HAL_UART_Receive_IT(huart1, pData, Size)启动中断接收。当接收到指定数量的字节后会触发HAL_UART_RxCpltCallback()回调函数。// 启动中断接收 uint8_t rx_byte; // 通常定义一个全局或静态变量 HAL_UART_Receive_IT(huart1, rx_byte, 1); // 每次接收1个字节 // 接收完成回调函数弱定义需要用户重写 void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if(huart-Instance USART1) { // 处理接收到的单个字节 rx_byte process_byte(rx_byte); // 关键步骤重新启动中断接收否则只会接收一次 HAL_UART_Receive_IT(huart1, rx_byte, 1); } }避坑指南中断接收回调函数里处理完数据后**必须重新调用HAL_UART_Receive_IT**来使能下一次接收中断这是一个非常经典的“坑”。很多人发现只能收到第一个字节就是因为忘了这一步。3. DMA模式Direct Memory Access这是处理大量、高速数据流的终极武器。DMA控制器可以在不占用CPU资源的情况下在外设UART和内存数组之间直接搬运数据。发送HAL_UART_Transmit_DMA(huart1, pData, Size)。CPU放下指令后就可以去干别的事了DMA会自动把整块数据搬过去发送完成后触发HAL_UART_TxCpltCallback()。接收HAL_UART_Receive_DMA(huart1, pData, Size)。DMA会在后台持续接收数据并存入指定数组直到收满指定长度才触发回调。更高级的用法是结合空闲中断Idle Interrupt实现不定长数据的自动接收。DMA空闲中断实现不定长接收高级技巧 这是工业上非常实用的模式。我们无法预知对方会发多长的数据包DMA可以设置一个足够大的缓冲区比如256字节然后使能UART的空闲中断。当总线上一段时间没有新数据即空闲时触发空闲中断。在空闲中断服务函数里我们可以根据DMA当前传输计数器计算出已经接收了多少个字节从而处理这一帧完整的数据。// 1. 启动DMA接收指向一个大缓冲区 #define RX_BUF_SIZE 256 uint8_t rx_dma_buffer[RX_BUF_SIZE]; HAL_UART_Receive_DMA(huart1, rx_dma_buffer, RX_BUF_SIZE); // 2. 在初始化后使能空闲中断 __HAL_UART_ENABLE_IT(huart1, UART_IT_IDLE); // 3. 在USARTx_IRQHandler中添加空闲中断处理 void USART1_IRQHandler(void) { HAL_UART_IRQHandler(huart1); // 处理HAL库定义的中断 // 手动判断空闲中断标志 if(__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE) ! RESET) { __HAL_UART_CLEAR_IDLEFLAG(huart1); // 清除空闲中断标志必须清除 // 计算接收到的数据长度 uint16_t rx_len RX_BUF_SIZE - __HAL_DMA_GET_COUNTER(huart1.hdmarx); if(rx_len 0) { // 处理 rx_dma_buffer 中前 rx_len 个字节的数据 process_frame(rx_dma_buffer, rx_len); // 重新启动DMA接收注意需要先停止再重新设置长度和启动 HAL_UART_DMAStop(huart1); HAL_UART_Receive_DMA(huart1, rx_dma_buffer, RX_BUF_SIZE); } } }注意DMA模式配置相对复杂需要正确配置DMA流Stream和通道Channel并处理好缓冲区溢出和重启接收的逻辑。但一旦调通对于高速数据流如GPS模块持续输出、摄像头数据的接收效率是碾压性的。4. 应用层协议设计让数据变得有意义原始的字节流只是通信的基础。要让两块STM32真正理解彼此必须定义一套共同遵守的“语言”这就是应用层协议。4.1 为什么需要自定义协议假设设备A要发送一个温度值25.6和一个开关状态1。如果只是简单发送字符串25.61设备B无法可靠地区分哪里是温度哪里是状态更无法处理数据长度变化和错误。自定义协议的核心目的是帧同步、数据分界、错误校验。4.2 一个经典的帧结构设计示例这里介绍一个在单片机间通信中久经考验的帧结构帧头 数据长度 命令字 数据域 校验和。字段长度字节说明帧头Header2固定值如0xAA、0x55用于标识一帧的开始。接收方持续检测只有收到正确的帧头才开始组帧。数据长度Length1 或 2指示后面“命令字数据域”的总字节数。方便接收方预知帧尾位置。命令字CMD1标识这帧数据的类型或意图如0x01代表查询温度0x02代表控制LED。数据域DataN实际要传输的有效数据内容由命令字定义。可以为空。校验和Checksum1从“长度”字段开始到“数据域”结束所有字节的累加和或异或和取低8位。用于验证数据在传输过程中是否出错。一帧数据的示例十六进制AA 55 04 01 00 00 20 41 2AAA 55: 帧头04: 长度表示后面有4个字节0100 00 20 4101: 命令字假设代表“上传温度值”00 00 20 41: 数据域这是一个float类型的温度值25.0在内存中的4字节表示小端模式。2A: 校验和计算04 01 00 00 20 41 0x66取低8位0x66但这里示例是0x2A仅为示意。4.3 协议解析的状态机实现在接收方我们需要编写一个**状态机State Machine**来解析这个协议。这是串口通信编程的核心技巧。typedef enum { STATE_WAIT_HEADER1, STATE_WAIT_HEADER2, STATE_WAIT_LENGTH, STATE_WAIT_CMD, STATE_WAIT_DATA, STATE_WAIT_CHECKSUM } uart_parse_state_t; uart_parse_state_t state STATE_WAIT_HEADER1; uint8_t rx_buffer[64]; // 协议解析缓冲区 uint8_t data_index 0; uint8_t expected_length 0; uint8_t calculated_checksum 0; void parse_uart_byte(uint8_t byte) { static uint8_t cmd; switch(state) { case STATE_WAIT_HEADER1: if(byte 0xAA) { state STATE_WAIT_HEADER2; calculated_checksum 0; // 开始新一帧校验和清零 } break; case STATE_WAIT_HEADER2: if(byte 0x55) { state STATE_WAIT_LENGTH; } else { state STATE_WAIT_HEADER1; // 帧头错误回到初始状态 } break; case STATE_WAIT_LENGTH: expected_length byte; calculated_checksum byte; // 开始累加校验和 state STATE_WAIT_CMD; break; case STATE_WAIT_CMD: cmd byte; calculated_checksum byte; data_index 0; // 如果长度字段只包含命令字即数据域长度为0 if(expected_length 1) { state STATE_WAIT_CHECKSUM; } else { state STATE_WAIT_DATA; } break; case STATE_WAIT_DATA: rx_buffer[data_index] byte; calculated_checksum byte; // 判断是否接收完所有数据字节 if(data_index (expected_length - 1)) { // 总长度包含CMD state STATE_WAIT_CHECKSUM; } break; case STATE_WAIT_CHECKSUM: if(byte (calculated_checksum 0xFF)) { // 校验通过 // 完整的一帧数据已就绪 // cmd 存储了命令字 // rx_buffer 中存储了 data_index 个字节的数据 process_protocol_frame(cmd, rx_buffer, data_index); } else { // 校验失败丢弃这一帧可以增加错误计数器 } // 无论对错解析完一帧后都回到初始状态准备接收下一帧 state STATE_WAIT_HEADER1; break; } }这个parse_uart_byte函数需要在你的字节接收中断回调函数中调用。每次收到一个字节就喂给状态机。状态机会根据当前状态和收到的字节决定下一步该做什么。这种方法逻辑清晰能有效处理数据流中的干扰和粘包问题。5. 实战调试技巧与故障排查实录理论配置完毕真正上电调试时才是“大戏开场”。以下是多年调试串口通信积累下来的“生存指南”。5.1 调试工具链你的“眼睛”和“耳朵”逻辑分析仪这是最强大的调试工具没有之一。它能以波形的方式直观展示TX、RX引脚上的每一个比特位。你可以直接测量波特率、查看数据位、校验位、停止位是否正确一眼就能定位是硬件问题还是软件问题。对于复杂的协议解析逻辑分析仪往往能瞬间找到问题所在比如帧头错误、字节间隔异常。USB转TTL串口模块这是最常用的辅助工具。你可以用它连接其中一块STM32的串口到电脑用串口助手软件如XCOM、SSCOM、Putty监听通信数据。这样你就能看到“原始对话”是什么样子是发送方根本没发还是接收方没收到还是数据内容不对。万用表/示波器用于检查硬件连接。万用表测通断和电压TX/RX引脚在空闲时应为高电平约3.3V。示波器可以观察信号质量看看波形是否干净有没有过冲或振铃。5.2 常见问题排查清单从易到难当你发现通信失败时请按照以下顺序排查现象可能原因排查方法完全无任何数据1. 硬件连接错误TX/RX接反、未共地2. 串口外设时钟未使能3. 引脚配置错误未复用为USART功能4. 波特率等参数双方不一致1. 用万用表检查连线确认共地。2. 在CubeMX生成的MX_USARTx_UART_Init函数中检查__HAL_RCC_USARTx_CLK_ENABLE()是否被调用。3. 检查引脚配置代码确认GPIO模式设置为GPIO_MODE_AF_PP复用推挽输出等。4. 双方代码逐字核对波特率、数据位、停止位、校验位。能发送不能接收1. 接收中断未使能或未正确重装2. 接收缓冲区溢出3. 对方发送的数据格式错误1. 确认HAL_UART_Receive_IT在初始化后已调用并在回调函数中重装。2. 检查接收数组是否够大DMA是否配置了循环模式。3. 用逻辑分析仪抓取对方发送的波形看是否符合约定格式。接收数据为乱码1.波特率不匹配最常见2. 时钟源配置错误HSE/HSI选择PLL倍频3. 电气干扰1.重点检查用逻辑分析仪测量实际波特率。计算理论值波特率 f_CLK / (USARTDIV)。确保双方系统时钟和分频系数一致。2. 检查System Core-RCC中的时钟树配置特别是HSE晶振值是否与实际焊接的晶振一致。3. 缩短连线增加滤波电容或使用双绞线。数据丢包或错位1. 发送/接收缓冲区处理不及时溢出2. 中断优先级冲突导致UART中断被阻塞3. 协议解析逻辑有bug未处理粘包1. 提高数据处理速度或使用DMA。检查huart-RxState和huart-TxState状态。2. 在CubeMX的NVIC中给UART中断设置一个较高的抢占优先级。3. 在协议解析状态机中确保任何异常情况如中途收到帧头都能复位到初始状态。通信一段时间后死机1. 中断服务函数处理时间过长2. 栈溢出中断中定义了大数组3. DMA传输完成中断未及时处理或未清除标志1. 遵循“快进快出”原则在中断中只做标记将耗时处理放到主循环。2. 避免在中断函数内定义大型局部变量。使用全局或静态缓冲区。3. 检查DMA传输完成中断回调函数确保没有阻塞操作并确认相关标志位被正确清除。5.3 一个真实的调试案例波特率“幽灵”问题我曾遇到一个诡异的问题两块完全相同的STM32F103板子代码也一模一样但就是无法通信逻辑分析仪显示波形“看起来”正常。后来把波形放大到比特级别才发现问题实际测量出的比特宽度与理论值有微小偏差。比如115200波特率理论比特周期是8.68μs但实测是8.72μs。这个误差累积几十个比特后采样点就会偏移到比特位的边缘最终导致误码。根源两块板子的外部高速晶振HSE实际频率有细微差异一个是8.000MHz另一个可能是7.998MHz。虽然代码里都配置为8MHz但晶体本身的精度误差±20ppm和负载电容的微小差别导致了系统主频的微小差异进而影响了USART分频计算出的波特率。解决方案使用更高精度的晶振如±10ppm。使用芯片内部的HSI高速内部RC振荡器作为时钟源。虽然HSI绝对精度不如晶振通常±1%但对于同一型号的芯片其频率一致性非常好两块芯片之间的相对误差极小反而更适合这种点对点异步通信。在CubeMX中将RCC-High Speed Clock (HSE)改为Crystal/Ceramic Resonator然后在Clock Configuration标签页将System Clock Mux的源选择为HSI并配置好PLL即可。在软件上启用UART的过采样并适当调整波特率寄存器BRR的值进行微调不推荐新手使用。这个案例告诉我们当硬件和基础软件都查不出问题时不妨把目光投向更底层、更基础的时钟系统。