本文首发于我的个人博客 talkplc.com同步发布于 CSDN。原文链接https://talkplc.com/2026/07/18/talkplc-architecture/上一篇把 Modbus 一帧报文逐字节拆开讲了。这一篇往上走一层与其每个项目都重写一遍 Modbus/西门子/三菱的收发不如把它做成一套能长期用、能跑嵌入式、还能给上位机绑定的库。这是这个系列的第一篇先把架构和取舍说清楚——协议实现的细节留给后面每一篇。项目代号talkplc。纯净室开发只依据公开协议规范个人时间与设备。为什么又要造一个通讯库工控现场的协议是一堆的Modbus RTU/TCP、西门子 S7、三菱 MC、欧姆龙 FINS/Hostlink、CODESYS…… 每接一个新设备、每起一个新项目都在重复写“打开串口 → 拼一帧 → 算校验 → 收一帧 → 解出寄存器”。已有的轮子里HslCommunication很成熟但主要面向 .NET。我想要的不太一样以 C 为核心能直接跑在嵌入式 Linux / 网关上不背运行时对外暴露干净的 C API方便再包一层给 C# / Python 做上位机模块解耦用哪层链哪层别一上来就拖一坨依赖。对我个人它同时是三样东西一个开源作品集、这个博客的选题引擎每实现一个协议写一篇以及一个长期想做下去的方向。一开始就定死的几条原则纯 C11 内核 干净 C API——最大可移植性绑定友好。传输与协议分离——协议层不关心底下是串口、TCP 还是内存模拟。每层单独成库、可单独链接——只想要 Modbus 帧逻辑那就只链协议模块不拖串口。没有硬件也能测——内置一个内存里的从站模拟帧逻辑不靠真设备就能验证。架构总览分层大概长这样依赖方向自上而下、绝不反向应用 / 上位机 / 绑定 (C#、Python…) │ ┌──────────▼──────────┐ │ gui Qt 监视界面 │ 可视化可选 └──────────┬──────────┘ ┌──────────▼──────────┐ │ poll 后台轮询线程 │ C11 线程对外只给“线程安全快照” └──────────┬──────────┘ ┌──────────▼──────────┐ │ driver 点位(tag)模型 │ 地址类型 → 值连续寄存器批量读 └───┬──────────────┬───┘ ┌───────▼──────┐ ┌─────▼──────────┐ │ modbus 协议 │ │ datatype 类型解码 │ └───────┬──────┘ └────────────────┘ ┌───────▼──────┐ │ serial 传输后端 │ 串口以后加 TCP └───────┬──────┘ ┌───────▼───────────────────────────┐ │ core 状态码 传输接口 收发帧回调 │ 人人依赖的地基 └───────────────────────────────────┘每层的职责模块干什么依赖core状态码、传输接口、收发帧回调trace—serial串口 I/OWindows / POSIX以后同法加 TCPcoremodbusModbus 帧的拼装 / 解析 / 校验不关心串口coredatatype寄存器 ↔ 数据类型u16/i16/u32/i32/f32/bool 字序—driver点位模型 轮询 批量读modbus, datatypepoll把驱动跑在后台线程上对外给线程安全快照drivergui工业风监视界面Qtpoll下面挑三个最关键的设计点讲讲——只讲思路代码点到为止。设计一传输层是一个“字节管道”整套库的地基是把“底层怎么收发字节”抽象成一个接口。协议层只认这个接口永远不知道自己是在串口上、TCP 上还是在一段内存里/* 一个字节管道。串口 / TCP / 内存模拟都实现它就行。 */typedefstructtp_transport{void*ctx;int(*read)(void*ctx,uint8_t*buf,size_tlen,inttimeout_ms);int(*write)(void*ctx,constuint8_t*buf,size_tlen);void(*flush)(void*ctx);void(*close)(void*ctx);}tp_transport_t;就这么几行换来两个大好处以后加Modbus TCP协议帧逻辑一行不用改只写一个新的传输后端测试时塞一个内存里的假从站进去不用真设备就能把收发全流程跑通。设计二协议层只管“一帧”Modbus RTU 的一帧结构很朴素细节见上一篇拆解┌────────┬────────┬──────────────┬────────┬────────┐ │ 从站号 │ 功能码 │ 数据 │ CRC 低 │ CRC 高 │ │ 1 B │ 1 B │ N 字节 │ 1 B │ 1 B │ └────────┴────────┴──────────────┴────────┴────────┘校验用的是 CRC-16/MODBUS公开标准算法多项式0xA001uint16_tcrc16(constuint8_t*p,size_tn){uint16_tcrc0xFFFF;while(n--){crc^*p;for(inti0;i8;i)crc(crc1)?(crc1)^0xA001:crc1;}returncrc;}小验证对 ASCII 串123456789算出来应是0x4B37——这是 CRC-16/MODBUS 的标准校验值拿它当单元测试的“已知答案”很省心。协议层还做了一件对界面很有用的事每收发一帧就通过一个回调把原始字节抛给上层。上层想怎么显示HEX / ASCII、要不要记录都随意——这就是监视界面里“收发帧”那一栏的数据来源。设计三点位模型 后台线程再往上“寄存器地址 数据类型”被抽象成点位tag。你只描述“我要读哪个地址、当成什么类型”轮询之后值就自动填好typedefstruct{charname[32];tp_area_tarea;/* 线圈 / 保持寄存器 / 输入寄存器 … */uint16_taddress;tp_datatype_ttype;/* uint16 / int16 / float32 / bool … *//* ↓ 轮询后自动填充 */doublevalue;bool valid;}tp_tag_t;这一层还顺手做了两件事批量读把同一区域里地址连续的点位合并成一次Modbus 请求而不是一个点位发一帧——少一半以上的往返并发放在 C 库里轮询跑在一个后台线程上C11threads.h那套 API界面只去读一份线程安全的快照。于是就算某个从站不应答、读超时卡住界面照样丝滑不会连“断开”都点不动。值得一提的是并发没有塞进界面框架里——它在纯 C 层。这样哪天不用这个界面、换别的前端甚至做成命令行守护进程后台采集这套照样能用。配套一个工业风监视界面光有库不够直观所以配了个 Qt 写的监视器左边选协议右边配串口、列采集点位、看实时值支持不同数据类型显示底下是收发帧监视可在 HEX / ASCII 之间切。界面只依赖最上面的poll那层通过线程安全快照拿数据——它对底下协议一无所知以后加了新协议界面几乎不用动。反过来界面本身也是可换的。它只和纯 C 的poll层打交道所以 Qt 只是“其中一种前端”桌面 / 上位机拿 Qt 写省事而同一套 C 内核也能驱动一个 LVGL 写的界面直接跑在嵌入式 HMI、触摸屏上。正因为核心是纯 C、不背运行时这条“下沉到设备端”的路才走得通——这也是当初咬定纯 C 的原因之一。接下来这个系列会一个协议一篇往下写Modbus TCP复用现成的帧逻辑换个传输后端 MBAP 头西门子S7、三菱MC、欧姆龙FINS/Hostlink……界面也不只一种桌面 / 上位机继续用 Qt嵌入式 HMI 用LVGL两者共用同一套纯 C 内核——协议、驱动、后台采集一行都不用改。每加一层都会回来对照这张架构图看看——如果新协议逼着我改了地基那多半是当初某个抽象没做对。这也是我留着这套分层、公开写出来的原因之一架构是会被新需求反复拷问的。下一篇Modbus TCP。
本文首发于我的个人博客 talkplc.com同步发布于 CSDN。原文链接https://talkplc.com/2026/07/18/talkplc-architecture/上一篇把 Modbus 一帧报文逐字节拆开讲了。这一篇往上走一层与其每个项目都重写一遍 Modbus/西门子/三菱的收发不如把它做成一套能长期用、能跑嵌入式、还能给上位机绑定的库。这是这个系列的第一篇先把架构和取舍说清楚——协议实现的细节留给后面每一篇。项目代号talkplc。纯净室开发只依据公开协议规范个人时间与设备。为什么又要造一个通讯库工控现场的协议是一堆的Modbus RTU/TCP、西门子 S7、三菱 MC、欧姆龙 FINS/Hostlink、CODESYS…… 每接一个新设备、每起一个新项目都在重复写“打开串口 → 拼一帧 → 算校验 → 收一帧 → 解出寄存器”。已有的轮子里HslCommunication很成熟但主要面向 .NET。我想要的不太一样以 C 为核心能直接跑在嵌入式 Linux / 网关上不背运行时对外暴露干净的 C API方便再包一层给 C# / Python 做上位机模块解耦用哪层链哪层别一上来就拖一坨依赖。对我个人它同时是三样东西一个开源作品集、这个博客的选题引擎每实现一个协议写一篇以及一个长期想做下去的方向。一开始就定死的几条原则纯 C11 内核 干净 C API——最大可移植性绑定友好。传输与协议分离——协议层不关心底下是串口、TCP 还是内存模拟。每层单独成库、可单独链接——只想要 Modbus 帧逻辑那就只链协议模块不拖串口。没有硬件也能测——内置一个内存里的从站模拟帧逻辑不靠真设备就能验证。架构总览分层大概长这样依赖方向自上而下、绝不反向应用 / 上位机 / 绑定 (C#、Python…) │ ┌──────────▼──────────┐ │ gui Qt 监视界面 │ 可视化可选 └──────────┬──────────┘ ┌──────────▼──────────┐ │ poll 后台轮询线程 │ C11 线程对外只给“线程安全快照” └──────────┬──────────┘ ┌──────────▼──────────┐ │ driver 点位(tag)模型 │ 地址类型 → 值连续寄存器批量读 └───┬──────────────┬───┘ ┌───────▼──────┐ ┌─────▼──────────┐ │ modbus 协议 │ │ datatype 类型解码 │ └───────┬──────┘ └────────────────┘ ┌───────▼──────┐ │ serial 传输后端 │ 串口以后加 TCP └───────┬──────┘ ┌───────▼───────────────────────────┐ │ core 状态码 传输接口 收发帧回调 │ 人人依赖的地基 └───────────────────────────────────┘每层的职责模块干什么依赖core状态码、传输接口、收发帧回调trace—serial串口 I/OWindows / POSIX以后同法加 TCPcoremodbusModbus 帧的拼装 / 解析 / 校验不关心串口coredatatype寄存器 ↔ 数据类型u16/i16/u32/i32/f32/bool 字序—driver点位模型 轮询 批量读modbus, datatypepoll把驱动跑在后台线程上对外给线程安全快照drivergui工业风监视界面Qtpoll下面挑三个最关键的设计点讲讲——只讲思路代码点到为止。设计一传输层是一个“字节管道”整套库的地基是把“底层怎么收发字节”抽象成一个接口。协议层只认这个接口永远不知道自己是在串口上、TCP 上还是在一段内存里/* 一个字节管道。串口 / TCP / 内存模拟都实现它就行。 */typedefstructtp_transport{void*ctx;int(*read)(void*ctx,uint8_t*buf,size_tlen,inttimeout_ms);int(*write)(void*ctx,constuint8_t*buf,size_tlen);void(*flush)(void*ctx);void(*close)(void*ctx);}tp_transport_t;就这么几行换来两个大好处以后加Modbus TCP协议帧逻辑一行不用改只写一个新的传输后端测试时塞一个内存里的假从站进去不用真设备就能把收发全流程跑通。设计二协议层只管“一帧”Modbus RTU 的一帧结构很朴素细节见上一篇拆解┌────────┬────────┬──────────────┬────────┬────────┐ │ 从站号 │ 功能码 │ 数据 │ CRC 低 │ CRC 高 │ │ 1 B │ 1 B │ N 字节 │ 1 B │ 1 B │ └────────┴────────┴──────────────┴────────┴────────┘校验用的是 CRC-16/MODBUS公开标准算法多项式0xA001uint16_tcrc16(constuint8_t*p,size_tn){uint16_tcrc0xFFFF;while(n--){crc^*p;for(inti0;i8;i)crc(crc1)?(crc1)^0xA001:crc1;}returncrc;}小验证对 ASCII 串123456789算出来应是0x4B37——这是 CRC-16/MODBUS 的标准校验值拿它当单元测试的“已知答案”很省心。协议层还做了一件对界面很有用的事每收发一帧就通过一个回调把原始字节抛给上层。上层想怎么显示HEX / ASCII、要不要记录都随意——这就是监视界面里“收发帧”那一栏的数据来源。设计三点位模型 后台线程再往上“寄存器地址 数据类型”被抽象成点位tag。你只描述“我要读哪个地址、当成什么类型”轮询之后值就自动填好typedefstruct{charname[32];tp_area_tarea;/* 线圈 / 保持寄存器 / 输入寄存器 … */uint16_taddress;tp_datatype_ttype;/* uint16 / int16 / float32 / bool … *//* ↓ 轮询后自动填充 */doublevalue;bool valid;}tp_tag_t;这一层还顺手做了两件事批量读把同一区域里地址连续的点位合并成一次Modbus 请求而不是一个点位发一帧——少一半以上的往返并发放在 C 库里轮询跑在一个后台线程上C11threads.h那套 API界面只去读一份线程安全的快照。于是就算某个从站不应答、读超时卡住界面照样丝滑不会连“断开”都点不动。值得一提的是并发没有塞进界面框架里——它在纯 C 层。这样哪天不用这个界面、换别的前端甚至做成命令行守护进程后台采集这套照样能用。配套一个工业风监视界面光有库不够直观所以配了个 Qt 写的监视器左边选协议右边配串口、列采集点位、看实时值支持不同数据类型显示底下是收发帧监视可在 HEX / ASCII 之间切。界面只依赖最上面的poll那层通过线程安全快照拿数据——它对底下协议一无所知以后加了新协议界面几乎不用动。反过来界面本身也是可换的。它只和纯 C 的poll层打交道所以 Qt 只是“其中一种前端”桌面 / 上位机拿 Qt 写省事而同一套 C 内核也能驱动一个 LVGL 写的界面直接跑在嵌入式 HMI、触摸屏上。正因为核心是纯 C、不背运行时这条“下沉到设备端”的路才走得通——这也是当初咬定纯 C 的原因之一。接下来这个系列会一个协议一篇往下写Modbus TCP复用现成的帧逻辑换个传输后端 MBAP 头西门子S7、三菱MC、欧姆龙FINS/Hostlink……界面也不只一种桌面 / 上位机继续用 Qt嵌入式 HMI 用LVGL两者共用同一套纯 C 内核——协议、驱动、后台采集一行都不用改。每加一层都会回来对照这张架构图看看——如果新协议逼着我改了地基那多半是当初某个抽象没做对。这也是我留着这套分层、公开写出来的原因之一架构是会被新需求反复拷问的。下一篇Modbus TCP。
