Modbus实践提要
这页是对原 Modbus应用笔记 的压缩版，重点不是复述协议，而是说明它在真实项目中的边界。
先看结论
Modbus RTU很适合低速、寄存器式、主从明确的控制场景。- 如果要传的是照片、文件或大块业务数据，它通常就不是一个优雅的承载协议。
- 不是不能做，而是代价会转化为频繁交互、吞吐很低、协议改造越来越重。
项目里遇到的真实问题
- 一个 ESP32-S3 主控需要和一个或多个摄像头模组通信。
- 某些场景还需要把摄像头拍到的图片传回来。
- 最终选了
RS485 + Modbus RTU的组合，但很快碰到了单包能力受限的问题。
为什么会卡住
- 标准
Modbus RTU报文很短，本质是寄存器读写协议。 - 它的设计更适合“读状态、写参数、触发动作”，不适合“搬运大块二进制内容”。
- 当数据量上到几百 KB 级别时，哪怕链路本身没问题，请求/响应模型也会让效率变得很难看。
功能码 23 的意义
0x17是“读/写多个寄存器”。- 它能在一次事务里先写后读，适合做“写命令 + 读结果”的组合操作。
- 这类功能码可以提高小块交互效率，但并不能从根本上把 Modbus 变成大数据传输协议。
更值得记住的判断
- 如果你的需求主体是设备控制，Modbus 很合适。
- 如果你的需求主体是大块数据搬运，应该尽早考虑别的协议或拆分架构。
- 如果不得不继续用 Modbus，重点应该放在：
- 业务上能否缩小交互数据量
- 是否只传元数据而不传原始大对象
- 是否把大数据链路拆到别的通道
库与实现
esp-modbus在功能码支持上要结合实际验证，不能只看“API 名字像支持”。libmodbus更适合作为桌面端或上位机侧的验证和辅助实现。