If you’ve been reading this blog for a while, you know I’ve spent a good part of the last 15 years writing tutorials on how to set up Eclipse CDT for embedded development.
OpenOCD configuration.
GCC toolchain paths.
Makefiles that almost work.
J-Link vs ST-Link quirks.
Getting the debugger to halt at main() instead of running off into the void.
The irony is that for many embedded projects, the hardest part isn’t the firmware.
It’s the toolchain.
You want to bring up a new nRF52 or STM32 board.
Instead, you spend hours (or days) installing toolchains, fixing environment variables, aligning SDK versions, and debugging your debugger.
I’ve repeated the same setup process enough times that I finally decided to automate it properly.
That’s how IOcomposer started.
The Goal
From a clean OS install to hitting a breakpoint in under 15 minutes.
Not an Arduino-style abstraction layer.
Not a cloud IDE.
A full professional embedded workflow:
GCC toolchains (ARM & RISC-V)
OpenOCD integration
Real JTAG debugging
Eclipse CDT
Bare-metal or lightweight framework development
But without the manual wrangling.
What IOcomposer Actually Is
IOcomposer is a standalone IDE built on Eclipse Embedded CDT, pre-integrated with:
xPack GCC toolchains (ARM & RISC-V)
OpenOCD & QEMU
Nordic nRF5 SDK (ready to build)
The IOsonata framework (multi-architecture firmware layer)
You install it.
You open it.
You build.
You debug.
No chasing paths. No manual plugin setup.
If you’ve followed my previous Eclipse tutorials, think of this as those guides — baked into the tool.
Why Add an AI Assistant?
This is where I hesitated before writing this post.
There are already generic AI coding tools. Most of them are good at C++ syntax. Most of them are not good at embedded systems.
The assistant in IOcomposer is different in one important way:
It has access to the full project structure — including macro definitions, board configuration, and linker setup.
That allows it to reason about embedded configuration problems, not just generate code.
A simple example:
 |
| Add SPI and wrong pin order detected |
board.h that conflicts with the SDK, it can flag the inconsistency and suggest the missing definitions.If a build fails, it analyzes the console output and suggests the specific include, flag, or configuration change that caused the failure.
It doesn’t replace debugging.
But it can shorten the “why is this failing?” phase.
Debugging Still Matters
The “Debug” button launches a fully configured OpenOCD session with:
Breakpoints
Live variable watch
Peripheral register view
Memory monitor
Disassembly view
This isn’t meant to abstract away embedded development.
It’s meant to remove the setup friction so you can focus on the firmware.
Who This Is (and Isn’t) For
If you’re happy with Arduino and don’t need JTAG debugging, this is probably unnecessary.
If your company standardizes on Zephyr and that workflow works for you, stick with it.
But if you prefer:
Bare-metal or lightweight firmware
Full debugger control
A professional desktop IDE
Without spending a weekend configuring it
Then IOcomposer might be worth trying.
Public Preview
This is an early public preview.
It runs on Windows, Linux, and macOS.
The core IDE and debugging features are free.
Paid tiers are only for higher AI usage.
You can download it here:
If you try it, I’d genuinely appreciate feedback:
Does the install work on your distro?
Does debugging connect reliably to your hardware?
Where does it break?
What feels unnecessary?
After writing setup guides for 12 years, I’m curious whether this actually solves the problem — or if I’ve just automated my own habits.
Let me know in the comments.
—
