Forem: 11cookies11

VSCode + Renode: Building a Modern Embedded Simulation Workflow

11cookies11 — Wed, 10 Dec 2025 05:47:52 +0000

In traditional embedded development, we usually rely on physical development boards, hardware debuggers (ST-Link/J-Link), various drivers, and heavyweight IDEs such as IAR or Keil. This setup not only makes the environment cumbersome to configure, but also limits testing capabilities due to hardware availability, physical conditions, and debugging risks.

With the maturity of Renode (from Antmicro), we can finally:

Use VSCode + GCC for a lightweight, modern development experience

Use Renode to simulate CPUs and peripherals

Use GDB Server to debug firmware remotely

Even run Renode on a server (Raspberry Pi / Orange Pi) and access it from anywhere

Over the past few days, I built a complete workflow from VSCode → Renode → GDB, solved a series of pitfalls, and documented everything — configurations, scripts, common errors, and fixes.

📌 1. Why Renode + VSCode?

Modern embedded development is shifting away from:

❌ IAR + physical board + hardware programmer + serial cables
❌ Breakpoints and stepping limited to physical devices
❌ Reinstalling toolchains when switching MCU families

Towards:

✔ VSCode + GCC — lightweight, modern, cross-platform
✔ Renode — full simulation of STM32 / ESP32 devices, including UART, SPI, I2C, GPIO, DMA
✔ GDB Remote Debugging — platform-agnostic, can debug over network
✔ Automation-ready — suitable for CI/CD and reproducible testing

This workflow is very common in international companies because:

It dramatically improves development efficiency

Enables automated testing

Allows CI pipelines to run MCU simulations

Reduces dependency on hardware

However, it is still uncommon in domestic environments, so I created this article to serve as a practical guide.

Steps

Install Renode

Configure Renode (write .resc script)

Configure VSCode (.vscode/tasks.json / .vscode/launch.json)

Verify end-to-end debugging

Goals

Write code that interacts with Renode-simulated peripherals

Use VSCode + Renode for full-featured debugging workflows

📌 2. Installing Renode

Renode provides multiple binary distributions — choose any that works for your platform:

Repository:
https://github.com/renode/renode

My choice:

renode-latest.linux-portable-dotnet.tar.gz

Reasons:

Bundles its own .NET runtime

Does not require system-installed dotnet/mono

Runs on OrangePi / Raspberry Pi directly

Extract and launch:

./renode

📌 3. Renode Configuration

Create a minimal Renode .resc script (example for STM32F103).
This file describes the MCU configuration Renode simulates — peripherals, firmware, and debug setup.

A working version:

using sysbus

mach create "stm32f103"
machine LoadPlatformDescription @platforms/cpus/stm32f103.repl

Load ELF from OrangePi

machine LoadELF @/home/orangepi/object/renode_portable/firmware.elf

Enable UART2 analyzer

showAnalyzer sysbus.usart2

Start GDB server on port 3333 for VSCode debugging

machine StartGdbServer 3333 true

start

Save it as:

run_stm32.resc

📌 4. VSCode Debug Configuration

The key part is setting up launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Debug STM32F103 on Renode Remote",
"type": "cppdbg",
"request": "launch",

        "program": "${workspaceFolder}/build/firmware.elf",
        "cwd": "${workspaceFolder}",

        "miDebuggerPath": "arm-none-eabi-gdb",
        "miDebuggerServerAddress": "xxx.xxx.xxx.xxx:3333",

        "preLaunchTask": "Run Renode Remote",
        "stopAtEntry": true,

        "setupCommands": [
            { "text": "set pagination off" },
            { "text": "set confirm off" },
            { "text": "set print pretty on" }
        ],

        "postRemoteConnectCommands": [
            { "text": "monitor machine Pause" },
            { "text": "monitor sysbus LoadELF @/home/orangepi/object/renode_portable/firmware.elf" },
            { "text": "monitor cpu Reset" }
        ],

        "externalConsole": false,
        "targetArchitecture": "arm"
    }
]

}

Core parameters:

miDebuggerPath → Local GDB executable
miDebuggerServerAddress → Remote Renode GDB endpoint

And:

"preLaunchTask": "Run Renode Remote"

VSCode automatically starts Renode on the remote board before debugging.

The post-connect sequence:

Pause simulation

Reload the ELF from the remote paths

Reset CPU and sync execution state

This mirrors what you'd normally do manually.

tasks.json

Required build + upload + execution pipeline:

{
"version": "2.0.0",
"tasks": [
{
"label": "CMake Configure",
"type": "shell",
"command": "cmake",
"args": [
"-S", "${workspaceFolder}",
"-B", "${workspaceFolder}/build",
"-DCMAKE_BUILD_TYPE=Debug"
]
},
{
"label": "CMake Build",
"type": "shell",
"command": "cmake",
"args": [
"--build", "${workspaceFolder}/build",
"--config", "Debug"
],
"dependsOn": ["CMake Configure"]
},
...
]
}

This pipeline uploads ELF and .resc to the remote machine, restarts Renode, and attaches GDB automatically.

Testing

Once configured, press F5 in VSCode:

Renode boots remotely

Firmware loads automatically

UART output and breakpoints work as expected

I Built a Runtime Framework That Executes Serial/TCP Protocols from YAML — No More Upper-PC Coding

11cookies11 — Tue, 09 Dec 2025 14:22:51 +0000

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 🚀