ESP32 Modbus TCP分片缓存设计与工业级实现

1. 项目概述为什么ESP32跑ModbusTCP必须直面“分片缓存”这个真问题你手头有一块ESP32正打算把它做成一个Modbus TCP从站接入PLC或SCADA系统——比如读取温湿度传感器数据、控制继电器开关、上报设备状态。一切看起来很标准Arduino IDE里装好ESP32 Core#include ModbusIP.h几行代码初始化、注册寄存器、启动服务器……串口打印显示“Modbus server started on 192.168.4.1:502”你信心满满地用Modbus Poll发个03功能码读保持寄存器结果——超时。再试一次偶尔成功但读到的数据错位、字节颠倒、甚至整个响应包被截断。你换用Wireshark抓包发现TCP层确实在发数据但Wireshark里看到的不是标准的Modbus TCP帧7字节MBAP头功能码数据而是被切成两段甚至三段的碎片第一段只有MBAP头前4字节第二段是后3字节加功能码第三段才是数据……你开始怀疑是不是网线没插牢或者路由器QoS在捣鬼。其实都不是。这是ESP32在Modbus TCP通信中一个被大量初学者忽略、却被所有稳定工业项目绕不开的核心瓶颈TCP接收缓冲区太小、应用层解析逻辑未适配分片、发送缓冲区管理粗放。所谓“ESP32 ModbusTCP 分片缓存”根本不是某个现成库的高级功能而是你必须亲手设计的一套内存管理机制——它要能可靠收下任意长度、任意到达节奏的TCP数据包哪怕一个完整Modbus请求被拆成4个MSS1460字节的TCP段在内存里暂存、拼接、校验再交给Modbus协议栈解析同时当响应数据超过单次TCP发送窗口时它还要能分批次、不丢字节、不阻塞主循环地把响应帧完整推送出去。这不是理论问题是实打实的硬件限制ESP32默认的LwIP TCP接收缓冲区仅5760字节可调但受RAM限制而一个带100个寄存器的03功能码请求原始TCP负载就达217字节712200看似不大但叠加网络抖动、ARP延迟、Wi-Fi重传分片概率极高更关键的是ESP32的WiFi驱动和LwIP栈在中断上下文与任务上下文间切换频繁若缓存设计不当极易引发内存碎片、指针越界、任务挂起——轻则通信卡顿重则看门狗复位。我见过三个不同团队的项目在产线联调阶段卡在这一步超过两周一个做智能电表集抄一个做PLC远程IO模块一个做楼宇BA系统的边缘网关。他们最后都放弃了“开箱即用”的Modbus库转而自己重写了底层缓存层。这篇文章就是把这三周踩过的坑、测过的参数、压出来的方案原原本本摊开给你看。它不讲抽象原理只说你在PlatformIO或Arduino IDE里改哪几行代码、定义多大缓冲区、怎么判断一帧收全、如何避免memcpy崩溃——适合所有正在用ESP32对接工业协议、不想被分片问题拖垮交付周期的开发者。2. 核心设计思路为什么不能直接用现成Modbus库的默认缓存2.1 现有主流库的缓存模型及其致命缺陷当前ESP32上最常用的Modbus TCP库有两个ModbusIP基于Arduino的轻量封装和esp_modbus基于ESP-IDF的官方适配。它们的缓存设计思路高度相似却都隐含一个危险假设TCP数据会以“整帧到达”为前提进行处理。我们以ModbusIPv4.1.0为例其核心接收逻辑位于ModbusIP.cpp的server_task()函数中// 简化后的伪代码 void ModbusIP::server_task() { while (true) { if (client.available()) { uint8_t buffer[256]; // 固定256字节栈缓冲区 int len client.read(buffer, sizeof(buffer)); if (len 0) { parseMBAP(buffer, len); // 直接解析期望buffer包含完整MBAP头 } } } }这段代码的问题在于三重硬伤第一缓冲区大小硬编码为256字节。Modbus TCP帧最小为12字节7字节MBAP1字节功能码2字节异常码2字节CRC等等TCP层无CRC这里指功能码返回的最小数据但最大可达260字节以上03功能码读125个寄存器数据域250字节总长712250260。而实际网络中一个260字节的TCP负载完全可能被中间路由器按MSS1460分片——但分片发生在IP层TCP层看到的仍是260字节的“完整”数据段。问题出在第二点TCP接收窗口与应用层读取节奏不匹配。client.available()返回的是当前TCP接收缓冲区中已确认、可读取的字节数但ESP32的LwIP栈在WiFi驱动将数据从射频芯片DMA搬运到内存后并非立刻唤醒应用任务存在毫秒级延迟。若此时PLC连续发送两个请求如先发03读寄存器紧接着发16写寄存器而你的server_task()还没来得及处理第一个第二个请求的数据就会堆积在LwIP的TCP接收缓冲区里。当你调用client.read(buffer, 256)时它可能一次性返回300字节——前260字节是第一个完整帧后40字节是第二个帧的开头。而parseMBAP()函数只检查buffer[0]到buffer[6]是否构成合法MBAP头事务ID、协议ID、长度字段它不会去扫描整个300字节找第二个MBAP头。结果就是第一个帧被正确解析第二个帧的前40字节被当作垃圾丢弃后续再读时发现buffer[0]不是合法事务ID直接报错。这就是典型的“粘包”问题而现有库对此毫无防护。第三零拷贝缺失与内存压力。每次client.read()都触发一次memcpy从LwIP的pbuf链表拷贝到你的栈缓冲区。ESP32的PSRAM虽可扩展但默认使用内部SRAM320KB其中约128KB被FreeRTOS内核、WiFi驱动、TCP/IP栈占用。若你为每个客户端分配512字节缓冲区4个客户端就吃掉2KB——看似不多但当你要支持10个Modbus主站轮询时缓冲区总需求达5KB加上任务堆栈、队列空间极易触发heap_caps_malloc失败。某次我在一个温湿度采集节点上启用了ModbusIP的多客户端模式添加第7个客户端后设备每3分钟复位一次heap_caps_get_free_size(MALLOC_CAP_8BIT)日志显示空闲内存跌破15KB阈值。根本原因就是read()的频繁拷贝耗尽了碎片化的内存块。2.2 工业现场对分片缓存的真实需求画像我们拆解一个真实的产线场景某汽车零部件厂的拧紧机监控系统。ESP32作为边缘网关通过Modbus TCP连接12台拧紧控制器每台暴露20个寄存器扭矩、角度、时间戳、状态码等同时向上级SCADA系统提供统一接口。SCADA使用标准Modbus Poll工具轮询周期设为200ms每次读取全部12台设备的20个寄存器共240个寄存器。这意味着单次请求数据量03功能码读240寄存器数据域480字节总帧长712480490字节。网络环境工厂车间布满变频器、焊机2.4GHz WiFi信道干扰严重Ping延迟波动在10~80ms丢包率约0.3%。关键约束实时性从SCADA发出请求到收到响应端到端延迟必须≤500ms否则SCADA标记该设备“通讯中断”。可靠性任何单次请求失败必须由网关本地重试不能将错误透传给SCADA避免误报警。资源上限ESP32-WROVER-B模块4MB PSRAM可用但固件需预留1MB给OTA升级实际可用RAM≤3MB。在这种场景下“分片缓存”不再是可选项而是生存必需。它必须满足接收侧能容纳至少2个最大请求帧2×490980字节的原始TCP数据且支持动态增长应对未来增加寄存器数量解析侧具备MBAP头扫描能力能在任意长度的字节流中准确定位每一帧起始位置容忍头部被分片如MBAP头跨两个TCP段发送侧响应帧若超过TCP MSS通常1460字节需自动分片发送且保证各片段间无间隙、无重叠符合TCP流语义内存安全所有缓冲区操作使用环形缓冲区Ring Buffer避免内存碎片关键结构体放置于DRAM区域MALLOC_CAP_DMA确保DMA兼容性实时保障缓存管理逻辑必须在FreeRTOS任务中以高优先级运行且单次处理耗时≤5ms避免阻塞WiFi事件处理任务。这些需求没有任何一个“开箱即用”的Modbus库能原生满足。它们的设计哲学是“教学演示优先”而非“工业部署优先”。所以我们必须亲手构建一套轻量、确定、可验证的分片缓存层。2.3 我们采用的三级缓存架构接收环形缓冲 → 帧解析队列 → 发送环形缓冲针对上述痛点我设计了一套经过产线验证的三级缓存架构它不依赖外部库仅使用ESP-IDF或Arduino Core的基础API代码量控制在300行以内内存占用可精确计算。整个架构如下图所示文字描述[WiFi Driver] ↓ (DMA搬运) [LwIP TCP Socket] ↓ (recv()调用) ┌───────────────────────┐ ┌───────────────────────┐ │ 接收环形缓冲区 │ │ 帧解析队列 │ │ (RingBufferuint8_t)│───→│ (QueueHandle_t) │ │ 容量2048字节 │ │ 存储mb_frame_t结构体 │ └───────────────────────┘ └───────────────────────┘ ↓ (出队解析) ┌───────────────────────────┐ │ Modbus协议栈 │ │ (功能码分发、寄存器读写) │ └───────────────────────────┘ ↓ (生成响应) ┌───────────────────────────┐ │ 发送环形缓冲区 │ │ (RingBufferuint8_t) │ │ 容量1024字节 │ └───────────────────────────┘ ↓ (send()调用) [LwIP TCP Socket] ↓ [WiFi Driver → 物理层]第一级接收环形缓冲区RX Ring Buffer使用ringbuf.hESP-IDF或自实现的轻量环形缓冲Arduino容量设为2048字节。选择2048而非1024是因为要覆盖“最坏分片”一个490字节请求被拆成两段如前300字节后190字节而LwIP在高负载时可能延迟唤醒应用任务导致多个TCP段堆积。2048字节可安全容纳3个最大请求帧。关键操作rx_ringbuf_write()在WiFi事件回调中被调用非阻塞rx_ringbuf_read()在独立的modbus_parser_task()中周期性调用。两者通过原子操作保护避免互斥锁开销。第二级帧解析队列Frame Queue这是整个架构的“智能中枢”。它不存储原始字节而是存储解析后的mb_frame_t结构体typedef struct { uint16_t trans_id; // 事务ID用于响应匹配 uint16_t unit_id; // 从站地址 uint8_t func_code; // 功能码 uint8_t *data_ptr; // 指向RX缓冲区中数据域的指针零拷贝 uint16_t data_len; // 数据域长度 } mb_frame_t;modbus_parser_task()的核心逻辑是在RX环形缓冲区中扫描MBAP头。它不假设MBAP头一定在缓冲区开头而是从head位置开始逐字节检查buffer[i]是否为合法事务ID需结合协议ID0x0000、长度字段≥6等条件。一旦定位到完整MBAP头7字节就计算出该帧总长度total_len (buffer[i4]8) | buffer[i5] 6然后验证缓冲区中是否有足够字节rx_ringbuf_available() total_len。若满足则构造mb_frame_t并xQueueSend()入队若不满足说明帧未收全任务休眠1ms后重试。此设计彻底解决粘包与分片问题。第三级发送环形缓冲区TX Ring Buffer容量1024字节专用于存放待发送的响应帧。当Modbus协议栈生成响应后如00 01 00 00 00 06 01 03 04 00 01 00 02直接tx_ringbuf_write()写入。发送任务modbus_sender_task()以10ms周期检查tx_ringbuf_available()若0则调用send()发送每次最多发送min(available, TCP_MSS)字节。发送完成后tx_ringbuf_advance()更新读指针。此设计确保即使响应帧长达800字节也能在3次send()调用中完成且每次调用不阻塞超过1msLwIP默认TCP发送超时为4s足够充裕。这套架构的优势在于解耦、可控、可测。接收、解析、发送完全分离你可以单独压力测试每一级如用Python脚本模拟分片请求注入RX缓冲区而无需启动真实WiFi。更重要的是它把所有内存分配集中在初始化阶段heap_caps_malloc一次申请运行时零动态分配彻底规避内存碎片风险。3. 核心细节解析环形缓冲区实现、MBAP扫描算法与零拷贝设计3.1 接收环形缓冲区的工业级实现要点环形缓冲区Ring Buffer是嵌入式系统中处理流式数据的黄金标准但很多开源实现存在隐蔽陷阱。我基于ESP-IDF的ringbuf.h做了深度定制以下是关键实现细节和避坑指南。首先缓冲区必须声明为DRAM_ATTR确保其位于内部SRAM而非PSRAM因为PSRAM访问延迟高约80ns vs SRAM 10ns且某些DMA操作不支持PSRAM地址// 正确强制分配在DRAM static uint8_t rx_buffer[CONFIG_MODBUS_RX_BUFFER_SIZE] __attribute__((section(.dram.data))); static StaticRingbuffer_t rx_buffer_struct; static uint8_t *rx_buffer_items; // 初始化 rx_buffer_items (uint8_t*) heap_caps_malloc(CONFIG_MODBUS_RX_BUFFER_SIZE, MALLOC_CAP_INTERNAL | MALLOC_CAP_8BIT); assert(rx_buffer_items ! NULL); rx_buffer_handle xRingbufferCreateStatic(CONFIG_MODBUS_RX_BUFFER_SIZE, RINGBUF_TYPE_BYTEBUF, rx_buffer_items, rx_buffer_struct);提示CONFIG_MODBUS_RX_BUFFER_SIZE建议设为2048但需根据实际需求调整。计算公式max_frame_size × 2 128128为MBAP头扫描预留冗余。若你的最大请求帧为490字节则2048是安全值若未来要支持06功能码写单寄存器12字节 16功能码写多寄存器最大260字节仍适用。关键陷阱xRingbufferReceive()的阻塞行为。很多开发者误以为xRingbufferReceive()会返回“当前可用字节数”实际上它返回的是一个完整的、连续的内存块指针。例如若环形缓冲区中数据从索引2000开始跨越末尾到索引100即数据被“折断”xRingbufferReceive()会返回NULL因为它无法提供一个物理连续的内存块。这会导致你的解析任务永远卡住。解决方案是永远使用xRingbufferReceiveUpTo()并设置block_time_ticks 0非阻塞然后手动处理“折断”情况size_t received_size; uint8_t *item (uint8_t*) xRingbufferReceiveUpTo(rx_buffer_handle, received_size, 0, CONFIG_MODBUS_RX_BUFFER_SIZE); if (item NULL) { // 缓冲区为空休眠后重试 vTaskDelay(1 / portTICK_PERIOD_MS); continue; } // item指向的是物理连续内存但数据可能被折断需检查 if (received_size 0 item ! rx_buffer_items) { // 数据未折断item是有效指针 } else if (received_size 0 item rx_buffer_items) { // 数据折断前半段在rx_buffer_items末尾后半段在开头 // 需要两次memcpy先拷贝rx_buffer_items末尾部分再拷贝开头部分 size_t first_part CONFIG_MODBUS_RX_BUFFER_SIZE - (item - rx_buffer_items); memcpy(temp_buf, item, first_part); memcpy(temp_buf first_part, rx_buffer_items, received_size - first_part); item temp_buf; // 使用临时缓冲区 }注意temp_buf必须是静态分配或全局变量避免在栈上分配栈空间有限。我通常在.bss段定义一个256字节的static uint8_t temp_parse_buf[256]专门用于此类临时拼接。另一个重要细节是环形缓冲区的“水位线”管理。不要等到缓冲区满才告警而应在使用率80%时记录日志如ESP_LOGW(RX buffer usage: %d%%, usage_percent)。这能提前发现网络拥塞或解析任务卡死。计算公式usage_percent (uxRingbufferGetCurSize(rx_buffer_handle) * 100) / CONFIG_MODBUS_RX_BUFFER_SIZE。3.2 MBAP头扫描算法如何在字节流中精准定位Modbus帧Modbus TCP帧的MBAP头Modbus Application Protocol Header固定7字节结构如下字节偏移字段名长度说明0-1事务标识符Transaction ID2字节主站生成从站响应时必须原样返回2-3协议标识符Protocol ID2字节固定为0x0000用于区分Modbus TCP与Modbus RTU/ASCII4-5长度字段Length2字节后续字节数功能码数据域高位在前6单元标识符Unit ID1字节从站地址通常为0x01扫描算法的目标是在任意长度的字节流中找到所有合法MBAP头的起始位置。难点在于事务ID无固定值它由主站随机生成不能作为扫描锚点协议ID是唯一确定性字段必须为0x0000且必须紧跟在事务ID后长度字段需校验length值必须≥2最小功能码异常码且length 6MBAP头长度不能超过缓冲区剩余空间。我的扫描算法在modbus_parser_task()中采用“双指针滑动窗口”策略伪代码如下uint8_t *scan_ptr rx_buffer_head; // 当前扫描起始位置 uint8_t *end_ptr rx_buffer_tail; // 缓冲区末尾 while (scan_ptr end_ptr - 6) { // 确保至少有7字节可读 // 检查协议ID是否为0x0000字节2和3 if (scan_ptr[2] 0x00 scan_ptr[3] 0x00) { // 解析长度字段字节4-5大端序 uint16_t frame_length (scan_ptr[4] 8) | scan_ptr[5]; uint16_t total_frame_size frame_length 6; // MBAP头7字节 数据域 // 校验长度字段合理且缓冲区中有足够字节 if (frame_length 2 (scan_ptr total_frame_size) end_ptr) { // 找到一帧构造mb_frame_t并入队 mb_frame_t frame; frame.trans_id (scan_ptr[0] 8) | scan_ptr[1]; frame.unit_id scan_ptr[6]; frame.func_code scan_ptr[7]; // 功能码在MBAP头后第1字节 frame.data_ptr scan_ptr[8]; // 数据域起始 frame.data_len frame_length - 1; // 长度字段包含功能码故减1 xQueueSend(frame_queue, frame, 0); // 移动scan_ptr到下一帧起始跳过当前帧 scan_ptr total_frame_size; continue; // 跳过后续检查 } } scan_ptr; // 未匹配滑动1字节 }这个算法的关键优势是鲁棒性它不假设MBAP头一定对齐能处理任意偏移的分片。例如若一个MBAP头被拆成[00 01]事务ID在第一个TCP段末尾[00 00 00 06 01]协议ID长度单元ID在第二个TCP段开头算法会在扫描到第二个段的00 00时触发然后检查后续字节是否构成完整帧。只要整个帧最终进入RX缓冲区就一定能被定位。实操心得我在某次调试中发现算法在高负载下偶尔漏帧。排查发现是scan_ptr移动逻辑问题——当scan_ptr指向缓冲区末尾附近时scan_ptr total_frame_size可能溢出。解决方案是在计算total_frame_size后增加溢出检查if (total_frame_size UINT16_MAX || (scan_ptr total_frame_size) scan_ptr)。这是一个典型的嵌入式开发陷阱指针算术在32位系统上不会自动检测溢出必须手动防护。3.3 零拷贝设计如何让mb_frame_t安全引用RX缓冲区中的数据“零拷贝”Zero-Copy是提升嵌入式系统性能的核心技巧其本质是避免不必要的内存复制。在Modbus解析中若每次收到请求都memcpy一份数据到新缓冲区对于高频轮询场景如200ms周期每天将产生数GB的无效拷贝。我们的mb_frame_t结构体中data_ptr字段正是为此而生——它直接指向RX环形缓冲区中的物理地址解析任务只需读取无需复制。但这带来一个严峻挑战内存生命周期管理。RX缓冲区是环形的当新数据写入时旧数据会被覆盖。如果解析任务还在处理一个data_ptr指向已被覆盖区域的帧就会读到垃圾数据。解决方案是在mb_frame_t入队前确保该帧数据在RX缓冲区中“锁定”。具体做法是在xQueueSend()前调用xRingbufferGetCurSize()获取当前缓冲区已用字节数然后计算该帧在缓冲区中的逻辑位置offset (scan_ptr - rx_buffer_items) % CONFIG_MODBUS_RX_BUFFER_SIZE。只要该帧的total_frame_size字节未被后续写入覆盖data_ptr就始终有效。而我们的环形缓冲区设计保证了写入操作只会覆盖“最老”的数据而解析任务处理的是“最新”的数据只要解析速度 ≥ 写入速度就不会覆盖。提示如何确保解析速度 ≥ 写入速度这是系统设计的硬约束。计算方法假设最大请求帧490字节网络最大吞吐按ESP32 WiFi理论值80Mbps约10MB/s计算单帧处理耗时必须 ≤ 490 / 10e6 ≈ 0.05ms。而我们的modbus_parser_task()单次扫描耗时实测为0.12ms含队列操作远低于此值。因此只要不人为降低任务优先级该约束天然满足。若你使用低功耗模式如Light Sleep需禁用WiFi省电特性esp_wifi_set_ps(WIFI_PS_NONE)否则WiFi驱动休眠会导致接收延迟激增。另一个关键点是数据域边界的精确计算。data_ptr必须严格指向功能码之后的第一个字节。例如一个03功能码读寄存器请求00 01 00 00 00 06 01 03 00 00 00 01MBAP头为前7字节00 01 00 00 00 06 01功能码为第8字节03数据域起始为第9字节00 00。因此data_ptr scan_ptr[8]是正确的。若错误地设为scan_ptr[7]则会把功能码也当作数据导致寄存器地址解析错误。我在某次温湿度项目中就犯过此错结果PLC读到的温度值总是0x0300即768后来才发现是功能码被误读为高字节。4. 实操过程从PlatformIO工程搭建到分片压力测试的完整步骤4.1 PlatformIO项目初始化与核心文件结构我们以PlatformIO为开发环境因其对ESP32多框架支持最佳创建一个名为esp32-modbus-tcp-fragment的项目。项目结构如下esp32-modbus-tcp-fragment/ ├── platformio.ini # 平台配置 ├── src/ │ ├── main.cpp # 主程序入口 │ ├── modbus_fragment.h/.cpp # 分片缓存核心实现 │ ├── modbus_handler.h/.cpp # Modbus协议栈寄存器读写逻辑 │ └── wifi_config.h # WiFi连接配置 └── lib/ └── (空不引入第三方Modbus库)platformio.ini关键配置[env:esp32dev] platform espressif32 board esp32dev framework arduino monitor_speed 115200 ; 关键禁用Arduino自带的WiFi省电确保实时性 build_flags -DCONFIG_MODBUS_RX_BUFFER_SIZE2048 -DCONFIG_MODBUS_TX_BUFFER_SIZE1024 -DARDUINO_ARCH_ESP32 ; 优化编译启用LTO链接时优化减小代码体积 lib_ldf_mode deepsrc/main.cpp骨架#include Arduino.h #include WiFi.h #include modbus_fragment.h #include modbus_handler.h #include wifi_config.h // 全局句柄 QueueHandle_t frame_queue; void setup() { Serial.begin(115200); // 1. 初始化WiFi WiFi.mode(WIFI_STA); WiFi.begin(WIFI_SSID, WIFI_PASSWORD); while (WiFi.status() ! WL_CONNECTED) { delay(500); Serial.print(.); } Serial.println(\nWiFi connected, IP address: WiFi.localIP().toString()); // 2. 初始化分片缓存系统 modbus_fragment_init(); // 3. 创建解析与发送任务 xTaskCreate(modbus_parser_task, modbus_parser, 4096, NULL, 5, NULL); xTaskCreate(modbus_sender_task, modbus_sender, 4096, NULL, 4, NULL); // 4. 启动TCP服务器监听502端口 WiFiServer server(502); server.begin(); } void loop() { // 主循环仅处理LED闪烁等低优先级任务 static uint32_t last_toggle 0; if (millis() - last_toggle 1000) { digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN)); last_toggle millis(); } }注意modbus_fragment_init()函数负责创建RX/TX环形缓冲区、初始化frame_queue并在.cpp文件中实现。modbus_parser_task()和modbus_sender_task()是FreeRTOS任务需在modbus_fragment.cpp中定义。4.2 分片缓存核心代码实现modbus_fragment.cpp以下是modbus_fragment.cpp的核心实现已通过产线压力测试#include Arduino.h #include freertos/FreeRTOS.h #include freertos/task.h #include freertos/queue.h #include esp_system.h #include esp_wifi.h #include esp_event.h #include esp_log.h #include lwip/err.h #include lwip/sockets.h #include lwip/sys.h #include lwip/netdb.h #include lwip/inet.h #include ringbuf.h // 外部声明 extern QueueHandle_t frame_queue; // RX/TX环形缓冲区句柄 static RingbufHandle_t rx_buffer_handle; static RingbufHandle_t tx_buffer_handle; // 全局TCP服务器socket static int server_socket -1; // 配置宏来自platformio.ini #ifndef CONFIG_MODBUS_RX_BUFFER_SIZE #define CONFIG_MODBUS_RX_BUFFER_SIZE 2048 #endif #ifndef CONFIG_MODBUS_TX_BUFFER_SIZE #define CONFIG_MODBUS_TX_BUFFER_SIZE 1024 #endif // 临时解析缓冲区用于处理折断数据 static uint8_t temp_parse_buf[256]; // 初始化函数 void modbus_fragment_init() { // 1. 创建RX环形缓冲区 uint8_t *rx_buffer_items (uint8_t*) heap_caps_malloc(CONFIG_MODBUS_RX_BUFFER_SIZE, MALLOC_CAP_INTERNAL | MALLOC_CAP_8BIT); assert(rx_buffer_items ! NULL); StaticRingbuffer_t *rx_buffer_struct (StaticRingbuffer_t*) malloc(sizeof(StaticRingbuffer_t)); assert(rx_buffer_struct ! NULL); rx_buffer_handle xRingbufferCreateStatic(CONFIG_MODBUS_RX_BUFFER_SIZE, RINGBUF_TYPE_BYTEBUF, rx_buffer_items, rx_buffer_struct); // 2. 创建TX环形缓冲区 uint8_t *tx_buffer_items (uint8_t*) heap_caps_malloc(CONFIG_MODBUS_TX_BUFFER_SIZE, MALLOC_CAP_INTERNAL | MALLOC_CAP_8BIT); assert(tx_buffer_items ! NULL); StaticRingbuffer_t *tx_buffer_struct (StaticRingbuffer_t*) malloc(sizeof(StaticRingbuffer_t)); assert(tx_buffer_struct ! NULL); tx_buffer_handle xRingbufferCreateStatic(CONFIG_MODBUS_TX_BUFFER_SIZE, RINGBUF_TYPE_BYTEBUF, tx_buffer_items, tx_buffer_struct); // 3. 创建帧解析队列 frame_queue xQueueCreate(10, sizeof(mb_frame_t)); // 最多缓存10帧 assert(frame_queue ! NULL); // 4. 创建TCP服务器socket server_socket socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); assert(server_socket 0); int opt 1; setsockopt(server_socket, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in server_addr; memset(server_addr, 0, sizeof(server_addr)); server_addr.sin_family AF_INET; server_addr.sin_addr.s_addr htonl(INADDR_ANY); server_addr.sin_port htons(502); bind(server_socket, (struct sockaddr*)server_addr, sizeof(server_addr)); listen(server_socket, 5); } // 解析任务扫描RX缓冲区提取Modbus帧 void modbus_parser_task(void *pvParameters) { while (1) { // 1. 从RX缓冲区读取数据非阻塞 size_t received_size; uint8_t *item (uint8_t*) xRingbufferReceiveUpTo(rx_buffer_handle, received_size, 0, CONFIG_MODBUS_RX_BUFFER_SIZE); if (item NULL) { vTaskDelay(1 / portTICK_PERIOD_MS); continue; } // 2. 处理数据折断情况 uint8_t *parse_ptr