目录一、前言二、RTU 与 TCP 的帧格式差异三、Write File Record 请求格式四、modbus_write_file_record 实现五、响应长度计算函数解析六、总结七、结尾一、前言大家好这里是Hello_Embed。上篇完成了 Socket 状态检测与断线重连机制Modbus TCP 通信已经具备了基本的容错能力。本篇来实现**写文件Write File Record**功能。建议本篇涉及 Modbus 文件记录的概念建议先阅读设备互联系列笔记再阅读本文以便更好地理解上下文。在 Modbus RTU 项目中已经实现过写文件功能但当时只考虑了 RTU 协议的帧格式。要在 TCP 上复用同一套逻辑需要对帧头部分做适配——这正是本篇改造的核心。二、RTU 与 TCP 的帧格式差异Modbus RTU 和 TCP 的帧结构有明显差别主要体现在头部长度字段RTUTCP从机地址 / 单元标识符1 字节1 字节MBAP 末位事务处理标识符—2 字节协议标识符—2 字节长度字段—2 字节头部合计1 字节7 字节功能码1 字节1 字节数据N 字节N 字节解析RTU 帧头只有 1 字节从机地址而 TCP 帧头有 7 字节MBAP Header。原来的 RTU 写文件代码中头部偏移量是硬编码的1要支持 TCP必须把它改成动态计算的offset从ctx-backend-header_length取得。三、Write File Record 请求格式Write File Record功能码 0x15的完整请求帧结构如下字段大小说明从机地址1 字节RTU 帧头TCP 中位于 MBAP 内Function Code1 字节固定为0x15Request Data Length1 字节后续数据总字节数 7 数据字节数Reference Type1 字节固定为0x06File Number2 字节文件编号Record Number2 字节记录编号Record Length2 字节记录数据的字数注意单位是字非字节Record DataN×2 字节实际数据长度必须为偶数其中Request Data Length 7 数据字节数即固定的子请求包头Reference Type File Number Record Number Record Length 7 字节加上实际数据。四、modbus_write_file_record 实现将 RTU 版本的写文件函数改造为同时支持 RTU 和 TCP关键改动是用offset替代硬编码的头部偏移量intmodbus_write_file_record(modbus_t*ctx,uint16_tfile_no,uint16_trecord_no,uint8_t*buffer,uint16_tlen){intrc;inti;intreq_length;uint8_treq[MAX_MESSAGE_LENGTH];intoffset;/* 长度必须为偶数Record Length 单位是字 */len(len1)~0x1;/* 数据长度合法性检查 * RTU ADU 最大 256 字节减去 1 字节地址、2 字节 CRC 253 字节有效载荷 * 其中功能码包头占 9 字节剩余最多 244 字节用于传输数据 */if(len2||len244)return-1;/* 动态计算头部偏移量RTU 为 0从从机地址开始TCP 为 6跳过 MBAP */offsetctx-backend-header_length-1;/* 填充请求帧头部 */req[offset]ctx-slave;/* 从机地址 / 单元标识符 */req[offset]MODBUS_FC_WRITE_FILE_RECORD;/* 功能码 0x15 */req[offset]7len;/* Request Data Length */req[offset]0x06;/* Reference Type */req[offset]file_no8;/* File Number 高字节 */req[offset]file_no0x00FF;/* File Number 低字节 */req[offset]record_no8;/* Record Number 高字节 */req[offset]record_no0x00FF;/* Record Number 低字节 */req[offset](len/2)8;/* Record Length 高字节字数 */req[offset](len/2)0x00FF;/* Record Length 低字节字数 */req_lengthoffset;/* 填充数据 */for(i0;ilen;i)req[req_length]buffer[i];/* 发送请求并等待响应 */rcsend_msg(ctx,req,req_length);if(rc0){uint8_trsp[MAX_MESSAGE_LENGTH];rc_modbus_receive_msg(ctx,rsp,MSG_CONFIRMATION);if(rc0)return-2;rccheck_confirmation(ctx,req,rsp,rc);}returnrc;}解析offset ctx-backend-header_length - 1是整个改造的核心。header_length在 RTU 中为1含从机地址在 TCP 中为7含 MBAP Header。减去1后offset指向req数组中从机地址所在的位置后续字段依次填入。由此同一套代码在两种协议下均能正确构造帧结构。五、响应长度计算函数解析库内部通过compute_response_length_from_request函数预先计算期望的响应帧长度以便校验接收到的数据是否完整。Write File Record 对应的分支如下staticunsignedintcompute_response_length_from_request(modbus_t*ctx,uint8_t*req){intlength;constintoffsetctx-backend-header_length;switch(req[offset]){/* ... 其他功能码 ... */caseMODBUS_FC_WRITE_FILE_RECORD:lengthreq[offset1]2;break;default:length5;}returnoffsetlengthctx-backend-checksum_length;}这里req[offset 1]取到的是Request Data Length字段即7 数据字节数再加上2是因为要把**功能码1 字节和 Request Data Length 自身1 字节**也计入总长度。以一次包含N字节数据的请求为例推导字段字节数功能码1Request Data Length值 7 N1Sub-Request 包头Reference Type File/Record No. Record Length7Record DataN有效载荷合计9 N所以length req[offset 1] 2 (7 N) 2 9 N与上表吻合。最终函数返回总字节数 offset协议头 length有效载荷 checksum_length校验码RTU 中offset 1checksum_length 2CRCTCP 中offset 7checksum_length 0无校验码。同一个表达式自动适配两种协议。解析这个计算方式的巧妙之处在于Write File Record 的响应帧与请求帧有效载荷结构完全一致Server 原样回显所以用请求帧的Request Data Length字段直接推算响应长度无需额外字段。六、总结改造点改造前RTU改造后RTU TCP头部偏移量硬编码为1动态计算ctx-backend-header_length - 1响应长度计算固定公式通用公式offset req[offset1] 2 checksum_length适用协议仅 RTURTU 和 TCP 均支持经过本篇改造写文件功能已经完全协议无关——无论底层使用 RTU 还是 TCP上层调用接口保持不变协议差异由ctx-backend封装层透明处理。七、结尾本篇完成了写文件功能从 RTU 到 TCP 的适配改造核心是用动态offset替代硬编码头部偏移实现了协议无关的帧构造。下一篇将改进 H5 开发板程序增加更完善的容错机制敬请期待Hello_Embed继续带你从原理到实践掌握嵌入式上位机开发的核心技能敬请关注