Hi HN,

I’ve been building IOcomposer (https://iocomposer.io), a free Eclipse-based IDE and optional AI assistant for embedded C++ development.

Try it (one-script install): https://iocomposer.io (macOS/Linux/Windows install commands are on the landing page. If you don’t like curl|bash, download the script, read it, then run it locally.)

Context (using nRF54 as the example): if you’re coming from years of nRF52 / nRF5-SDK bare-metal C/C++, moving to nRF54 often pushes you into nRF Connect SDK + the Zephyr config/tooling stack (West/CMake/Kconfig/Devicetree). For many teams that’s a workflow + architecture rewrite. IOcomposer targets the “keep writing firmware” path.

What IOcomposer does: - MCU-centric project setup: wizard generates an Eclipse CDT managed project (build + toolchain + debug config). Boards are typically just pin maps (board.h). No Devicetree/Kconfig required. - Build/flash/debug from the IDE: Eclipse Embedded CDT managed build with 1-click JTAG/SWD debugging. No external build-system glue. - Optional AI: indexes installed vendor headers + the underlying HAL so suggestions match real APIs (not generic C++). Outputs patch-style edits; core IDE works without AI.

3-minute unedited demo (prompt → BLE peripheral project → compiles + debugs on real hardware): https://youtu.be/LR2vYtMeC8A

Targets: Validated (builds + runs baseline examples on hardware): nRF52, nRF54L15, STM32 baseline. Experimental: nRF53, nRF91, nRF54H20, additional STM32 families. Underlying framework (for the curious): https://github.com/IOsonata/IOsonata

The ask: IOcomposer is early beta. Where does this workflow break for your use case? Where does the AI help vs. become noise?

Happy to answer questions about build/debug integration, the AI layer, or why I chose Eclipse over VS Code.

— Hoan