简介：这是一份面向STM32嵌入式开发者的FreeRTOS基础例程，集中演示消息队列、USART1的DMA接收与MODBUS双向通信如何配合。工程共规划六个运行任务：任务一控制三只指示灯闪烁，任务二控制两只指示灯闪烁，任务三与任务四各自采集两路DI后向MODBUS任务投递消息，任务五每秒读取SD2405时钟芯片时间并发送消息，任务六收到上位机请求后，把上述DI状态与时钟数据经串口回传。消息队列以首个字节区分请求命令、时钟数据、第一组DI、第二组DI，结构简单直观，适合对照学习任务间通信。压缩包共839个文件、约3.1MB，以C源文件与H头文件为主，另有工程配置文件、Hex烧录文件、HTML文档和PNG原理图，覆盖代码阅读、编译和烧录所需内容。已有2405人学习下载，适合初学FreeRTOS消息队列或想实现MODBUS从站的开发者直接参考。
1. 一个压缩包标题背后的完整链路：FreeRTOS+DMA+USART1+MODBUS到底怎么协作
V4-006_基础例程+FreeRTOS+DMA+USART1+消息队列+MODBUS双向通信，这个压缩包名字一眼能拆出五样东西：基础例程、FreeRTOS、DMA、USART1、消息队列，最后压一个MODBUS双向通信。很多人拿到这类工程模板的第一反应是改波特率、改寄存器地址、能通就交差，但真正把它跑起来做双向主从通信时，问题往往出在模板没写到的地方：帧边界是谁定的、DMA缓冲满了怎么办、两个任务同时碰串口会不会打架。这篇笔记按我做工业串口通信的习惯把这套模板拆开讲，先讲为什么要用DMA和消息队列这套组合，再给出能直接搬的收发代码和MODBUS解析逻辑，最后把最容易翻车的几个事故现场按现象、原因、解决写清楚。适合新手照着把工程跑通，也适合老手排查那种时好时坏、换台设备就超时的玄学问题。
2. 通信架构先立住：为什么选DMA+空闲中断，为什么消息队列不能省
这类基础例程的串口处理方式基本就两种。一种是纯中断逐字节接收，每来一个字节进一次中断，把字节塞进环形缓冲；另一种是DMA循环接收，配合串口空闲中断把一整帧数据一次性搬到内存。逐字节中断在MODBUS这种帧长不定、空闲时间长的场景下有两个麻烦：一是波特率上去之后每字节一个中断，CPU被打断的频率和收发的数据量成正比；二是帧边界要用定时器或字节间隔去猜，容易把两帧并成一帧。DMA方式则把这部分搬运工作从CPU手里拿走，寄存器配好之后，数据在内存和串口之间自己流转，CPU只在帧结束那一刻收到一个空闲中断。
这里要说明一点：DMA不是万能的。如果你的场景是一来一往应答式的单帧短报文、而且波特率不高，逐字节中断完全够用，还省一个DMA通道。选择DMA的真正理由是后台有别的任务要跑，FreeRTOS在这个例程里恰恰就是那个别的任务。有了任务调度，CPU就不能在串口中断里待太久，DMA加空闲中断的组合避免了一帧数据吃掉几百次中断，把CPU时间还给任务调度器。另外，MODBUS RTU在物理层是半双工总线，双向通信并不表示同时收发，而是指同一台设备既能作为主站发起请求、也能作为从站响应请求，这个语义后面实现时还要再强调一次。
那消息队列在这里是干什么的？它的核心职责是把中断上下文和任务上下文切开。DMA搬运完一帧，空闲中断只需要做一件事：把这一帧有多长挂到队列里，然后立刻返回。真正做MODBUS解析、CRC计算、功能码分发的任务在队列里等，等到了才被唤醒。这样做有几个实打实的好处：中断服务函数保持极短，不会因为解析逻辑拖慢下一次接收；解析任务可以被阻塞挂起，接收和解析互不占用对方的时间；如果同时有多个生产者，比如两路串口都要跑MODBUS，队列天然做了缓冲和线性化。
2.1 串口收发的两种姿势：逐字节中断和DMA+空闲中断怎么选
我先放一张对比，这是我在决定工程方案时心里过的那张表，串口收发的选择其实不需要纠结太久。
| 对比项 | 逐字节中断 | DMA + 空闲中断 |
|---|---|---|
| CPU中断次数（每帧6字节） | 6次，每字节1次 | 1次，整帧结束后1次空闲中断 |
| 帧边界判定 | 软件定时器或字节间隔估算 | 串口硬件空闲线自动判定 |
| 解析逻辑放置 | 中断里不宜放长逻辑 | 中断只入队，解析放任务 |
| 后台有RTOS任务时 | 中断频繁挤占任务时间 | 任务调度更平滑 |
| 典型失败模式 | 高波特率下丢字节、帧粘包 | 缓冲区回绕、Cache一致性问题 |
选择的时候看两个条件：后台有没有任务要跑、协议是不是不定长。两者都满足，就直接走DMA路径。MODBUS RTU帧长从4字节到254字节不等，属于典型的不定长协议，再加上FreeRTOS在跑，DMA几乎是唯一不太会翻车的选择。如果只是裸机轮询一个传感器，逐字节中断反而代码更短、更容易调试。
DMA接收有循环和非循环两种模式。非循环模式下DMA收满设定的字节数后停止，你得知道未来一帧有多长才能配缓冲大小，这不符合不定长帧的诉求。循环模式则是DMA写完缓冲区尾部后自动回绕到头部继续写，配合空闲中断来定帧，相当于缓冲区永远在接收，中断只负责告诉你哪一段是有效数据。设计上唯一的隐患是循环造成的回绕，这个后面避坑章专门说。
2.2 消息队列是任务和中断之间的缓冲带，放什么进队有讲究
消息队列在这里扮演的角色不是搬运数据，而是搬运状态。常见做法是空闲中断里只把这一帧的长度放入队列，不放入数据指针、更不拷贝整个帧。长度本身是16位整数，入队操作极快，中断服务函数不会卡顿。任务的职责是从队列里收到长度之后，再去DMA缓冲区取数据。这个设计把数据所有权明确分开了：DMA缓冲区属于接收外设，解析任务只在拿到长度、确认数据完整后访问它。
为什么不直接把数据拷进队列？因为MODBUS帧最长可达254字节，队列节点大小要按最大帧开内存，而且拷贝时间在中断里不可控。把长度入队是更常见、也更稳的工程做法。代价是任务取出长度后必须尽快处理，否则DMA循环模式可能会覆盖掉这帧数据。因此队列深度至少要覆盖解析任务最坏阻塞时长内可能到达的帧数，一般开4到8个节点就够了。
还要强调一个区别：全局变量也能传递长度，但队列天然支持阻塞等待、多生产者写入和超时控制。全局变量加标志位在裸机里没问题，放到FreeRTOS里，解析任务就得忙轮询或者用信号量打底，写出来的代码反而更绕。队列是这套FreeRTOS例程里的标准答案，不是花架子。
2.3 任务划分和优先级设定：接收、解析、发送三块怎么安排
我一般建议至少拆成两个任务：一个负责接收和解析，一个负责发送管理。接收解析任务从rx队列里等帧长度，拿到后拷贝数据、做CRC、按功能码分发、生成应答，再把应答帧丢进tx队列。发送任务从tx队列里取整帧，组织成MODBUS RTU报文，最后用DMA发送出去。两个任务加两个队列，逻辑干净，调试时责任分明。
任务优先级的设定有一点讲究。串口空闲中断属于快速事件，但它只做入队，所以中断优先级高一点没关系。关键是解析任务优先级不要设得过高，避免它长时间占用CPU，导致DMA接收侧没有机会被消费或者发送任务饿死。推荐接收解析任务设中等优先级，发送任务略低，任何涉及延时的任务，比如模拟MODBUS帧间间隔，用vTaskDelay而不是忙等待。这样一旦发送卡住，高优先级的接收解析任务还能保持通信正常。
如果你想让系统吞吐更高，可以把接收任务再拆成收帧任务和协议解析任务，前者只做DMA缓冲区的拷贝和入队，后者只做MODBUS逻辑。基础例程用两个任务就够了，拆多了反而增加队列同步成本。优先级表我习惯这样定：
| 任务 | 优先级 | 说明 |
|---|---|---|
| 接收解析任务 | 中 | 从rx队列取长度，解析MODBUS帧并生成应答 |
| 发送任务 | 中低 | 从tx队列取帧，组CRC并启动DMA发送 |
| 空闲/后台任务 | 低 | 不参与通信，留给业务逻辑 |
3. 把MODBUS双向通信跑起来：组帧、解析与DMA收发实现
这一章给的是能直接落到工程里的代码骨架。代码风格以标准外设库API为例，用HAL库的思路是等价的，重点是逻辑和参数，不是某个外设库的函数名。我会按接收侧、解析侧、发送侧三块讲，每块带一个代码块并解释参数怎么调。
3.1 DMA循环接收与空闲中断定帧：最小实现代码
接收侧的目标是：DMA自动把USART1收到的字节搬进缓冲区，空闲中断在帧结束时触发，中断里只做一件事——把这一次收到的长度放入队列。
/* USART1 + DMA 循环接收的最小实现 */ #define RX_BUF_SIZE 512 /* 接收缓冲区，必须大于MODBUS最长大帧 */ static uint8_t dma_rx_buf[RX_BUF_SIZE]; static uint16_t dma_rx_len; /* 本次空闲中断计算出的有效字节数 */ QueueHandle_t xModbusRxQueue; /* 接收消息队列，入队内容是帧长度 */ void USART1_DMA_Init(void) { /* 省略GPIO、波特率、串口基础配置 */ /* 关键配置是这个DMA通道：循环模式、外设到内存 */ DMA_InitTypeDef dma_init; dma_init.DMA_Direction = DMA_DIR_PeripheralSRC; /* 外设(串口) -> 内存 */ dma_init.DMA_BufferSize = RX_BUF_SIZE; dma_init.DMA_Mode = DMA_Mode_Circular; /* 循环模式，满了回绕 */ dma_init.DMA_PeripheralInc = DMA_PInc_Disable; /* 外设地址不递增 */ dma_init.DMA_MemoryInc = DMA_MInc_Enable; /* 内存地址递增 */ DMA_Init(DMA1_Channel5, &dma_init); /* 使能空闲中断，这就是定帧的关键 */ USART_ITConfig(USART1, USART_IT_IDLE, ENABLE); /* 接收队列建4个深度，足够缓存解析任务处理期间的待处理帧 */ xModbusRxQueue = xQueueCreate(4, sizeof(uint16_t)); } void USART1_IRQHandler(void) { BaseType_t xHigherPriorityTaskWoken = pdFALSE; if (USART_GetITStatus(USART1, USART_IT_IDLE) != RESET) { /* 先读数据寄存器清掉空闲标志，顺序不能反 */ USART_ReceiveData(USART1); USART_ClearITPendingBit(USART1, USART_IT_IDLE); /* 计算DMA当前已写入的字节数：缓冲大小 - 剩余计数器 */ uint16_t remaining = DMA_GetCurrDataCounter(DMA1_Channel5); dma_rx_len = RX_BUF_SIZE - remaining; if (dma_rx_len > 0) { /* 只把长度入队，不在中断里碰数据，保持中断极短 */ xQueueSendFromISR(xModbusRxQueue, &dma_rx_len, &xHigherPriorityTaskWoken); } /* 循环模式下DMA自动回绕，这里不需要重新启动DMA */ } portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }这段代码的核心逻辑是DMA循环搬运、空闲中断定帧。dma_rx_len的计算方式用的是缓冲区总大小减去DMA硬件剩余的计数器值，得到的是从上次空闲中断以来新写进来的字节数。这个数就是本次一帧的长度，但也可能因为帧间隔过低而包含两帧，避坑章会专门处理。
两个参数需要重点说明。RX_BUF_SIZE设512字节是给MODBUS最长大帧254字节留出两倍余量，目的是降低回绕导致帧被拆到缓冲区首尾两端的概率，设成256会频繁踩边界。队列深度4表示最多挂起4帧未处理，如果你的主站轮询周期很短、解析任务还做了其他耗时操作，就把深度加到8或者16，代价只是几个队列节点的RAM。
注意空闲标志的清除顺序：先读一次数据寄存器，再清空闲中断标志位。很多初学者只清标志不读数据寄存器，导致第二次空闲中断永远不触发。这个细节属于标准外设库的老坑，HAL库里用法略有差异，但思路一样——必须让硬件看到数据寄存器已经被读走。
3.2 MODBUS RTU帧解析任务：CRC校验、地址过滤和功能码分发
解析任务在队列里等长度，拿到长度后从DMA缓冲区拷贝整帧，然后走校验、过滤、分发三步。
/* MODBUS RTU帧：[地址1字节][功能码1字节][数据N字节][CRC低字节][CRC高字节] */ #define MODBUS_BUF_MAX 256 #define MODBUS_FC_READ 0x03 /* 读保持寄存器 */ #define MODBUS_FC_WRITE 0x06 /* 写单个寄存器 */ #define MODBUS_ADDR_SELF 0x01 /* 本机从站地址，主站模式下填0表示不过滤 */ typedef struct { uint8_t addr; uint8_t func; uint8_t data[MODBUS_BUF_MAX]; uint16_t len; /* data有效长度 */ } modbus_frame_t; QueueHandle_t xModbusTxQueue; /* 发送队列，给发送任务用 */ void vModbusRxTask(void *pvParameters) { uint16_t rx_len; uint8_t frm[MODBUS_BUF_MAX]; for (;;) { /* 阻塞等待DMA空闲中断丢进来的帧长度 */ if (xQueueReceive(xModbusRxQueue, &rx_len, portMAX_DELAY) == pdPASS) { if (rx_len < 4 || rx_len > MODBUS_BUF_MAX) continue; /* 最短合法帧4字节，太短是噪声 */ /* 从DMA缓冲区拷贝到局部数组，避免缓冲区被后续帧覆盖 */ memcpy(frm, dma_rx_buf, rx_len); /* 校验CRC16：覆盖地址+功能码+数据区，不含CRC本身 */ uint16_t crc_calc = Modbus_CRC16(frm, rx_len - 2); uint16_t crc_recv = (uint16_t)frm[rx_len - 1] << 8 | frm[rx_len - 2]; if (crc_calc != crc_recv) continue; /* CRC不对，直接丢帧 */ /* 从站模式按地址过滤，主站模式把本机地址配成0xFF绕过过滤 */ if (MODBUS_ADDR_SELF != 0xFF && frm[0] != MODBUS_ADDR_SELF) continue; /* 按功能码分发到处理函数 */ switch (frm[1]) { case MODBUS_FC_READ: Modbus_HandleRead(frm, rx_len); break; case MODBUS_FC_WRITE: Modbus_HandleWrite(frm, rx_len); break; default: /* 不支持的功能码，按协议回异常帧 */ Modbus_SendException(frm[0], frm[1], 0x01); break; } } } } uint16_t Modbus_CRC16(uint8_t *buf, uint16_t len) { uint16_t crc = 0xFFFF; for (uint16_t i = 0; i < len; i++) { crc ^= buf[i]; for (uint8_t bit = 0; bit < 8; bit++) { if (crc & 1) crc = (crc >> 1) ^ 0xA001; else crc >>= 1; } } return crc; }解析任务里做了两件很容易被忽略的事。第一，校验前把数据从DMA缓冲区拷贝到局部数组frm。DMA循环模式在空闲中断之后会继续接收总线上的字节，虽然当前帧已经完整，但解析任务如果做CRC和功能码处理时被更高优先级任务打断，新帧可能把缓冲区覆盖，局部拷贝能彻底隔离这种风险。第二，CRC比较时候注意字节序，MODBUS RTU的CRC在帧里是低字节在前、高字节在后，所以组装crc_recv时，frm[rx_len-1]是高字节左移8位再与低字节相或。
CRC函数本身用位循环方式实现，优点是代码短、内存占用小，缺点是逐位计算速度一般。如果你的主站轮询频率很高，就把这个函数换成查表法，用const关键字预置256项CRC表，计算速度能快好几倍。注意CRC表要定义在函数外面作为全局常量，不要在函数内部每次重建，否则算一次建一次表，性能很难看。
地址过滤这行有个设计点：从站模式下，MODBUS_ADDR_SELF配成设备自己的从站地址，收到的帧地址不匹配就丢弃；主站模式下，把这个宏配成0xFF，表示不做地址过滤，因为主站收到的应答帧地址是不同从站发出的。基础例程一般把地址写死在宏定义里，你要是做可配置设备，就把它改成全局变量，支持运行时修改。
3.3 双向通信怎么设计：主站轮询和从站应答并发不互锁
MODBUS双向通信里最容易理解偏的地方是双向这个词。物理总线是半双工的，双向指的是设备既可能作为从站被动响应，也可能作为主站主动发起请求。在实际工程中，这两种角色很少同时启用，更多是设备默认做从站，需要配置成主站时就切换角色。角色切换可以做一个全局状态位，主从选择用命令或配置项下发。
发送侧的任务模型是这样的：
/* 发送任务：从发送队列取帧，组CRC后通过DMA一次性发出 */ #define TX_BUF_SIZE 256 static uint8_t tx_dma_buf[TX_BUF_SIZE]; void vModbusTxTask(void *pvParameters) { modbus_frame_t frame; for (;;) { if (xQueueReceive(xModbusTxQueue, &frame, portMAX_DELAY) == pdPASS) { /* 组装RTU帧：地址 + 功能码 + 数据 */ uint16_t idx = 0; tx_dma_buf[idx++] = frame.addr; tx_dma_buf[idx++] = frame.func; memcpy(&tx_dma_buf[idx], frame.data, frame.len); idx += frame.len; /* 补上CRC16，低字节在前 */ uint16_t crc = Modbus_CRC16(tx_dma_buf, idx); tx_dma_buf[idx++] = crc & 0xFF; tx_dma_buf[idx++] = crc >> 8; /* 配置DMA发送，一次性发完整帧 */ DMA_Cmd(DMA1_Channel4, DISABLE); DMA_SetCurrDataCounter(DMA1_Channel4, idx); DMA_Cmd(DMA1_Channel4, ENABLE); /* 等待发送完成，再处理下一帧，避免两帧粘连 */ while (DMA_GetFlagStatus(DMA1_FLAG_TC4) == RESET) taskYIELD(); DMA_ClearFlag(DMA1_FLAG_TC4); } } } BaseType_t Modbus_Send(uint8_t addr, uint8_t func, uint8_t *data, uint16_t data_len) { modbus_frame_t frame; frame.addr = addr; frame.func = func; if (data_len > MODBUS_BUF_MAX) return pdFAIL; memcpy(frame.data, data, data_len); frame.len = data_len; /* 入队超时给10个tick，发送队列满就放弃这一帧 */ return xQueueSend(xModbusTxQueue, &frame, 10); }发送任务里用while加taskYIELD等DMA发送完成，是这套代码里最实用的技巧。DMA发送是一个耗时过程，115200波特率下一帧最长254字节需要约22毫秒。如果用CPU忙等，这个任务会占住CPU不放；用taskYIELD主动让出CPU，任务仍然保持阻塞在等待条件上，其他任务能正常运行。代价是这个任务在发送期间会被反复唤醒检查标志位，对MODBUS这种低速协议完全可接受。
关键参数是发送队列的深度。如果设备作为主站轮询32个从站，每个从站请求帧和应答帧都走这个队列，深度至少要覆盖一轮轮询中可能积压的帧数。建议基础工程直接开16个节点，每个节点是modbus_frame_t结构体，最大256字节数据域，RAM开销大约是4KB多一点。如果你的单片机RAM紧张，可以把结构体里的data域砍小，前提是明确自己不会用到长数据帧。
双向通信的时序核心是请求应答的一来一回。主站往tx队列放读请求，同时等待rx队列里的应答；从站从rx队列收到请求，解析后把应答放tx队列。因为收发各自有独立的DMA通道和队列，主站发送请求和从站解析应答可以同时进行，不会互相阻塞。唯一要注意的是帧间间隔必须满足MODBUS规范要求的3.5字符静默时间，发送任务在处理完一帧后不要在循环里立即处理下一帧，加一个vTaskDelay或者靠队列自然间隔控制，否则总线上会出现帧粘连。
4. 避坑手册：DMA+FreeRTOS+MODBUS组合最常见的6个事故现场
这一章写我把这套例程组合在一起调试时踩过的坑，每条按现象、原因、解决三个步骤写。这些坑单独看都不难，但组合在一起时，现象会互相掩盖，特别浪费时间，就是那种改一行代码好了、过几天又出现的玄学问题。
4.1 现象：连续两帧MODBUS粘成一段，解析直接丢弃
现象是串口助手连续发两帧读请求，设备只在第一帧时正常应答，第二帧没有反应。加调试输出发现接收任务只收到一个长度值，而且这个长度接近两帧相加。
原因在帧定界方式上。空闲中断的触发条件是串口线上出现一个字节时间的空闲，MODBUS规范要求帧间间隔是3.5个字符时间，但只要上位机发送间隔小于一个字符时间，两帧之间就不会产生空闲中断，DMA把连续字节一起搬进缓冲区，空闲中断只在最后触发一次。115200波特率下1个字符时间约87微秒，很多上位机软件发送两帧的间隔短于这个值，就会触发粘包。
解决思路有两个。第一个是严格要求上位机保证帧间延时，这在自测时管用，但在工业现场不现实，总线上的主站可能来自不同厂家的设备。第二个是在解析任务里做帧分割：拿到一段连续数据后，根据MODBUS帧长度和CRC校验结果尝试切帧，切出一帧处理后，检查剩余长度是否还足够组成下一帧，如果够就继续处理。这个逻辑相当于把空闲中断定帧变成了数据和CRC双重定帧，能有效消化粘包。还有一种更彻底的做法是改用定时器接收超时判帧，每收一个字节重置硬件定时器，超过3.5字符时间没有新字节就产生中断，这需要额外占用一个定时器，我在最后一章再展开。
4.2 现象：一帧数据被拆到缓冲区首尾，CRC全部算错
现象是设备偶尔收不到某条命令，或者CRC校验总是失败，但用串口助手抓波形发现数据明明是对的。再查DMA缓冲区内容，发现这一帧的前半段在缓冲区尾部、后半段在缓冲区头部，memcpy出来的frm数组是乱的。
原因是DMA循环模式写满缓冲区后回绕到头部继续写，而这一帧恰好跨越了回绕点，被物理上拆成两段存下来。空闲中断触发时，dma_rx_len计算的是从上次中断到现在的全部字节数，这个长度数值正确，但缓冲区里是从某个位置开始不连续的数据。
解决思路是增加一个回绕判断。每次空闲中断后，记录DMA当前写入位置，也就是remaining值，如果本次长度加上写入位置超过了缓冲区大小，说明发生了回绕，需要把缓冲区尾部和头部两段分别拷出来拼成一帧。代码上就是把一次memcpy换成两次memcpy，源地址分别是回绕前的尾段和缓冲区起始处。另一种更省事的方法是直接把缓冲区加大到MODBUS最大帧的2倍以上，回绕恰好落在帧中间的概率会显著下降，但只是降低概率，不是根治。要做完整协议栈，拼接逻辑不能省。
4.3 现象：中断里入队成功，任务却一直等不到数据
现象是调试串口打印发现xQueueSendFromISR返回值是pdPASS，但接收任务一直阻塞在xQueueReceive上，像没收到一样。或者更隐蔽的情况是，程序跑一段时间后接收停止，重新复位又正常。
原因有两个可能。第一个是portYIELD_FROM_ISR放的位置不对，或者入队后没有触发任务切换，xQueueSendFromISR只做入队动作，它不知道这个队列唤醒的任务什么时候该跑，必须由portYIELD_FROM_ISR在中断退出时触发一次调度，这个调用必须在中断服务函数末尾无条件执行，不能放在某个if分支里。第二个是队列深度直接设成1，DMA收到第二帧时队列还是满的，xQueueSendFromISR返回errQUEUE_FULL，新帧长度被丢弃，而任务还在处理上一帧。
解决方法是先扫一遍中断和队列的配置常识：确认栈上BaseType_t变量没有越界，确认portYIELD_FROM_ISR无条件执行，确认队列深度不小于最坏情况下的积压帧数。排查这类问题时，建议在xQueueSendFromISR调用点加一个计数器，把返回值打印出来看，如果频繁出现非pdPASS，优先加队列深度而不是猜中断优先级。
4.4 现象：CRC计算挪进中断后，任务全部饿死
现象是把CRC校验逻辑写在空闲中断里之后，主站轮询时偶尔丢寄存器数据，更严重时FreeRTOS的低优先级任务几乎不执行，连指示灯闪烁都变慢了。
原因是空闲中断的频率和帧率相同，如果每帧在中断里做几百字节的CRC循环计算，中断时长远超允许值，把CPU时间大量消耗在中断上下文里，任务调度器被饿着。这个坑的精妙之处在于它不会立刻死机，而是表现为性能缓慢恶化，很难定位。
解决方法是坚持一个原则：中断服务函数只做两件事，计算长度和入队。CRC循环、地址过滤、功能码分发全部挪到解析任务里。中断是黑匣子的入口，任何放进中断的逻辑都会变成排查时的盲区。如果确实要在中断里做快速判断，可以用一个标志变量，先看一下帧头地址是否匹配，不匹配就跳过入队，但CRC必须在任务里算。
4.5 现象：任务栈溢出导致HardFault，还是偶发的
现象是系统运行一段时间后突然跳HardFault，有时候是几个小时，有时候是一天，复位后又能正常跑。检查代码逻辑看不出问题，直到开启栈溢出检测钩子才发现是某个任务栈不够用。
原因是解析任务里定义了modbus_frame_t结构体或者大的局部数组，这类结构体在栈上分配，如果任务栈大小只按默认值配置，很容易超限。MODBUS_BUF_MAX是256字节，再加上函数调用链和队列操作的临时变量，栈消耗会到400字节以上。另一个是FreeRTOSConfig.h里configUSE_16_BIT_TICKS被设为1，系统tick用16位计数，超时时间超过32767个tick就溢出，导致阻塞等待立即返回，看起来像是通信超时。
解决方法是把configUSE_16_BIT_TICKS设为0，同时给解析任务单独分配栈大小，建议从512字起步，不够就往上加。在FreeRTOSConfig.h里开启configCHECK_FOR_STACK_OVERFLOW，注册栈溢出钩子函数，HardFault之前先在串口打一条日志，定位能快很多。
4.6 现象：带D-Cache的芯片上，DMA收到的数据和CPU看到的不一样
现象是在某Cortex-M7内核的芯片上跑这套代码，DMA明明已经把串口数据搬进了缓冲区，但CPU读取时还是旧数据，偶尔又是新数据，完全没规律。
原因是这类内核有D-Cache，CPU读写内存时会先走Cache，而DMA外设直接访问物理内存，两者看到的数据不一致。F1、F4这类Cortex-M3/M4内核没有D-Cache，不存在这个问题，所以移植到新平台时才容易踩中。
解决方法是把DMA收发缓冲区放到非Cache属性区域，或者在每次接收完成后调用Cache无效化操作、每次发送前调用Cache回写操作。具体API要看芯片的固件库，核心思路一致：确保CPU在读取DMA写入的数据前，先让Cache里的旧数据失效；在DMA读取CPU写好的数据前，先把Cache内容回写到物理内存。移植代码到带Cache的平台时，第一件事就是检查缓冲区内存属性，不要等跑起来再猜。
5. 验收这套双向通信：回环测试、波形检查和进阶轮询
先别急着把设备挂到真实总线上，有一套稳定的自测流程能省下大量调试时间。第一步是裸机验证链路。所谓裸机验证，就是在不启用FreeRTOS的调度器、只开中断的情况下，让DMA循环接收和空闲中断先跑起来，用串口助手手动发一帧MODBUS请求，看缓冲区里能不能收到完整数据。这一步验证的是DMA配置、中断标志清除和长度计算这三个最容易出错的地方。等裸机链路稳定了，再挂上FreeRTOS和解析任务，把问题范围缩小到任务调度层面。我见过太多人三件事一起调，出问题时不知道是队列还是DMA的问题，其实把链路拆开验证，每一步都有明确的判断标准。
回环测试用标准MODBUS读请求帧最方便：发01 03 00 00 00 02 C4 0B，这表示读从站1、从起始寄存器0开始读2个保持寄存器。设备正确应答的帧格式是01 03 04加4个字节寄存器数据加2字节CRC，只要串口助手里能看到这个应答模式，证明从站接收解析、DMA发送、CRC计算全链路是通的。这时再切换主站模式，让设备定时轮询串口助手里模拟的从站，确认请求帧的CRC和格式正确。最后用逻辑分析仪抓一次TXD/RXD波形，检查帧与帧之间的间隔是否满足MODBUS规范的3.5字符时间。
进阶方向里最实用的是主站多从站轮询加超时重连。做法是把主站任务做成一个周期循环，每隔固定间隔发送一个从站的请求帧，然后带着超时等待应答。xQueueReceive的超时参数就是天然的重传计时器，超时后把失败计数加一，连续失败三次就标记这个从站掉线，继续轮询下一个地址，不掉线的不阻塞整条总线。这里有个参数经验：主站轮询超时时间设500毫秒比较合适，太短容易误判，太长会拖慢整轮轮询。发送队列深度记得按从站数量扩容。
我做这套东西时最大的教训，就是一开始没把帧定界当回事，总想着先让数据跑起来再说，结果粘包和回绕两个坑反复交替出现，改一处好了另一处又冒出来。后来改成先确认DMA缓冲区内容再写解析逻辑，每个环节都先用串口助手把原始数据打印出来核对一遍，问题反而好定位得多。如果你现在也在调这套FreeRTOS加DMA加MODBUS的组合，先把裸机回环跑通，再看队列和任务优先级，最后再碰帧边界优化，希望帮到你。
本文还有配套的精品资源，点击获取
