干这行的时间长了手里总会攒下几个“看着简单、做起来全是细节”的项目。ESP32做ModbusTCP从站本身不是什么新鲜事但如果你要让这颗芯片在充当TCP从站的同时再去背后挂一串ModbusRTU设备那问题就来了——RS485轮询慢、TCP客户端却一个劲儿地读两边节奏对不上中间必须有一层缓冲。我这次要说的“ESP32 ModbusTCP 分片缓存”就是为了解决这种错位而设计的一个中间层。简单说这套方案做的是一个“ModbusTCP网关”上位机通过以太网访问ESP32ESP32再通过RS485和下面的RTU设备通信。为了不让每次TCP读请求都穿透到RS485总线上我把Modbus数据空间按寄存器范围切成若干个“分片”每个分片独立缓存、独立刷新。命中缓存的请求直接回数据没命中或者过期的分片才去总线上拉。项目本身不大但涉及的缓存管理、状态机、并发保护这些点是实实在在能用到别的项目里的。这篇东西适合正在做Modbus网关、或者想在ESP32上做“带缓存的服务端”的朋友参考我把整个设计和踩坑过程都摊开讲。1. 分片缓存这个想法是怎么被逼出来的1.1 现场的实际痛点我以前做的网关项目大多数是单片机做从站直接响应上位机的读写。那种场景比较简单数据就在本地寄存器里读多少写多少CPU速度足够根本不存在缓存问题。但这次的设备结构不一样ESP32只是一个中转站真正的数据在RS485下面的各类仪表里。先看一组数据RS485在9600波特率下读一个功能码为03、长度为20个寄存器的请求报文大约要走20到30毫秒算上设备响应时间和总线切换一个完整的读周期往往在40毫秒以上。而上位机的扫描周期如果是500毫秒它会一口气把所有关注的寄存器都读一遍。假如关注点分布在8个不同设备上那就要串行去轮询8台设备一轮下来现场要小1秒。这还是在没算通信异常重试的情况下。上位机那边可不这么想它认为TCP访问一个从站应该就是几十毫秒的事。一旦响应超时组态软件就会把设备标红、产生报警。要么把上位机扫描周期调大要么把每台设备单独建TCP连接——这两种办法一个是拖性能一个是让工程量翻倍。所以我在中间加一个缓存层本质上是把“响应速度”和“数据实时性”解耦TCP侧永远快速响应RS485侧按自己的节奏去刷新数据。1.2 为什么缓存要“分片”而不是整块缓存刚开始做的时候我脑海里第一个方案非常粗暴给每个从站设备分配一整块缓冲区上位机不管读哪个区域都从这块缓冲区里取。一开始测试确实能跑但代码一复杂就发现问题很大。首先是内存利用率的问题。ESP32虽然有320KB左右的片上RAM但实际分给用户应用的只有160KB左右还要跑Wi-Fi协议栈、TCP/IP协议栈。如果你把每个设备的寄存器范围都按最大的寄存器数量去分配比如一台设备最大地址是0x200、保持寄存器和输入寄存器都开这么宽一台设备就要2KB以上。挂上10台设备光寄存器缓存区就干掉20KB这还没算HashMap、互斥锁和网络缓冲。其次是刷新效率的问题。有些设备的数据变化频繁比如电能表的有功功率一秒钟跳好几次有些数据基本不动比如版本号、额定电压这类参数。如果整块缓存每次都整体刷新大量RS485带宽都浪费在那些不变的数据上。分片之后你可以把电源参数单独放一个分片、刷新周期设成500毫秒把设备标识码这类静态数据放另一个分片刷新周期设成10秒甚至只在启动时读一次。还有一个隐蔽的问题写操作的一致性。如果上位机通过Modbus写单个寄存器而这块缓存正好是整块的你需要立刻更新缓存里的那个位置。整块缓存更新意味着要么把全部数据重新读一遍要么精准修改缓冲区里的偏移量。靠谱的做法显然是后者但前提是你得知道这个寄存器在缓冲区里的位置——这不就又变成“片区管理”了吗所以直接在一开始就把数据切成多个分片设计上更干净后面扩展功能也容易。1.3 一套可参考的分片策略我最后用的是三层划分法。第一层按从站地址分每个RTU设备的寄存器独立管理第二层按功能码分保持寄存器、输入寄存器、线圈、离散输入本身在Modbus里就属于不同的地址空间必须分开第三层在同一个地址空间内部再按寄存器长度切块我这边每个分片固定管64个寄存器。为什么固定64个而不是16或者128这是权衡出来的结果。分片太小比如16个寄存器好处是刷新粒度细但分片数量会非常多调度和存储管理开销反而大分片太大比如128个寄存器一次RS485读返回的数据量虽然没超现场总线的报文上限但某个寄存器被高频访问时会把整个128个寄存器的刷新周期拖慢。64这个数值读一次报文长度在10到80毫秒之间既能覆盖一次典型的上位机读取范围又不会因为分片数过多把后台轮询程序搞成瓶颈。当然这个值不是死的如果你的设备寄存器特别密集就调小了用数据点很稀疏调大了更划算。2. 系统框架设计和分片状态机2.1 整体线程模型ESP32跑的是FreeRTOS整个网关我拆成三条线。第一条是TCP服务线程负责监听502端口、解析MBAP报文头、处理Modbus功能码并对分片缓存执行“命中读/未命中发起加载”的动作。第二条是RS485轮询线程专职维护一个“分片调度队列”按分片各自的时间戳决定现在该刷新哪个分片。第三条是个辅助线程专门处理TCP客户端的连接管理、超时断连这些杂务避免慢客户端拖住主循环。这三个线程共享的对象就是分片缓存表。缓存表本身是一个结构体数组长度在系统初始化时根据配置文件动态分配每个元素对应一个分片。对这个表的所有读写都包了一层互斥锁锁的粒度控制到单个分片尽量不锁整张表。一开始偷懒用全局大锁结果高负载时TCP线程和轮询线程互相等锁读写性能直接掉一半后来改成“每片一锁”才解决。2.2 分片状态机的四个状态每个分片不是简单地“有数据”和“没数据”两态而是设计成四态。空特征EMPTY、刷新中LOADING、有效VALID、过期STALE。EMPTY是分片刚注册还没碰过的状态LOADING表示已经有RTU请求在总线上跑数据还没回来VALID表示缓存里有比“有效时间窗口”更新的数据可以直接命中STALE表示数据存在但已经过了有效期。这个状态机最关键的地方是它处理了“多个TCP请求同时访问同一个分片”的情况。如果没有LOADING状态两个TCP请求同时来发现缓存过期就会发起两次一模一样的RS485读请求浪费总线带宽。有了LOADING状态后到的请求只需要看到状态是LOADING就等待同一个RTU请求完成然后共享结果。状态迁移的完整路径是EMPTY收到读请求后发起刷新进入LOADING刷新成功带着时间戳进入VALID时间戳超时迁到STALESTALE收到读请求再发起刷新回到LOADING。刷新失败不会直接丢掉分片而是衰减进入STALE同时记录失败次数连续失败超过5次就不再触发刷新防止坏设备把总线和CPU都耗死在重试上。2.3 分片表的管理与注册机制有人看到“分片表”就会想起动态数组、链表这些。我在这个项目里用了一个很土办法注册式分配。系统启动时解析一个配置文件里面描述每个从站有哪些分片、起始地址、长度、刷新周期、数据保存类型。解析完直接把一张静态数组按配置填满每一项的索引固定不变。这样做的好处是运行时不用malloc完全避免内存碎片问题。ESP32上跑久了频繁分配和释放小块内存很容易让堆碎片化最后明明看着空闲内存不少就是分配不出一个连续块。分片表固定后除了“值缓冲区”在分片初始化时一次性分配好整个生命周期内没有第二次动态内存操作。后来这台设备在测试环境连续跑了两个多月没有出现一次因内存不足导致的崩溃。3. 核心实现细节从数据结构到请求路径3.1 分片结构体到底该长什么样我定义的分片结构体大概是这样typedef enum { CACHE_EMPTY 0, CACHE_LOADING, CACHE_VALID, CACHE_STALE } cache_state_t; typedef struct { uint8_t slave_addr; // RTU从站地址 uint8_t func_code; // 只支持03/04读类写类不缓存 uint16_t start_addr; // 寄存器起始地址 uint16_t reg_count; // 分片长度固定为64 uint16_t refresh_ms; // 刷新周期 uint32_t last_loaded_tick;// 最后一次成功加载的系统tick cache_state_t state; // 当前状态 SemaphoreHandle_t lock; // 分片级互斥锁 uint16_t *values; // 指向实际的寄存器值缓冲区 uint16_t fail_count; // 连续失败次数 uint8_t priority; // 调度优先级0最高 } modbus_cache_slice_t;这里有几个细节值得展开。slave_addr 是目标设备地址func_code 只写了03和04是因为我这边分片缓存只针对“读保持寄存器”和“读输入寄存器”这两种数据类型。线圈和离散输入的数据量小直接用位图缓存不参与分片管理。refresh_ms 是按实际场景配置的比如电表的电压电流设500毫秒累计电量设1000毫秒设备型号这些静态量设30秒。锁用了 FreeRTOS 的互斥信号量这里不能用二值信号量因为二值信号量最低优先级反转的问题在某些场景下会很致命。values 缓冲区为什么单独指针而不是内嵌数组因为分片数量是配置出来的而每个分片的 reg_count 不一定是64后续如果改成支持灵活长度内嵌数组要么浪费空间要么不够用。单独指针可以让每个分片按自己的实际大小去分配排布更紧凑。3.2 读请求的“命中优先”处理流程当一个ModbusTCP读请求进来处理函数走的是下面这条链路。第一步检查报文头确认功能码是03或04然后从请求里解析出起始地址和寄存器数量。第二步按“(功能码, 从站, 地址范围)”算出它涉及哪几个分片。第三步对涉及到的每个分片执行“读快照”操作。所谓读快照就是调用一个返回数据副本的函数而不是直接把 values 指针交给调用方。为什么要副本因为如果直接把指针给上层模块上层正在拼接TCP响应的时候后台轮询线程可能正好更新这个分片同一个寄存器读出来一会儿是一会儿二数据就不一致了。用副本虽然多了一次内存拷贝但在64个寄存器这种规模下一次memcpy也就是一百多字节代价完全可以忽略。如果分片状态不是VALID那就走未命中路径。未命中时先看状态是不是LOADING如果是就挂在这个分片的“完成信号量”上等待如果不是就把状态置为LOADING然后丢一个“加载请求”到RS485轮询线程的队列里再等待信号量。这个“等待”动作得设超时我经验值是200毫秒。因为RS485上一台设备如果本身就没接好或者地址不对请求发出去之后可能根本没有响应要等寄存器返回超时这往往要几百毫秒甚至一秒。TCP客户端不可能等那么久所以超过200毫秒还没回来的就按异常响应返回给对端。有的同学会问那这种情况是不是会让上位机看到偶发超时是的但这是合理的——设备真正离线时该超时就超时正常在线时命中率很高基本不会走到这一步。3.3 写操作的直写与失效策略分片缓存不能把所有功能码都缓存特别是写操作。Modbus的写操作包括写单个寄存器功能码06、写多个寄存器功能码16、写单个线圈05、写多个线圈15这些操作我全都不缓存一律直写。直写的含义是TCP请求解析之后直接构造RTU报文发到总线上等待RTU响应的结果再原样返回给TCP客户端。但直写会引出缓存一致性问题。比如上位机写了一个寄存器这个寄存器恰好也在某个分片里分片里的旧值没有同步更新下一次读请求上来直接命中缓存读到的还是旧值这是绝对不能接受的。我的解决方案是“先写成功再让缓存失效”。所谓失效不是把分片状态变成EMPTY也不是把整个分片删掉而是把它打上“被污染”标记并把状态推到STALE。这样下一次读到这个分片发现不是VALID就自然触发刷新从设备上重新拉一遍数据。这个方法有个额外好处如果上位机连续写同一个寄存器中间不会插进来多余的总线读操作只有在写完后的第一次读请求才会触发刷新大大提升了总线利用率。线圈写操作和寄存器写操作在一致性处理上也类似不过因为线圈数据量小我干脆把线圈的缓存做成“写后更新”写完线圈后直接修改对应位图的缓存值这样不用像寄存器分片那样每次都要等刷新读线圈的响应几乎可以做到瞬时返回。4. 后台轮询调度和FreeRTOS协作4.1 轮询线程怎么排任务后台轮询线程做的事情很简单扫描全部有效分片找出所有满足“状态是VALID或STALE且距上次加载时间超过refresh_ms”的项从其中挑出最多N个构造成RTU请求发出去。N由任务栈大小决定我这边设了4也就是每轮最多同时发4个请求。为什么要限制同时发出的数量因为RS485是半双工的所有请求都挂在同一条总线上如果一口气把几十个请求全发出去光靠分时排队也会让低优先级分片吃不到总线更重要的是同时发出多请求会导致总线碰撞和响应乱序必须控制并发数。调度算法我用的是一种带优先级的“按到期时间排序”的办法。每轮开始前先统计所有分片的“剩余到期时间”也就是 refresh_ms 减去已经过去的时间。剩下时间最少的那个分片往往是优先度最高的。这样高频分片自然排在前面低频分片也不至于永远被挤掉——因为每次调度完高频分片后它会进入一个较长的冷却期调度器就有机会处理低频分片。不需要维护复杂的实时系统优先级这个贪心策略在项目里跑得很稳。4.2 FreeRTOS任务栈和信号量细节轮询线程的任务栈我设为4096字节优先级比TCP线程低两档。为什么低因为轮询刷新的是后台数据晚一两个周期没有太大影响而TCP请求是上位机在等的响应慢了几百毫秒就可能被标记超时。所以把TCP线程的优先级设高让前台的响应性能优先得到保障。互斥锁的使用上我强调一点绝对不要在持有分片锁的时候去等RTU响应。因为RTU响应要等硬件收发完成最坏情况要等1秒以上如果此时线程持锁等待另一个线程访问同一个分片就会被卡住整个系统出现“假死”。我的做法是分片锁只会在“读取快照”和“修改状态字段”这种微操作上持有到了真正挂起等待RTU的环节会先把锁释放掉。通信完成后的回调机制也值得说说。RTU收发完成会在轮询线程内部调用一个完成函数这个函数会检查请求对应的分片索引然后更新 values 缓冲区、设置 last_loaded_tick、把状态置为VALID最后 release 分片上的完成信号量。TCP线程里等这个信号量的任务会被唤醒拿到的就是一份“已更新”的快照。4.3 异常分支设备离线、报文异常、超时重试设备离线是最常见的坑。一个分片连续拉了5次全部超时继续拉只会让总线被这个不存在的设备占死。我设了一个“失败上限”达到上限后把该分片状态置为STALE并且设置一个“惩罚时间”——比如30秒内不再往调度队列里放它。这样其他在线设备的分片不会饿死。还有一种情况是设备回包异常最常见的是地址正确但功能码回的是异常码比如设备收到非法地址的请求会回一个功能码最高位置1的数据。对这种回包的处理我把它等同为刷新失败但不算设备离线所以只触发一次重试不进入惩罚。这是因为异常码可能是设备侧的瞬时状态比如某个寄存器的读取权限还没初始化好过一会再读就正常了。有人会问如果一台设备被上位机连续读写而它的某一个分片refresh_ms设得很短会不会导致这个分片永远排在队列前面、其他分片饿死这就是我上面说的“到期时间排序冷却期”算法发挥作用的地方。短周期的分片被刷新一次后到期时间会被推到很久以后这时其它分片的机会就来了。实测用6个从站、每个从站4个分片、其中有2个分片周期为300毫秒的情况下最长等待的静态分片最迟不超过2秒就会被刷新一次完全能接受。5. 实测数据缓存前后到底差了多少5.1 测试环境搭建我把这套固件烧到了ESP32-WROOM-32E模块上外接了一块RS485转TTL小板板子上挂了6台从站。从站里有两台是我用另一块ESP32模拟的一个是电能表模拟器另一个是温湿度传感器模拟器剩下四台是实物仪表。所有从站都通过ModbusRTU协议挂在9600波特率、8N1的总线上。TCP侧是用电脑上的Modbus调试助手做客户端同时用Wireshark抓包。为了保证测试有说服力我把6台设备的数据范围全部铺开让上位机会在500毫秒扫描周期内读所有设备的全部寄存器模拟一个真实的组态画面刷新场景。5.2 响应延迟对比没有缓存的时候一次TCP读请求要穿透RS485最高延迟经常冲到180毫秒以上平均值在70毫秒左右。主要时间花在排队等轮询上因为RS485上的请求队列是先进先出的。加了分片缓存后命中状态下的响应时间基本就在5毫秒以内主要就是网络出包时间和ESP32内部处理时间。再看一个更有意思的指标总线负载。没有缓存时6台设备每台每秒被读至少2次每秒总线上要跑12个读请求有缓存后最活跃的电能表分片每500毫秒刷新一次静态参数分片每30秒刷新一次。算下来每秒总线上平均只有4个请求。总线空闲下来了整个网络的通信可靠性也随之提升偶发干扰导致的重试也少了很多。5.3 Wireshark抓包里验证到的细节用Wireshark抓包能清楚看到缓存的命中行为。正常运行时上位机的读请求TCP响应帧几乎紧跟着请求帧就回来了间隔在1到3毫秒。而每500毫秒左右会有一个延时明显偏高的响应通常在30到60毫秒之间那个就是缓存过期触发RS485刷新产生的。做统计分析时可以拿这个时间差作为判断缓存是否命中的依据。还发现一个有意思的现象RS485刷新请求本身带的是ModbusRTU报文Wireshark默认解析不了RTU会显示成一串十六进制数据。所以我做了个额外工作在固件里加了一条“日志通道”把RTU收发报文的hex也打到一个虚拟串口上。这样Wireshark看TCP层、串口日志看RS485层两边对一下时间戳调试效率立刻不一样。这个习惯后来帮我定位了好几次问题。6. 常见问题排查和避坑清单6.1 几个我踩过的坑第一个坑是位序字节序。Modbus寄存器是16位的高位在前。ESP32是小端模式内存里 uint16_t 的低字节在低地址。直接memcpy寄存器数组到缓冲区再按字节拼接响应出来就是高低位反转。我处理方式是定义统一的“pdu字节序”接口拼接响应时手动操作先取寄存器值的高字节再取低字节。这个坑虽然老套但每次项目都可能再踩一遍。第二个坑是TCP连接管理。ModbusTCP理论上允许同一个TCP连接连续发多个请求。上位机软件很多是流水线式地连续发不等上一个响应回来就接着发下一个。如果固件用的是“一个连接一个线程”或“单线程处理只读一个socket”的简单模式很可能把后续请求丢在缓冲区里导致上位机显示数据不刷新。我后来在TCP线程里专门做了一个16字节深度的MBAP请求队列每帧响应都带上对应的事务ID请求一一对应回包才算彻底解决。第三个坑是内存拷贝的“隐藏代价”。我用分片锁保证一致性时第一次实现是在锁内直接把 values 指针递给了网络发送函数结果Wireshark里偶发看到响应帧字节错位。原因就是轮询线程更新分片和TCP线程拼帧并发执行数据竞争。后来全面改成“先拷贝快照再拼帧发送”问题就消失了。所以在这个项目里多花的几次memcpy是值得的。6.2 排查工具和使用心得日志是整个系统最便宜也最好用的“示波器”。我按模块分了三个日志级别TCP连接管理、分片调度、RTU收发。平时只开错误级排查问题是打开全部并在日志里带上精确到毫秒的时间戳。遇到疑难问题一份完整的带时间戳日志加一段Wireshark抓包能覆盖90%的排查场景。另一个技巧是用“事务ID”做关联分析。在TCP响应帧里加上事务ID在日志里记录这个事务ID对应的分片索引和缓存状态。上位机读到某个数据很奇怪时翻日志就能定位到是缓存命中读的旧值还是触发了一次刷新读的新值。这个关联手段在排查一致性问题时特别好用。6.3 我建议你保持的几个设计习惯如果你也打算写自己的ModbusTCP缓存层有几个习惯我建议从一开始就保持。第一个是“所有配置走静态表”给分片建立“注册式配置”不要运行时动态增加分片省内存也省心。第二个是“锁粒度越小越好”哪怕多写几个锁函数也别图省事给整张缓存表上一把大锁。第三个是“不要信任设备的响应”每帧RTU响应都要校验地址、功能码、CRC容错处理宁可多写几行代码。最后关于“缓存多久算过期”这个参数很难有一套普适值。我的经验是电压电流温度这类变化快的数据设300到1000毫秒电能累计值这类变化慢但总量会增长的设1到2秒版本号、设备序列号这种静态量直接设300秒以上都行。核心思路是把最活跃的流量限制在少数几个分片里让大部分静态数据几乎不占用总线。现在这套分片缓存的代码已经被我用到两个实际项目里了其中一个在客户现场连续跑了半年没有重启过在线率稳定在99%以上。我个人最深的体会是嵌入式项目里“缓存”两个字永远不是单纯为了快更多是为了把慢速外设和快速网络之间的节奏差异给抹平。分片只是手段真正值钱的是状态机和一致性设计。你在自己的项目里如果也要做类似的东西建议先把分片状态机画清楚、把锁的层级定明白再开始写代码后面返工能少吃很多苦。