In the world of embedded systems, automated testing, and industrial communication, there’s a pain we all share:
The same communication logic gets re-implemented again and again.
MCU bootloader upgrades? Write a PC tool.
Modbus testing? Another tool.
TCP console? One more.
Automated testers? Rewrite the whole thing.
The protocol never changes — only the execution context does. Yet we keep wasting time rewriting upper-layer tools.
I used to think this was normal.
Until I built this project:
ToolOfCOM
A runtime that reads YAML and executes communication protocol logic.
Write YAML, not code. That’s it.
🧠 Why Does ToolOfCOM Exist?
When debugging a device, we’re not really “using a serial port.” What we’re actually doing is:
Waiting for events
Parsing responses
Handling timeouts
Executing the next step
Managing multi-step protocol flows
In other words, every PC-side tool is a communication state machine.
Traditionally, we hard-code this logic in Python / C# / LabVIEW, which leads to the real problem:
One protocol → One PC tool
That’s where the duplication begins.
ToolOfCOM does one simple but transformative thing:
It turns communication logic into a YAML-based DSL
Protocols become Drivers
Channels become Communication endpoints
Execution becomes a state machine
Communication logic is no longer code.
It’s textual, reusable, versionable data.
🚀 ToolOfCOM in One Sentence
It’s a runtime engine for communication protocols that executes YAML as a state machine.
Compare the mindset shift:
Tool Type Mental Model
Traditional Tool “Click buttons + write logic”
ToolOfCOM “Write YAML = define execution”
It doesn’t replace existing tools.
It elevates them.
📐 Architecture — Minimal, Brutal, Effective
YAML DSL
↓ parser
ScriptAST
↓ executor
Runtime Engine
├─ ActionRegistry
├─ Protocol Drivers (XMODEM / Modbus RTU/ASCII/TCP / YMODEM)
└─ Channels (UART / TCP / Logging)
Decomposed into human terms:
YAML = Communication description language
Parser = Converts YAML → AST
Runtime Engine = State-machine executor
Actions = Actual tasks
Drivers = Protocol stacks
Channels = UART/TCP abstractions
Protocol, channel, and logic are fully decoupled.
🧾 This YAML Is Not Configuration — It’s Code
A real executable script:
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" ] }
This is not a config file.
This is executable communication logic.
🔁 How Does It Run?
The full pipeline looks like this:
toolofcom run upgrade.yaml
→ Parse YAML → Build state machine → Initialize UART/TCP channels
→ Register actions/protocol drivers
→ Execute instructions → Listen for events/timeout
→ State transitions → TX/RX → Repeat
→ done
Execution logs show every transition:
[STATE] wait_C
waiting for handshake...
[STATE] send_block
[STATE] next_block
...
Completed
Enable the LoggingChannel and you get full TX/RX traces — perfect for automated testing and protocol verification.
⚡ Why This Matters
It changes how communication logic is produced:
Perspective Before ToolOfCOM
Protocol changes Modify code Modify YAML
Test engineers Learn coding Learn states
Collaboration Ship tools Ship scripts
Protocol as asset ❌ No ✔ Yes
And the real breakthrough:
The same YAML runs across different channels (Serial/TCP/etc.)
For the first time, protocol logic becomes transport-agnostic.
🔥 Real-World Applications
ToolOfCOM already supports:
Feature Status
XMODEM upgrade pipeline ✔ MCU bootloader testing powerhouse
Modbus RTU/ASCII/TCP ✔ Field-ready for industrial use
Mixed UART/TCP channels ✔ Hot-swappable execution paths
State-driven automation ✔ No code required
Extensible protocol stack ✔ Inherit BaseProtocol, add behavior
You can now share and reuse protocols like source code.
For the first time, protocols become assets.
🧭 The Future (This Is the Real Paradigm Shift)
ToolOfCOM opens a door:
Protocols are no longer part of programs.
Protocols are the programs.
From now on:
Firmware upgrades are YAML
Device debugging is YAML
Automated testing is YAML
Engineering hand-off is YAML
No one will ever ask again:
“Do you have a PC tool for this protocol?”
The answer becomes:
Give me the YAML. I’ll run it.
🏁 Final Words
I didn’t build this to make another serial tool.
I built it to offer engineers a new mental model:
Communication is not commands. It is a process.
Processes shouldn’t be hard-coded; they should be described, shared, and executed.
ToolOfCOM makes that real.
📎 Open Source Repository
👉 https://github.com/11cookies11/ToolOfCom.git
End 🚀
Top comments (0)