1. 从“Hello World”到工业控制：为什么USART依然是嵌入式开发的基石
如果你刚接触嵌入式开发，可能觉得串口通信（USART）是个老掉牙的话题，远不如网络、蓝牙、USB这些技术酷炫。但在我十多年的嵌入式项目经历里，从调试第一块51单片机，到设计复杂的工业控制器，USART几乎出现在每一个项目中。它就像电路板上的“普通话”，是调试的“生命线”，也是设备间最可靠、最直接的对话方式。即便在今天，当你需要快速验证一个传感器、与上位机交换数据，或者在资源受限的MCU上实现稳定通信时，USART往往是第一选择，甚至是唯一选择。
很多人，尤其是新手，容易混淆UART和USART。简单来说，UART是通用异步收发器，只支持异步通信；而USART是通用同步/异步收发器，多了一个“S”（Synchronous），意味着它既能像UART一样异步工作，也能在特定时钟信号同步下进行高速同步通信。在STM32这类现代MCU上，我们常说的“串口”通常指的就是其USART外设，因为它功能更全。但日常应用中，我们绝大多数时候都使用其异步模式，所以很多人也就习惯性地称其为“串口”或“UART”了。理解这个区别，有助于你在看芯片手册时，不会对USART那些额外的同步控制引脚感到困惑。
那么，USART到底解决了什么问题？想象一下，你的微控制器（MCU）需要告诉电脑“我收到温度数据了”，或者需要控制另一个模块的电机转动。MCU内部是并行的数字世界，而外部设备或长距离传输需要串行的、基于电平的物理信号。USART就是这个“翻译官”和“信使”，负责把MCU内部的并行数据，转换成一位一位（bit）串行发送的电平信号，同时也把接收到的串行信号，还原成MCU能理解的并行数据。它的核心价值在于简单、可靠、普适。几乎所有的MCU都内置了USART，几乎所有的PC都有USB转串口工具，几乎所有的调试终端软件（如SecureCRT、Putty、甚至简单的串口助手）都支持它。这种生态的普遍性，使得USART成为嵌入式开发中不可或缺的“基础设施”。
这篇文章，我将抛开教科书式的理论罗列，以一个老工程师的视角，带你深入USART的实战应用。我会重点分享在STM32平台上，如何从零配置USART，如何实现稳定可靠的数据收发，如何应对实际项目中那些让人头疼的坑（比如数据丢失、波特率误差），并探讨在更复杂的场景如Modbus协议、与RT-Thread等RTOS配合时，如何用好USART。无论你是正在学习STM32的新手，还是希望优化现有通信代码的开发者，这里都有你能直接“抄作业”的干货。
2. 拨开云雾：深入理解USART的硬件机制与配置逻辑
在动手写代码之前，我们必须先和硬件打交道。理解USART的硬件机制，是避免后续各种灵异问题的关键。很多人配置串口出错，根源在于对几个核心概念理解模糊。
2.1 核心概念拆解：波特率、数据帧与流控
首先，波特率不是“每秒传输的字节数”，而是每秒传输的符号数。一个符号通常代表一个二进制位（bit）。如果波特率是115200，就意味着信号线电平每秒变化115200次。那么，传输一个字节（8位）需要多长时间呢？这还得算上帧格式。一个常见的USART数据帧包括：1个起始位（低电平）、8个数据位、1个停止位（高电平），无校验位。这样，传输一个字节就需要10个符号位（1+8+1）。所以，在115200波特率下，理论上的字节传输速率是115200 / 10 = 11520 字节/秒。理解这个计算，你就能预估通信带宽，也能明白为什么波特率设置错误会导致全盘乱码——收发双方的时钟节拍根本对不上。
其次，数据帧格式是通信双方必须事先约定好的“暗号”。除了数据位长度（常为8位，也可以是9位），还有校验位和停止位。奇偶校验位用于简单的错误检测，但在要求高可靠性的工业场合，它往往不够用，需要更上层的协议（如Modbus的CRC校验）来保证。停止位不仅表示一帧的结束，还为接收方提供了宝贵的“缓冲时间”，以处理刚刚接收到的数据。在较高的波特率或较长的物理线缆下，适当增加停止位长度（如1.5位、2位）可以提升通信稳定性，代价是降低了有效数据吞吐率。
最后，硬件流控（RTS/CTS）是一个容易被忽略但极其重要的功能。当你的MCU通过USART高速接收大量数据时，其内部的接收缓冲区（可能只有几十字节）很容易被填满。如果没有流控，发送方（比如PC）会持续发送，导致MCU来不及处理的数据被新数据覆盖，从而丢失。硬件流控通过RTS（请求发送）和CTS（清除发送）两根额外的信号线，让收发双方能够“握手”：接收方准备好时，拉低CTS告诉发送方“你可以发了”；接收方缓冲区快满时，拉高CTS说“等等，我还没吃完”。在高速（如921600以上）或大数据量连续传输时，强烈建议启用硬件流控，这是保证数据不丢的硬件级保障。当然，这需要你的硬件电路和对方设备都支持。
2.2 STM32 CubeMX配置实战：从引脚到中断
现在，我们以STM32F103系列（一个非常经典的型号）为例，使用STM32CubeMX工具进行配置。CubeMX极大地简化了初始化过程，但知其然更要知其所以然。
第一步是时钟配置。USART外设需要时钟驱动，通常来源于APB1或APB2总线。以USART1为例，它挂在APB2总线下。在CubeMX的“Clock Configuration”标签页，你需要确保系统时钟（HCLK）和APB2外设时钟（PCLK2）被正确设置。USART的波特率发生器正是基于这个PCLK2时钟分频产生的。如果系统时钟配置错了，你计算出的波特率就会偏离标准值，导致通信失败。一个经验：使用外部晶振（HSE）作为时钟源，通常比内部RC振荡器（HSI）更精准，对串口通信的稳定性至关重要。
第二步是USART参数配置。在“Connectivity” -> “USART1”中，进行基本设置：
- Mode: 选择“Asynchronous”（异步模式），这是我们最常用的。
- Basic Parameters:
- Baud Rate: 输入目标值，如115200。CubeMX会自动计算并填入下方“USARTDIV”寄存器的值。你可以点开“计算器”图标，查看它根据当前PCLK2频率计算出的分频系数和实际波特率误差。务必关注这个误差值！对于标准波特率（如9600, 115200），误差最好控制在2%以内；对于一些非标波特率（如187500），误差可能较大，需要你手动调整分频系数或考虑更换时钟源。
- Word Length: 8 bits (或9 bits，如果使用奇偶校验)。
- Parity: None（通常），或者Odd/Evan（奇/偶校验）。
- Stop Bits: 1 bit（最常用）。
- Hardware Flow Control: 根据你的电路设计选择“Disable”, “RTS”, “CTS” 或 “RTS and CTS”。
- NVIC Settings: 这是关键！勾选“USART1 global interrupt”。我们将使用中断方式来接收数据，而不是低效的查询方式。在“GPIO Settings”标签页，你可以看到CubeMX已经自动为你分配了USART1_TX（PA9）和USART1_RX（PA10）引脚，以及流控引脚（如果启用）。
配置完成后，生成代码。CubeMX会为你生成MX_USART1_UART_Init()函数，里面完成了GPIO、USART外设的所有寄存器初始化。你需要做的，就是在这个初始化函数之后，开启接收中断。
// 在main.c中，初始化后添加 HAL_UART_Receive_IT(&huart1, &rx_buffer, 1); // 启动中断接收，每次接收1个字节到rx_buffer这行代码告诉HAL库：请让USART1工作在中断模式，每收到一个字节，就触发一次中断，并把数据存到rx_buffer变量里，然后调用你编写的回调函数。这就是中断驱动接收的核心。
3. 从字节到报文：构建稳健的串口数据收发引擎
配置好硬件只是第一步，如何稳定、高效地处理来来往往的数据流，才是软件设计的核心。直接在主循环里查询接收标志位是最简单但最糟糕的方式，它会严重阻塞CPU。而中断，是我们构建高效通信引擎的基石。
3.1 中断接收与环形缓冲区：应对数据洪流的“蓄水池”
为什么一定要用“中断+缓冲区”的模式？想象一下，USART接收数据就像水龙头滴水，CPU是接水的人。查询方式好比这个人一直盯着水龙头，水滴一下他就用手接一下，其他什么事也干不了。中断方式则是把水桶（缓冲区）放在下面，水滴到桶里发出“叮”的一声（中断信号），CPU听到声音后过来处理一下桶里的水，然后就可以继续去做别的事情（执行其他任务）。显然，中断方式效率高得多。
在HAL库中，我们使用HAL_UART_Receive_IT()启动中断接收。但这里有一个巨坑：这个函数启动的是一次性的中断接收。意思是，它接收完指定长度（比如1个字节）的数据后，就会关闭中断，不再接收。所以，你必须在中断回调函数里，再次调用HAL_UART_Receive_IT()来重启接收，否则串口就“聋了”。
更专业的做法是结合环形缓冲区。我们定义一个数组作为缓冲区，并维护读、写两个指针。中断服务程序只做一件事：把收到的字节放入写指针位置，然后写指针加一（循环）。应用层代码则从读指针位置取出数据。这样，即使数据涌入的速度暂时超过处理速度，数据也会被安全地缓存起来，不会丢失。
#define UART_RX_BUF_SIZE 256 uint8_t uart_rx_buf[UART_RX_BUF_SIZE]; volatile uint16_t uart_rx_wr_index = 0; // 写指针 volatile uint16_t uart_rx_rd_index = 0; // 读指针 volatile uint16_t uart_rx_count = 0; // 缓冲区中有效数据数 // USART1中断服务程序（在stm32f1xx_it.c中自动生成，我们只需修改回调函数） void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART1) { uint8_t tmp = rx_buffer; // 假设rx_buffer是全局变量，存着刚收到的字节 // 将数据存入环形缓冲区 uint16_t next_wr_index = (uart_rx_wr_index + 1) % UART_RX_BUF_SIZE; if (next_wr_index != uart_rx_rd_index) { // 缓冲区未满 uart_rx_buf[uart_rx_wr_index] = tmp; uart_rx_wr_index = next_wr_index; uart_rx_count++; } else { // 缓冲区已满，数据丢失！这里可以增加错误计数或指示灯报警 } // 重启接收中断，等待下一个字节 HAL_UART_Receive_IT(&huart1, &rx_buffer, 1); } }在主循环或某个任务中，你可以检查uart_rx_count，如果大于0，就从uart_rx_rd_index位置读取数据并处理，同时更新读指针和计数。这样就实现了一个线程安全的、高效的串口数据接收引擎。
3.2 发送策略：阻塞、中断与DMA
发送数据相对简单，但也有几种模式，选择哪种取决于你的应用场景和对实时性的要求。
阻塞式发送(
HAL_UART_Transmit)：这是最简单的。函数会一直等待，直到所有数据发送完毕才返回。缺点很明显：在发送大量数据时，CPU会被完全占用，无法响应其他事件（包括接收中断！）。这可能导致接收数据丢失。所以，它只适用于极少量、非频繁的发送，比如发送一个调试信息。中断式发送(
HAL_UART_Transmit_IT)：函数启动发送后立即返回，USART每发送完一个字节或一半缓冲区（取决于具体实现）会产生中断，在中断中继续发送剩余数据。这解放了CPU，但频繁的中断仍然有一定开销。适用于中等数据量、发送间隔不固定的场景。DMA发送(
HAL_UART_Transmit_DMA)：这是最高效的方式。DMA（直接存储器访问）是一个独立于CPU的硬件单元，它可以在CPU不干预的情况下，自动将内存中的数据搬运到USART的发送数据寄存器。你只需要设置好源地址、目标地址和数据长度，启动DMA，就可以完全不管了，CPU可以全力处理其他任务。对于需要连续、高速发送数据的应用（如通过串口传输图像数据块），DMA是唯一的选择。配置DMA发送时，要注意DMA通道的选择、数据宽度（通常为字节）、传输模式（通常为内存到外设）以及发送完成回调函数（用于通知应用层发送完毕）。
注意：使用DMA或中断发送时，必须确保发送缓冲区在发送完成前是有效的。如果缓冲区是局部变量，函数返回后缓冲区可能被释放或覆盖，导致发送乱码。通常需要将发送数据定义为全局变量或静态变量，或者使用动态内存分配并确保生命周期。
3.3 报文解析：从原始字节流到结构化数据
设备间通信很少只传输一个孤立的字节，通常是按照一定格式组成的“报文”或“帧”。常见的帧格式有：定长帧、变长帧（带长度域）、特定首尾标志帧（如以0xAA 0x55开头，0x0D 0x0A结尾）。
解析报文的核心是状态机。我们以一个简单的“首尾标志帧”为例：帧头0xAA，帧尾0x0D 0x0A，中间是变长的数据。
typedef enum { FRAME_STATE_IDLE, // 空闲状态，等待帧头 FRAME_STATE_RECEIVING, // 接收数据状态 FRAME_STATE_COMPLETE // 帧接收完成状态 } uart_frame_state_t; uart_frame_state_t frame_state = FRAME_STATE_IDLE; uint8_t frame_buffer[100]; uint16_t frame_index = 0; void uart_frame_processor(uint8_t byte) { switch (frame_state) { case FRAME_STATE_IDLE: if (byte == 0xAA) { // 检测到帧头 frame_state = FRAME_STATE_RECEIVING; frame_index = 0; } break; case FRAME_STATE_RECEIVING: if (byte == 0x0D) { // 可能是帧尾的第一个字节，需要暂存状态，这里简化处理 // 更严谨的做法是引入一个子状态 frame_state = FRAME_STATE_COMPLETE; } else if (frame_index < sizeof(frame_buffer)) { frame_buffer[frame_index++] = byte; // 存储数据 } else { // 缓冲区溢出，帧错误，复位状态机 frame_state = FRAME_STATE_IDLE; } break; case FRAME_STATE_COMPLETE: if (byte == 0x0A) { // 确认帧尾，一帧数据接收完毕 // 调用上层函数处理 frame_buffer 中的数据，长度为 frame_index process_frame(frame_buffer, frame_index); } // 无论是否匹配，都回到空闲状态，准备接收下一帧 frame_state = FRAME_STATE_IDLE; break; } }在主循环中，我们从环形缓冲区读取字节，并调用uart_frame_processor进行处理。这种状态机解析器结构清晰，能够很好地处理数据流中的粘包、断包问题。对于更复杂的协议如Modbus，原理相同，只是状态更多，校验更严格（需要计算CRC）。
4. 工业级应用进阶：Modbus RTU协议与RTOS下的串口驱动
当你的嵌入式设备需要与PLC、HMI（人机界面）或工业传感器组网时，Modbus协议几乎是标配。而在复杂的多任务系统中，如何让串口驱动安全地服务于多个任务，就需要RTOS（实时操作系统）的协助了。
4.1 基于USART实现Modbus RTU从站
Modbus RTU是一种基于串行总线的主从式通信协议。帧格式包括：从站地址、功能码、数据域、CRC校验。作为从站（比如你的STM32设备），核心任务是：1. 接收并校验报文；2. 解析功能码；3. 操作本地寄存器（保持寄存器、输入寄存器、线圈等）；4. 组织响应报文并发送。
实现的关键点在于定时器。Modbus RTU规定，帧与帧之间需要有至少3.5个字符时间的静默间隔（T3.5）作为帧间隔。这意味着，我们的接收状态机在收到一个字节后，需要启动一个定时器（超时时间略大于3.5个字符时间）。如果在定时器超时前收到下一个字节，就重置定时器并继续接收；如果定时器超时，则认为一帧数据接收完毕，开始处理。
// 在串口接收中断回调函数中 void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { // ... 将数据存入环形缓冲区 ... // 重置帧接收超时定时器 __HAL_TIM_SET_COUNTER(&htim3, 0); // 假设使用TIM3做超时定时器 HAL_TIM_Base_Start_IT(&htim3); // ... 重启接收中断 ... } // 定时器超时中断回调函数 void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM3) { HAL_TIM_Base_Stop_IT(&htim3); // 标志位置位，通知主循环或任务：一帧Modbus数据接收完成 modbus_frame_ready_flag = 1; } }主循环检测到modbus_frame_ready_flag置位后，就从环形缓冲区中取出完整的一帧数据进行CRC校验。如果校验通过，就根据从站地址和功能码，去访问对应的寄存器映射表（通常是一个大数组），然后组织响应帧，通过USART发送回去。CRC校验可以使用查表法以提高速度。整个过程中，USART的稳定性和定时器的精准度至关重要。
4.2 在RT-Thread等RTOS中管理串口驱动
在裸机程序中，我们的环形缓冲区和状态机运行在主循环或中断中。但在RTOS（如RT-Thread、FreeRTOS）中，我们有多个任务（线程）可能需要读写串口。例如，一个“通信任务”负责接收和解析Modbus指令，一个“日志任务”需要通过串口打印调试信息。如何避免冲突？
RTOS通常提供了完善的设备驱动框架。以RT-Thread为例，USART会被抽象成一个“字符设备”。我们通过rt_device_find()找到串口设备，用rt_device_open()以中断或DMA模式打开它，然后用rt_device_read()和rt_device_write()进行读写。这些API内部已经实现了互斥锁，保证了多线程访问的安全性。
更常见的使用模式是生产者-消费者模型结合消息队列：
- 创建一个串口接收线程（高优先级），它阻塞式地调用
rt_device_read()。当有数据到达时，rt_device_read()返回，该线程将收到的原始数据包（或初步解析后的消息）通过rt_mq_send()发送到一个消息队列。 - 创建一个或多个数据处理线程（如Modbus解析线程、数据存储线程），它们阻塞式地调用
rt_mq_recv()从消息队列中获取消息进行处理。 - 对于发送，可以创建一个发送线程，或者让各个任务通过一个互斥锁保护的发送函数来调用
rt_device_write()。
这样做的好处是解耦和流量控制。接收线程只负责高效地“收快递”，并把“快递”扔进队列；处理线程按自己的节奏从队列里“取快递”。消息队列满了，接收线程会阻塞，从而反压上游（本质上是让USART接收缓冲区满，通过硬件流控或软件停止读取来通知发送方减速），避免了数据丢失。这是构建稳健嵌入式系统的经典模式。
5. 调试血泪史：那些年我踩过的串口坑与避坑指南
理论再完美，也抵不过实际电路和代码中的一个个暗坑。下面分享几个让我记忆深刻的教训，希望能帮你节省大量调试时间。
5.1 电平匹配与共地：通信的物理基础
这是最基础，也最容易出问题的地方。USART是TTL电平，通常是0V表示逻辑0，3.3V或5V表示逻辑1。你的PC的串口（DB9接口）是RS-232电平，采用负逻辑，-3V ~ -15V表示逻辑1，+3V ~ +15V表示逻辑0。两者直接连接会损坏芯片！必须使用USB转TTL串口模块（如CH340G、CP2102、FT232等）或RS-232电平转换芯片（如MAX232）进行电平转换。
另一个隐形杀手是地线。通信双方必须共地，即GND连接在一起，否则电平参考点不同，信号无法正确识别。在调试时，经常因为用了不同的电源（比如开发板用USB供电，模块用电池供电）而忘记连接GND，导致通信时好时坏，数据乱码。第一条检查准则：确保电平转换正确，且GND可靠连接。
5.2 波特率误差与时钟精度
我曾遇到一个诡异的问题：设备A和B通信，短距离（1米内）完全正常，线缆延长到5米后，误码率急剧上升。排查了屏蔽、干扰所有因素后，最后发现是设备B的MCU使用了内部RC振荡器（HSI）作为系统时钟源，其精度较差（可能±1%），在115200波特率下，累积的时钟误差在长距离传输时被放大，导致采样点偏移，从而产生误码。教训：对于超过1Mbps或长距离通信，务必使用外部晶振（HSE）作为时钟源。在CubeMX生成代码后，可以检查SystemClock_Config()函数，确认RCC配置是否正确指向了HSE。
5.3 中断优先级与阻塞调用
这是一个经典的死锁场景：在USART接收中断服务程序（ISR）中，你调用了某个函数，而这个函数内部试图获取一个已经被低优先级任务占用的互斥锁（Mutex）。由于ISR的优先级高于任何任务，它无法被挂起等待，于是程序死锁。
在RTOS中，中断服务程序应该尽可能短小，只做最紧急的事情（如保存数据到缓冲区、发送信号量）。复杂的处理应该交给任务（线程）去完成。同样，绝对禁止在中断服务程序中使用HAL_UART_Transmit这类阻塞式发送函数，它会“卡死”在中断里，导致系统崩溃。在中断里，只能使用HAL_UART_Transmit_IT或基于DMA的非阻塞发送。
5.4 缓冲区溢出与数据丢失
这是环形缓冲区设计不周导致的。我早期的一个项目，串口接收缓冲区只设置了64字节。平时调试命令够用，但有一次设备突然上传一大段历史日志，瞬间冲垮了缓冲区，导致关键数据丢失且没有任何告警。改进方案：
- 根据最大可能的数据突发量，合理设置缓冲区大小（比如512或1024字节）。
- 在缓冲区满时，要有明确的处理策略：是丢弃最旧的数据（覆盖），还是丢弃最新的数据（并置错误标志），或者通过流控让发送方暂停。对于关键数据，应采用“丢弃最新+报警”的策略。
- 增加缓冲区水位监测机制，当数据量超过某个阈值时，提前预警。
5.5 电磁干扰与硬件设计
在电机控制、变频器等强干扰环境中，串口通信极易受到干扰。表现为随机出现乱码，甚至导致MCU死机。硬件上可以采取以下措施：
- 隔离：使用磁耦或光耦隔离芯片（如ADM2483、ISO3082）对USART信号进行电气隔离，切断地环路干扰。
- 滤波：在USART的RX/TX线上串联一个小电阻（如22欧姆），并并联一个到地的电容（如几十皮法），构成一个简单的RC低通滤波器，滤除高频毛刺。
- 布线：远离电源线和功率线，如果可能，使用双绞线或屏蔽线。
- 终端电阻：在长距离（超过10米）或高速率下，在传输线的末端并联一个120欧姆的终端电阻，可以抑制信号反射。
软件上，则必须依赖协议层的校验和重传机制。像Modbus的CRC校验就能有效识别出被干扰的错误帧，然后主站可以通过超时重发来保证数据的最终正确性。不要指望物理层是完美的。
6. 性能优化与高级话题：让串口飞起来
当你的应用对通信速率或实时性要求极高时，就需要考虑一些高级优化技巧。
6.1 DMA双缓冲与空闲中断实现“免拷贝”接收
前面提到的“中断+环形缓冲区”模式，每个字节都会触发一次中断，并且需要一次内存拷贝（从USART数据寄存器到用户缓冲区）。当波特率高达几Mbps时，中断开销可能成为瓶颈。
更高级的方案是“DMA+空闲中断”：
- 配置DMA以循环模式（Circular Mode）工作，将USART接收数据寄存器直接搬运到一个大的线性缓冲区（比如1024字节）。
- 开启USART的空闲中断（Idle Interrupt）。当USART接收线上持续一个帧的时间（比如10个bit时间）没有新数据时，会产生空闲中断。
- 在空闲中断服务程序中，你可以知道：从上次处理完到现在，DMA又搬运了多少新数据到缓冲区。通过计算DMA当前写入位置和上次读取位置的差值，就能得到一包完整的数据长度，然后一次性处理这一整包数据。
- 由于DMA是硬件自动搬运，CPU零干预；空闲中断只在数据包间隔时触发一次，中断频率极低。这实现了近乎“免拷贝”（数据直接由DMA存放到目标缓冲区）、高效率的批量数据接收。这是处理高速、大数据量串口通信（如GPS模块持续输出、某些高速传感器）的终极方案。在STM32的HAL库中，可以通过
HAL_UARTEx_ReceiveToIdle_DMA()这个函数来方便地启用此模式。
6.2 使用硬件FIFO与自动波特率检测
一些高端的STM32系列（如F4, F7, H7）的USART外设自带硬件FIFO（先进先出队列）。你可以配置FIFO的触发阈值（例如，当RX FIFO中有8个字节时再产生中断），从而进一步减少中断次数，提升系统效率。
另外，某些USART支持自动波特率检测功能。这在需要与不同波特率设备自适应通信的场景下非常有用。它通过检测第一个起始位的长度来推算出发送方的波特率，并自动配置本机。不过，这个功能对起始位的波形质量要求较高，在干扰大的环境中可能不可靠。
6.3 软件层面的协议优化
最后，在协议设计上也可以优化。例如：
- 二进制协议优于字符串协议：像Modbus RTU这种二进制协议，比发送“TEMP:25.6\r\n”这样的ASCII字符串协议更紧凑，解析更快，占用带宽更小。
- 合并发送：将多个需要发送的小数据包在应用层缓存起来，合并成一个大的数据包一次性发送，可以减少帧头帧尾的开销和发送调度的次数。
- 选择性应答：在全双工通信中，不一定每帧都需要应答。可以设计成“命令帧需要应答，数据上报帧不需要应答”的模式，减少网络流量和响应延迟。
USART串口通信，这个看似简单的技术，其深度和广度足以支撑起从入门学习到工业级产品的整个跨度。它考验的不仅是对一个外设寄存器的配置，更是对硬件原理、中断系统、实时系统、数据结构乃至抗干扰设计的综合理解。
