我做了一个用 YAML 来驱动串口/TCP 协议执行的框架，上位机从此不需要写代码了

在嵌入式开发、自动化测试、工控联调的世界里，有一个永恒的痛点：

同一套通信逻辑，会在不同的工具里被反复实现。

MCU Bootloader 升级要写一套上位机
Modbus 调试又写一套
TCP 控制台再来一套
测试平台脚本还要重写一遍

协议没有变，只是执行方式换了，人却一直在重复劳动。

我曾经以为这是正常的，直到我写出了这个项目：

复制代码

ToolOfCOM

一个能"读懂 YAML 并执行通信协议逻辑"的运行时系统。你不再需要写上位机，写一份 YAML 就够了。

🧠 为什么会有 ToolOfCOM？

我们真正想调试的不是"串口"，而是：

等待某个事件
判断回包内容
超时处理
执行下一条命令
协议升级连续行为

也就是说，上位机是一台通信状态机。

以前我们把状态机硬编码在 Python / C# / LabVIEW 里，所以：

每换一个协议，也就换了一套上位机。

这是重复劳动的根源。

我在 ToolOfCOM 里做了一件简单却颠覆性的事：

把通信过程抽象成 YAML DSL

协议只是 Driver 通信只是 Channel 执行过程由状态机解释

于是通信逻辑从此变成了文本资产。

🚀 用一句话理解 ToolOfCOM

它是通信协议的运行时引擎， 把上位机变成可执行的 YAML 状态机。

和串口助手等工具的区别在这里：

工具类型	思维模式
传统上位机	"点按钮 + 写逻辑 + 调代码"
ToolOfCOM	"写 YAML = 定义协议执行链"

不是替代，而是升维。

📐 架构长这样（极简但有杀伤力）

scss 复制代码

YAML DSL
  ↓ parser
ScriptAST
  ↓ executor
Runtime Engine
  ├─ ActionRegistry
  ├─ Protocol Drivers (XMODEM / Modbus RTU/ASCII/TCP / YMODEM)
  └─ Channels (UART / TCP / Logging)

一句话拆解：

YAML = 通信描述语言
Parser = 把 YAML 变成 AST
Runtime Engine = 状态机执行器
Actions = 具体动作
Drivers = 协议栈
Channels = 串口/TCP 抽象层

协议、通道、逻辑三者彻底解耦。

🧾 看看它的 YAML（比 Python 还顺眼）

这是一个真的可以执行的脚本：

yaml 复制代码

version: 1
vars: { block: 1, file_path: ./firmware.bin }

channels:
  boot: { type: uart, device: COM5, baudrate: 115200 }

state_machine:
  initial: wait_C
  states:
    wait_C:
      on_event: { "C": send_block }
      timeout: 5000
      on_timeout: fail

    send_block:
      do:
        - action: send_xmodem_block
          args: { block: "$block" }
      on_event: { ACK: next_block, NAK: send_block }
      timeout: 2000
      on_timeout: fail

    next_block:
      do: [ - set: { block: "$block + 1" } ]
      when: "$block <= file.block_count"
      goto: send_block
      else_goto: send_eot

    send_eot:
      do: [ - action: send_eot ]
      on_event: { ACK: done }

    done: { do: [ - log: "Completed" ] }

这不是配置文件。

这是一段可执行的通信流程代码。

🔁 它是怎么跑起来的？

完整链路如下：

arduino 复制代码

toolofcom run upgrade.yaml
→ 解析 YAML → 构建状态机 → 创建 UART/TCP 通道
→ 注册动作/协议驱动
→ 执行 do 指令 → 监听事件/超时
→ 状态跳转 → 发送/收包 → 循环执行
→ done

执行日志会呈现每一次状态跳转：

csharp 复制代码

[STATE] wait_C
waiting for handshake...
[STATE] send_block
[STATE] next_block
...
Completed

如果启用 LoggingChannel，还能把所有 TX/RX 帧写入日志文件------非常适合自动化测试与协议验证。

⚡ 为什么这件事意义重大？

因为它改变了通信逻辑的生产方式：

视角	过去	ToolOfCOM
协议演进成本	改代码	改 YAML
测试人员	学脚本	学状态机
工程协作	发工具	发脚本
协议资产化	不存在	✔ 实现

更关键的是：

同一份 YAML 可以在串口、TCP 等不同通道运行

协议逻辑第一次实现跨介质复用。

🔥 现实用途是什么？

ToolOfCOM 已经支持：

功能	状态
XMODEM 升级链路	✔ MCU Bootloader 测试神器
Modbus RTU/ASCII/TCP	✔ 工控现场直接用
串口/TCP 混合通道	✔ 可切换运行
状态机驱动自动化测试	✔ 无需写代码
协议动作扩展	✔ 继承 BaseProtocol 即可增加协议

你甚至可以把某个协议的执行逻辑提交到仓库里复用。

协议第一次变成可以共享的资产。

🧭 它的未来（这是整个故事的升维点）

ToolOfCOM 正在打开一个可能性：

复制代码

协议不再是程序的一部分，
协议本身就是一段可以执行的脚本。

从此以后：

产品升级是 YAML
设备调试是 YAML
自动化测试是 YAML
工程交付也是 YAML

再也不会有人问：

"有没有这个协议的上位机？"

因为回答将变成：

复制代码

给我 YAML，我来跑。

🏁 写在最后

我做这个项目，不是为了做一个更好看的串口助手。

而是为了给工程师一个新的视角：

通信不是命令，通信是流程。 流程不该写死在代码里，它应该被描述、复用、执行。

ToolOfCOM 让这件事真正发生了。

📎 项目开源地址

👉 评论区可见

🌟 如果这篇文章改变了你对"通信逻辑"的理解，

请点个赞、关注我，下一篇我会继续揭开：

协议即资产，未来的工程协作会是什么样？

全文完 🚀