嵌入式与工控通讯笔记

第二篇把协议赶出了框架，结尾立了个 flag：接第二种协议时才见真章——如果新协议逼我改了框架，那套“零协议、按索引”的抽象就没立住。 这一篇来还债。选的是西门子 S7：它的地址是 DB1.DBW0、M0.0、IW4，和 Modbus 的“区域 + 寄存器号”是两个世界，最适合拷问抽象。结论先说：框架和界面一行没改，加的只是一个新协议模块 + 一个驱动。 项目代号 talkplc。S7 部分从公开的 S7comm 协议从零写——只依据公开资料与抓包，个人时间与设备，不涉任何厂商代码。 S7 不是“一层”，是三层套娃Modbus 一帧很扁：从站 + 功能码 + 数据 + CRC。S7 classic（S7-300/400/1200/1500 的非优化访问）要啰嗦得多——它是三层套在一起： 12345678┌─ TPKT (RFC1006) 03 00 [长度16] ──────────────────────────────┐│ ┌─ COTP 02 F0 80 ───────────────────────────────...

上一篇做了件狠事：把 area/寄存器/站号这些“协议味”彻底赶出框架，界面连协议都不认识，靠一份 JSON 配置就能驱动。当时结尾说下一篇去接第二个协议——但我先插一篇，因为这次分离结出了一个太顺手的果子，值得单独说：显示层可以做成“即插即用的构件”了。 本篇让一个仪表盘构件上线，并用一段配置拼出一块可弹出、可投大屏的看板。项目代号 talkplc，纯净室开发，只依据公开协议规范，个人时间与设备。 红利从哪来：数据是一份“按索引寻址的快照”回顾一下上两篇搭出来的数据流：采集线程每一拍产出一份点位快照——一个按下标排列的数组，每个元素是 { 值, 有效, 状态 }。界面（或任何前端）只做一件事：按索引取值。 关键就在这“按索引”三个字。它意味着：任何想显示数据的东西，只需要知道两件事——绑定哪个下标、拿到快照后取出那个值。 至于这个值是 Modbus 保持寄存器、还是以后的西门子 DB 块，显示端一概不关心。 1234567采集线程 ──每拍──▶ 快照 tag[]（按索引：值/有效/状态） │ ...

上一篇把 talkplc 的分层讲清楚了，结尾立了个 flag：“加 Modbus TCP，协议帧逻辑一行不改，只写个新传输后端”。这一篇来兑现它。 但真动手时，这句话只说对了一半——传输确实一行没改，加 TCP 的过程却反过来把框架里藏着的“Modbus 味”照了出来，逼我做了一次不小的架构微调。正好应上一篇那句：架构是会被新需求反复拷问的。 项目代号 talkplc，纯净室开发，只依据公开协议规范，个人时间与设备。 先兑现承诺：Modbus TCP 到底改了什么Modbus RTU 和 TCP，应用层的读写请求（PDU）是一模一样的——都是“功能码 + 起始地址 + 数量”。区别只在外面那层壳： 12345678RTU（串口）： ┌──────┬───────────┬─────────┐ │ 从站 │ PDU │ CRC16 │ └──────┴───────────┴─────────┘TCP（以太网）：┌───────────── MBAP 头 ─────────────┬──────┬─...

上一篇把 Modbus 一帧报文逐字节拆开讲了。这一篇往上走一层：与其每个项目都重写一遍 Modbus/西门子/三菱的收发，不如把它做成一套能长期用、能跑嵌入式、还能给上位机绑定的库。这是这个系列的第一篇，先把架构和取舍说清楚——协议实现的细节留给后面每一篇。 项目代号 talkplc。纯净室开发，只依据公开协议规范，个人时间与设备。 为什么又要造一个通讯库工控现场的协议是一堆的：Modbus RTU/TCP、西门子 S7、三菱 MC、欧姆龙 FINS/Hostlink、CODESYS…… 每接一个新设备、每起一个新项目，都在重复写”打开串口 → 拼一帧 → 算校验 → 收一帧 → 解出寄存器”。 已有的轮子里，HslCommunication 很成熟，但主要面向 .NET。我想要的不太一样： 以 C 为核心，能直接跑在嵌入式 Linux / 网关上，不背运行时； 对外暴露干净的 C API，方便再包一层给 C# / Python 做上位机； 模块解耦，用哪层链哪层，别一上来就拖一坨依赖。 对我个人，它同时是...

博客的第一篇技术文，从 Modbus 开始。它是工控通讯里的”普通话”——几乎所有 PLC、仪表、变频器、传感器都认它。这篇文章分两部分：先把一帧报文逐字节 + 图解看懂；再把我在 RS-485 现场踩过、见过的坑，按物理层 / 时序层 / 协议层分类列全。 一句话理解 ModbusModbus 是主从（Master / Slave）+ 一问一答的协议：只有主站发起请求，从站被动应答。 1234567sequenceDiagram participant M as 主站 Master participant S as 从站 Slave M->>S: 请求帧（功能码 + 地址 + 数量） Note over S: 校验 CRC → 处理请求 S-->>M: 响应帧（数据 或 异常码） Note over M: 校验 CRC → 解析数据 学 Modbus 核心就三件事：数据放在哪（数据模型）、怎么点名（功能码 + 地址）、报文长什么样（帧结构）。 数据模型：四种”区” 数据区 读...

这是博客的第一篇。之所以开这个站，是想把自己在嵌入式软件和工业通讯协议上踩过的坑、想明白的原理、造过的轮子，公开地记录下来。 我会在这里写什么我日常打交道的，是设备与设备之间”说话”的那一层——各种工业通讯协议： Modbus（RTU / TCP）——绕不开的入门与常青协议 西门子 S7、三菱 MC、欧姆龙 FINS/Hostlink——主流 PLC 的通讯门道 CODESYS 及其它现场总线 / 工业以太网 内容大概是三类： 协议拆解：把一帧报文逐字节讲清楚，知其然也知其所以然 踩坑复盘：现场通讯不稳、丢帧、时序、干扰……这些真实问题是怎么定位和解决的 造轮子：我正在写一个开源的多协议通讯库（用 C/C++，可跑在嵌入式设备上），进展和设计思路会同步在这里 为什么要公开写一部分是逼自己把经验系统化——很多东西不写下来，就永远停留在”会用”而非”讲得清”。另一部分，是想认识更多同行。如果你也在工控 / 嵌入式这条路上，欢迎交流、拍砖、一起把协议这件事聊透。 慢慢写，长期更新。