很多做串口通信的工程师可能都有过这样的经历板子跑起来之后小数据量下一切正常一旦数据量上来上位机收到的数据就开始跳字节、缺帧、甚至整包丢失。你先是怀疑波特率不对拿示波器量了量波形发现电平、时序都没问题然后又怀疑是接线太长、干扰太大换了屏蔽线、加了磁环情况有所缓解但数据量再大一点又会丢。最后你才意识到问题的根源不在物理层而在你的 MCU 根本来不及把串口收到的数据拿走新的数据已经把旧数据覆盖掉了。这就是串口丢数据最常见、也最容易被忽略的底层原因——缓冲区不够或者更准确地说是没有用 FIFO 把数据到达和数据处理这两件速度不匹配的事情解耦开。这篇文章会讲清楚三件事串口 FIFO 缓存的本质是什么、为什么它能在绝大多数场景下解决丢数据问题、以及当你真的遇到丢数据时该怎么从硬件到软件一步步排查和解决。文章会同时覆盖 MCU 嵌入式开发、FPGA 设计和上位机通信这几个方向适合正在调试串口通信的开发者收藏。1. 这篇文章真正要解决的问题先说判断串口丢数据95% 以上不是因为物理层信号差而是因为接收端处理不过来数据在等待处理的过程中被覆盖了。FIFO 缓存就是用来解决处理不过来这个问题的标准手段。但处理不过来又分很多层。如果事情发生在 MCU 内部可能是串口外设收到一个字节后触发中断但你的中断服务函数还没来得及执行或者执行了但耗时太长下一个字节已经把接收寄存器覆盖了。如果发生在 FPGA 设计里可能是跨时钟域的数据没有做缓冲读时钟和写时钟不同步数据在交接过程中丢失。如果发生在上位机端可能是你的程序读取串口缓冲区不及时缓冲区满了以后驱动就把新到的数据丢弃了。这三种场景表面上看都不一样但本质是同一个问题数据的产生速率是恒定的、由外部设备决定的而数据的消费速率是不可预测的、受程序执行逻辑影响的。这两者之间必须有一个缓存区来匀一匀这个缓存区就是 FIFO。读这篇文章的人我觉得可以分成三类MCU 开发者正在用 STM32、GD32、ESP32 等芯片做串口通信遇到数据量大就丢帧的困扰想搞清楚硬件 FIFO 和软件 FIFO 到底怎么配合。FPGA 开发者正在做 UART 收发模块或高速数据采集需要在系统里插入同步或异步 FIFO 来做跨时钟域缓存想理解 FWFT 模式、FIFO 资源配置这类细节。上位机或嵌入式 Linux 开发者在用串口调试工具、Python 读取串口数据时发现接收缓冲区溢出想弄明白丢数据是驱动层的问题还是应用层的问题。这篇文章不是某一个芯片的官方手册翻译而是把串口通信里为什么需要 FIFO、FIFO 怎么用、丢了数据怎么排查讲成一个完整思路。读完以后你可以直接回到自己的项目里对照检查和落地。2. 串口 FIFO 到底是啥用快递驿站理解缓存很多文章一上来就讲环形缓冲区、格雷码、读指针写指针概念堆了一堆但读者还是不知道它到底解决了什么。我先用最朴素的方式建立一个直觉。假设你正在工位上写代码这时候快递员给你打电话说有包裹到了你立刻下楼来拿。你放下手头的事跑下去拿了快递回来继续写代码。如果快递员五分钟打一次电话你还能忍受如果是一个接一个地打你就彻底没法干活了。更麻烦的是如果你正在开会、在写一段不能中断的关键代码你没法马上下楼快递员就不会等你——他直接带着快递走了。串口通信就是这样。外部设备以固定波特率向你的 MCU 发数据每个字节到达的时间是确定的。你的 CPU 就像一个正在忙各种任务的工程师必须暂停当前工作去处理串口数据。如果处理得不够快下一个字节就来了。现在引入 FIFO就相当于在楼下装了一个快递柜。快递员到了以后不需要等你本人直接把包裹放进柜子里然后去做下一件事。你有空了再来取。快递柜就是 FIFO它把你的响应时间和数据到达时间解耦了。所以FIFO 的正式定义是FIFOFirst In First Out先入先出队列是一种数据缓存结构数据按照到达顺序进入缓冲区也按照同样的顺序被取出。在串口通信场景里FIFO 起到了速率匹配和突发缓冲的作用——即使 CPU 暂时没空处理数据也能在缓存里安全地等一会儿。这里要区分两个层级的 FIFO很多人会混淆类型位置典型深度作用缺点硬件 FIFO串口外设/FPGA 内部几十字节到几 KB不同芯片差异很大在硬件层面缓冲数据不需要 CPU 参与深度有限溢出后数据仍然会丢软件 FIFOMCU 内存/上位机内存由你分配可到几 KB 甚至几 MB在软件层面保存数据等待应用程序处理占用内存需要自己维护读写逻辑很多 MCU 的串口外设其实自带了几字节到上百字节的硬件 FIFO但因为深度有限只能起到临时顶一下的作用。真正解决大流量丢数据问题光靠硬件 FIFO 是不够的必须结合软件 FIFO 甚至 DMA把这些数据先整体搬运到内存里再慢慢解析。3. 为什么串口会丢数据速率失配与中断延迟要真正解决丢数据问题就得先搞清楚数据到底是在哪个环节丢的。我用一个具体例子来解释。假设你的串口波特率是 115200典型 UART 帧格式是 1 个起始位 8 个数据位 1 个停止位共 10 个 bit。那么每秒可以传输 11520 个字节平均每个字节间隔约 86.8 微秒。也就是说你的系统必须保证在最坏情况下每 86.8 微秒就要把串口收到的数据搬走一次。如果串口外设没有硬件 FIFO或者 FIFO 深度只有 1那么你必须在下一个字节到达之前把当前数据寄存器里的值读出来否则新的字节会把旧的覆盖掉——数据就这样丢了。但 86.8 微秒听起来并不短为什么还会丢因为必须搬走数据这个动作不是简单地执行一条读指令而是整个中断响应链条串口硬件收到一个字节置位接收中断标志。中断控制器响应这个中断。CPU 暂停当前任务保存现场跳到中断服务函数。中断服务函数里读取数据寄存器把数据写入缓冲区。恢复现场从中断返回。如果这段代码里有任何一步被耽误比如你在一段临界区里关了中断做 Flash 写操作、在 RTOS 里中断被更高优先级的中断抢占、或者是中断服务函数里做了计算、打印日志这类耗时操作那么超过 86.8 微秒是非常容易的。一旦超时数据就被覆盖了。更隐蔽的情况是你的中断服务函数本身执行得很快但你在中断里只是把数据放到了一个全局数组里。主循环里的解析代码还没来得及处理这个数组下一个字节又来了数组越界后覆盖了前面的数据。这是另一种丢数据不是硬件层面丢的而是软件层面处理不过来。所以串口丢数据的根因可以总结为三种模式硬件溢出数据到达时硬件接收缓冲已被占满新数据覆盖旧数据触发溢出错误。中断延迟溢出中断响应不及时虽然后台有能力处理数据但前台没有及时接住数据。软件消费不及时数据已经进了内存缓冲区但应用层解析速度跟不上缓冲区满了以后只能丢弃新数据。理解了这三种模式后面的排查和解决方案就都有了方向。4. 硬件 FIFO 深度解析MCU、USART 与 FPGA4.1 MCU 串口外设的硬件 FIFO不同厂商的 MCU串口外设的缓存能力差异很大。一些芯片的 UART 外设自带较深的硬件 FIFO。以 ESP32 的 UART 为例它的硬件 FIFO 深度达到 128 字节数据到达后先存进 FIFOCPU 可以选择在 FIFO 达到某个阈值时再触发中断这样中断频率大幅降低给 CPU 留出了更多处理时间。另一类 MCU 则会提供接收超时中断和空闲中断等机制用于配合硬件 FIFO 做帧级别的接收。而经典的 STM32F1/F4 系列USART 外设本身没有可配置的深 FIFO接收路径上基本上是一个移位寄存器加一个数据寄存器缓冲深度非常浅。这也是很多人在 STM32 上做串口通信时感到容易丢数据的一个客观原因——硬件缓冲能力有限软件必须及时取走数据。所以这里的第一条建议就是先翻开你所用芯片的数据手册确认串口外设到底有没有硬件 FIFO、深度是多少、有没有 FIFO 阈值中断或 DMA 请求事件。这些信息直接决定了你的软件策略。如果你的芯片本来就有 128 字节硬件 FIFO你只需要在 FIFO 半满或超时时触发中断批量读取就能轻松应对高速数据如果芯片没有硬件 FIFO你就要更认真地考虑用 DMA 或者高效的软件中断处理。4.2 FPGA 角度看 FIFO同步、异步与 FWFT在 FPGA 设计中FIFO 通常不是一个概念而是直接由 IP 核提供的物理资源。最常见的两类是同步 FIFO 和异步 FIFO。同步 FIFO的读时钟和写时钟是同一个时钟常用于同频时钟域内部的数据缓冲。异步 FIFO的读时钟和写时钟不同用于跨时钟域的数据传输。在串口场景下异步 FIFO 最常见的使用方式是把接收到的串行数据按字节写入 FIFO系统处理逻辑用自己的时钟域从另一端读取。选异步 FIFO 时IP 核里通常会问你要不要启用 FWFTFirst-Word Fall-Through模式。FWFT 模式也叫首字直通模式指的是只要 FIFO 非空第一个数据就会自动出现在读数据总线上不需要你先拉一次读使能把它推出来。普通模式下你必须先产生一次读请求数据才会出现在输出总线上虽然只差了一个时钟周期但在某些对延迟敏感的高速接口里这一个周期就会影响时序收敛。所以答案是FWFT 和以太网没有绑定关系但以太网 MAC、PCIe、高速 ADC 采集这一类跨时钟域且需要快速判断FIFO 里有没有数据、数据是否有效的场景FWFT 模式确实更常用因为它天然带了数据有效的语义方便下游逻辑直接判断。另外FPGA 里的 FIFO 可以直接用分布式逻辑LUT/FF实现也可以用块存储资源Block RAM实现。有些工程师发现自己只是个 8 字节深度的缓存却把 BRAM 配成 512 深度白白浪费了大块存储资源也有人在需要 4KB 深度的 FIFO 时用分布式逻辑实现把 LUT 消耗殆尽。我在一些开源项目里也看到高云 Gowin 这类国产 FPGA 上正确选择 FIFO 的分布式 RAM 与 Block RAM 实现方式可以节省大量逻辑资源的说法虽然 90% 这个数字得看具体场景但方向是对的FIFO 的配置策略对资源消耗影响非常大深度小、位宽窄的 FIFO 优先选分布式 RAM深度大的选 Block RAM。4.3 硬件 FIFO 的局限硬件 FIFO 不是万能的它的局限主要有三点深度有限。FPGA 里你可以把 FIFO 配得很大但资源是有限的MCU 里的硬件 FIFO 更是只有几十到几百字节。如果数据速率高于消费速率且持续一段时间FIFO 一定会满。溢出即丢。FIFO 满了以后写入的数据会被丢弃同时产生溢出标志。如果你不及时处理这个标志后续所有数据都会因为写入位置不对而错乱。无法替代协议层重传。如果通信链路本身存在物理干扰或者双方速率严重不匹配FIFO 只能缓冲不能补救。可靠的通信还是需要协议层设计重传、校验和应答机制。换句话说硬件 FIFO 解决的是短时突发的速率失配解决不了长期平均速率不够的传输瓶颈。5. 软件 FIFO手写环形缓冲区这才是防丢数据的核心对于 MCU 开发者来说最实用、最可控的做法是在内存里维护一个软件 FIFO——通常也叫环形缓冲区。它不依赖芯片特定的硬件外设移植性好深度可以自己决定。5.1 环形缓冲区原理环形缓冲区的核心思想是用一段连续内存和一个读指针、一个写指针组成队列。数据写入时写指针前进数据读取时读指针前进。当指针到达缓冲区末尾时回绕到开头因此逻辑上是一个环。判断缓冲区状态空读指针 写指针满在读指针追上写指针之前预留一个空位或者用额外计数器记录数据个数工程里最常用的是预留一个空位法和计数法。计数法更直观但需要多维护一个变量在中断与主循环之间共享时要注意原子性。我下面的示例采用计数法因为它最容易理解也方便你把它改成任意平台。5.2 完整代码实现串口环形缓冲区先看头文件// 文件路径ring_buffer.h #ifndef RING_BUFFER_H #define RING_BUFFER_H #include stdint.h #include stdbool.h #define RBUF_SIZE 512 // 缓冲区大小必须为 2 的幂时可用位运算优化这里保持通用 typedef struct { uint8_t buffer[RBUF_SIZE]; volatile uint16_t head; // 写指针 volatile uint16_t tail; // 读指针 volatile uint16_t count; // 缓冲区中有效数据个数 } ring_buffer_t; void rbuf_init(ring_buffer_t *rb); bool rbuf_write(ring_buffer_t *rb, uint8_t data); bool rbuf_read(ring_buffer_t *rb, uint8_t *data); uint16_t rbuf_available(ring_buffer_t *rb); bool rbuf_is_empty(ring_buffer_t *rb); bool rbuf_is_full(ring_buffer_t *rb); #endif再看实现文件// 文件路径ring_buffer.c #include ring_buffer.h void rbuf_init(ring_buffer_t *rb) { rb-head 0; rb-tail 0; rb-count 0; } bool rbuf_write(ring_buffer_t *rb, uint8_t data) { if (rb-count RBUF_SIZE) { return false; // 缓冲区已满写入失败 } rb-buffer[rb-head] data; rb-head (rb-head 1) % RBUF_SIZE; rb-count; return true; } bool rbuf_read(ring_buffer_t *rb, uint8_t *data) { if (rb-count 0) { return false; // 缓冲区为空读取失败 } *data rb-buffer[rb-tail]; rb-tail (rb-tail 1) % RBUF_SIZE; rb-count--; return true; } uint16_t rbuf_available(ring_buffer_t *rb) { return rb-count; } bool rbuf_is_empty(ring_buffer_t *rb) { return rb-count 0; } bool rbuf_is_full(ring_buffer_t *rb) { return rb-count RBUF_SIZE; }核心逻辑解释head是写指针每写入一个字节后前进一位越界回绕。tail是读指针每读取一个字节后前进一位越界回绕。count表示当前缓冲区里有多少有效数据是判断空和满的唯一依据。head、tail、count都加了volatile因为它们会同时被中断服务函数和主循环访问防止编译器优化掉读取操作。这里要特别注意如果消费者在一个线程/主循环中读生产者在中断里写那么一个函数只允许被单侧访问的部分需要避免交叉冲突。上面这个实现假设中断写入、主循环读取这是最简单也最常见的串口应用模式。如果要在多线程环境使用必须加临界区保护或互斥机制。5.3 在串口中断里使用环形缓冲区有了这个环形缓冲区串口接收中断就变得非常轻量每次收到一个字节只要把它写进缓冲区就行解析工作全部放到主循环。下面是一个 STM32 HAL 风格的示意代码核心思路在其他平台同样适用// 假设在 stm32f4xx_it.c 或其他中断源文件中 #include ring_buffer.h extern ring_buffer_t uart_rx_rb; extern volatile uint8_t uart_rx_overflow_flag; // 溢出标志用于统计丢包 void USART1_IRQHandler(void) { uint8_t data; if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_RXNE)) { data (uint8_t)(huart1.Instance-DR 0xFF); // 如果缓冲区满计数丢包但不阻塞中断 if (!rbuf_write(uart_rx_rb, data)) { uart_rx_overflow_flag; } } }主循环里解析数据// 文件路径main_loop_demo.c uint8_t buf[128]; uint16_t len 0; while (1) { uint8_t ch; if (rbuf_read(uart_rx_rb, ch)) { if (ch \n) { // 一帧结束处理 buf[0..len-1] process_frame(buf, len); len 0; } else if (len sizeof(buf)) { buf[len] ch; } else { len 0; // 帧过长丢弃 } } else { // 没有数据时做一些其他低优先级任务 do_other_tasks(); } }这样做的最大收益是中断服务函数执行时间被压缩到极致只有一次写内存的操作不会再因为中断耗时过长而导致下一字节覆盖上一字节。真正费时的解析和逻辑处理全部交给了主循环你有充分的余量去判断帧边界、校验数据和完成业务逻辑。5.4 进阶方案中断 DMA如果串口波特率很高比如 921600 甚至 2M 以上或者 CPU 负载已经很重那么让 CPU 一个字节一个字节地进中断就不合适了。此时应该用 DMA。DMA 的思路是配置好 DMA 通道后串口硬件每收到一个字节DMA 控制器自动把数据搬到内存不需要 CPU 干预。当接收到指定长度或发生空闲时DMA 产生中断CPU 才来处理。代码示意STM32 HAL 空闲中断 DMA// 初始化时启动 DMA 接收 HAL_UARTEx_ReceiveToIdle_DMA(huart1, rx_dma_buf, RX_DMA_BUF_SIZE); __HAL_DMA_ENABLE_IT(hdma_usart1_rx, DMA_IT_HT); // 半传输中断可选 // 在 UART 空闲中断回调中处理一帧数据 void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart huart1) { // Size 表示本次 DMA 接收了多少字节 process_frame(rx_dma_buf, Size); // 重新启动下一次 DMA 接收 HAL_UARTEx_ReceiveToIdle_DMA(huart1, rx_dma_buf, RX_DMA_BUF_SIZE); } }DMA 模式下的缓冲策略通常采用双缓冲一块缓冲区在接收数据另一块在处理数据两块交替使用这样 DMA 永远不会因为没有缓冲区而停下。这是很多高速串口方案的标准做法。6. 丢数据的根因排查从现象到本质如果你已经写好了 FIFO还是发现数据会在某些情况下丢失可以按下面的思路定位。下面这个表格是多年调串口的人最常用的排查起点问题现象可能原因排查方式解决方案低波特率正常高波特率丢数据波特率误差过大、中断处理不及时用逻辑分析仪抓起始位和停止位计算实际波特率与标称值的误差改用误差更小的晶振调整分频配置降低波特率数据量一大就丢帧接收缓冲区不够或消费速度慢打印缓冲区深度、消费速度临时加大缓冲区观察是否改善增大环形缓冲区改用 DMA优化解析逻辑偶尔丢 1 个字节且数据整体错位中断被长时间屏蔽检查是否在临界区或 Flash 操作期间关闭了中断缩短关中断时间把耗时操作移出临界区出现溢出标志ORE硬件接收缓冲溢出读取状态寄存器确认溢出标志被置位提高取走数据的频率开启 FIFO加大 DMA 接收周期帧内容完整但顺序错乱缓冲区覆盖或 DMA 双缓冲切换错误查看帧头帧尾位置确认是否被新数据覆盖检查环形缓冲区的读写指针确认 DMA 传输完成标志上位机丢数据上位机读取不及时或驱动缓冲溢出用串口调试助手对比调整读取线程优先级采用异步读取增大串口驱动接收缓冲启用硬件流控6.1 很多人忽视的波特率误差积累丢数据不一定是缓冲区不够也可能是波特率本身就有误差。UART 通信时接收方在每个 bit 的中心位置采样如果发送方和接收方的波特率误差太大采样点就会逐渐偏移最终读到错误的电平。波特率误差的计算并不复杂。以 115200 波特率、标准 10 bit 帧为例每个 bit 的时长是 1/115200 ≈ 8.68 微秒。如果你的 MCU 时钟是 16 MHz想要产生 115200 波特率分频值是 16000000 / 115200 ≈ 138.89取整后实际波特率会偏离标称值。误差在 2% 以内通常可以工作超过 3% 就比较危险了。所以排查丢数据时不要只盯着 FIFO 看应该先用逻辑分析仪或示波器去量一下实际波形算一下波特率误差。尤其是使用内部 RC 振荡器且环境温度变化大的系统时钟漂移带来的波特率漂移可能比想象中严重得多。6.2 关于流控RTS/CTS 只有部分场景有用当数据量大到长期平均速率超过链路容量时FIFO 已经无法解决问题必须让对端暂时停下来等待。硬件流控RTS/CTS是一种常用的手段接收方缓冲区快满时拉高 RTS 信号通知发送方暂停发送缓冲区恢复后再拉低 RTS发送方继续发送。MCU 上启用硬件流控很简单一般只需要在初始化时配置UART_HWCONTROL_RTS_CTS再额外接两根信号线。但只有部分场景用得上硬件流控如果通信双方都是你开发的设备且距离较长、数据量达到持续满负荷硬件流控是可靠的选择。如果只是开发板上 MCU 和 PC 之间临时调试PC 端串口线不一定把 RTS/CTS 引出来这时候开启硬件流控反而可能卡死——因为对端根本没有连接流控引脚。更通用的做法是协议层流控在应用层定义命令让接收方在缓冲区达到高水位时发送暂停指令低水位时发送继续指令。这虽然会增加协议复杂度但完全不依赖硬件引脚适合不能改硬件的场景。7. 完整示例一个带软件 FIFO 的串口接收框架为了让你能直接对照落地我在这里整理一个虽然简化但结构完整的接收框架。它包含四个部分波特率配置、FIFO 初始化、中断写入、主循环解析。我把它们放在一起形成一个最小可用工程骨架。7.1 第一步初始化// 文件路径uart_fifo_demo.c #include ring_buffer.h #include stm32f4xx_hal.h ring_buffer_t uart_rx_rb; volatile uint8_t uart_rx_overflow_flag 0; void uart_init(void) { __HAL_RCC_USART1_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin GPIO_PIN_9 | GPIO_PIN_10; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; GPIO_InitStruct.Pull GPIO_PULLUP; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; GPIO_InitStruct.Alternate GPIO_AF7_USART1; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); 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; HAL_UART_Init(huart1); HAL_NVIC_SetPriority(USART1_IRQn, 5, 0); HAL_NVIC_EnableIRQ(USART1_IRQn); // 使能接收中断 __HAL_UART_ENABLE_IT(huart1, UART_IT_RXNE); } int main(void) { HAL_Init(); SystemClock_Config(); rbuf_init(uart_rx_rb); uart_init(); while (1) { // 见下方解析代码 uart_rx_process(); } }7.2 第二步中断写入在中断服务函数里只需要做读一个字节 写入 FIFO 统计溢出三件事严禁做任何解析和打印// 文件路径stm32f4xx_it.c或你的中断处理文件 #include ring_buffer.h extern ring_buffer_t uart_rx_rb; extern volatile uint8_t uart_rx_overflow_flag; void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_RXNE)) { uint8_t data (uint8_t)(huart1.Instance-DR 0xFF); if (!rbuf_write(uart_rx_rb, data)) { uart_rx_overflow_flag; // 记录溢出次数便于诊断 } } }7.3 第三步主循环解析主循环的职责是有数据就取取到就按帧解析没有数据时不要让循环空转可以做低优先级任务// 文件路径uart_fifo_demo.c #define FRAME_MAX_LEN 128 void uart_rx_process(void) { static uint8_t frame_buf[FRAME_MAX_LEN]; static uint16_t frame_len 0; uint8_t ch; while (rbuf_read(uart_rx_rb, ch)) { if (ch 0xAA frame_len 0) { frame_buf[frame_len] ch; // 帧头 } else if (frame_len 0 frame_len FRAME_MAX_LEN) { frame_buf[frame_len] ch; if (frame_len 4 ch 0x55 frame_buf[0] 0xAA) { // 简化的帧尾判断这里应该在协议里定义长度字段 process_frame(frame_buf, frame_len); frame_len 0; } } else { frame_len 0; // 异常状态重新等待帧头 } } // 如果没有数据可以在这里做其他低优先级任务 }7.4 如何验证这个框架是否有效写完之后不要直接上业务先做一个接收压测用串口调试助手或写一个 PC 端小工具以固定间隔循环发送 0x00~0xFF。MCU 端每收到一帧或每收到 1000 字节通过另一个串口打印uart_rx_overflow_flag的当前值。如果溢出计数一直是 0说明 FIFO 深度和消费速度是足够的。如果溢出计数持续增长说明消费速度赶不上生产速度应该加大 FIFO、减少中断里的耗时操作或者改用 DMA。这种先压测后上业务的习惯可以避免很多串口通信问题被隐藏在业务逻辑里。8. 工程实践与最佳实践建议8.1 选型思路什么时候该用什么方案我建议按下面的优先级选择串口接收方案低速、低负载场景轮询或中断 软件 FIFO。这是最简单可靠的组合不需要额外硬件资源。中速、突发流量场景中断 环形缓冲区。中断只负责搬运数据缓冲区做得够大问题基本都能解决。高速、大数据量场景DMA 双缓冲。让 DMA 帮 CPU 打工CPU 只在 DMA 传输完成时才介入。跨时钟域场景如果数据从 FPGA 到 MCU或者 FPGA 内部跨时钟域必须用异步 FIFO不要用寄存器数组硬拼。8.2 关于 FIFO 深度的选择FIFO 深度不是越大越好而是要看消费方最慢能承受多久不消费。一个简单的估算方法FIFO 最小深度 最坏突发数据量 - 消费方在突发期间能处理的数据量举例来说如果你的系统每 100 毫秒会收到一次 64 字节的突发数据而解析处理程序每 10 毫秒可以处理 128 字节那么 FIFO 深度设为 64 就够了。但如果解析程序可能被 A/D 转换任务阻塞 50 毫秒那么深度必须能覆盖这 50 毫秒内到达的数据量。实际工程里我见过很多人一上来就分配 4KB 甚至 16KB 的环形缓冲区这在 PC 上位机里毫无问题但在 RAM 只有几十 KB 的单片机上就要谨慎。更合理的做法是先用小缓冲区跑通流程再通过压测确定溢出边界最后留 1.5 到 2 倍余量。8.3 中断服务函数的纪律串口通信的稳定性很大程度上取决于你是否遵守中断服务函数的设计纪律不要打印日志。printf 和 HAL_UART_Transmit 是阻塞函数放进中断会直接导致下一个字节丢失。不要做协议解析。把原始数据放进 FIFO 就行解析工作放到主循环。不要调用耗时过长的库函数。尤其避免 malloc、printf、文件操作等不确定耗时的调用。保持可重入。中断里最终写入的环形缓冲区要设计成单一生产者和单一消费者模式避免复杂锁操作。8.4 安全与异常恢复串口通信不像数据库操作那样有事务回滚但同样需要做好异常恢复策略溢出计数。在 FIFO 满时不要只是静默丢弃而是用一个计数器累计溢出次数方便后续诊断。帧失步恢复。协议里一定要有明确的帧头帧尾解析逻辑检测到非法帧头时要丢弃整帧并重新同步而不是继续向后解析出错误数据。看门狗。如果串口长时间没有收到任何数据业务侧要能判断链路是否异常必要时重新初始化串口或者提示对端重启发送。生产环境变更。特别提醒如果需要修改生产环境中的设备通信参数务必先在离线测试板上验证波特率、FIFO 深度和中断优先级设置确认没有回归问题后再批量下发更新。涉及固件升级时备份当前版本、保留回滚路径是必须做的。8.5 关于 FPGA FIFO 的几条经验如果你在 FPGA 设计中使用 FIFO这几个经验值得记住异步 FIFO 的跨时钟域安全不要只用两级寄存器同步读指针到写时钟域正确做法是使用格雷码指针并进行多级同步同时注意空满判断的保守性。IP 核会帮你做这些但如果你自己设计异步 FIFO务必搞清楚格雷码和指针同步的原理。FWFT 模式适合做数据流标准模式读取时多一拍延迟FWFT 模式数据摆在门口两种模式在时序上各有取舍选型时以接口协议的时序要求为准。注意 FIFO IP 的资源消耗小深度 FIFO 优先用分布式 RAM/寄存器实现大深度用 Block RAM。配置前先查一下目标 FPGA 的 BRAM 和 LUT 规模避免为了一个小 FIFO 浪费整个 FPGA 的大块资源。9. 总结串口 FIFO 缓存解决的不是某一个芯片的 bug而是嵌入式系统里一个普遍存在的矛盾数据到达的速率是硬件决定的、恒定甚至突发的而 CPU 处理数据的能力是软件决定的、会有波动的。FIFO 就是这两者之间的缓冲带。真正可靠的串口接收方案不是把希望全部寄托在硬件 FIFO 上也不是简单把中断服务函数写得特别短而是用硬件 FIFO 兜底 软件 FIFO 缓存 DMA 降低 CPU 负担 协议层做好校验和重传的组合拳从物理层到应用层逐级消除丢数据的可能。如果你现在正被串口丢数据困扰建议按这个顺序去检查先用逻辑分析仪确认波特率误差再确认你的串口外设有没有硬件 FIFO、深度多少然后看中断服务函数里有没有做多余的事最后把软件 FIFO 和 DMA 的可能性都试一遍。大多数丢数据问题都会在这一轮排查里水落石出。下一步可以继续深入学习环形缓冲区在 RTOS 多线程环境下的实现、DMA 双缓冲机制、以及异步 FIFO 的格雷码指针同步原理。这几个方向都属于一旦搞懂就能用到很多项目里的底层能力值得花时间彻底吃透。建议把这篇文章收藏备用下次调串口时再翻出来对照排查。