A Late Spring for Embedded Tools — Four Signals from Dissecting STM32CubeMX2

I mostly build software, but my interests sprawl a bit. Firmware, communication protocols, batteries, cars, chips — I always keep one foot in the world that touches hardware. And these areas have one thing in common: technology adoption is slow. Tools or ways of thinking that became obvious in general SW five years ago take another five years to migrate over to the hardware side.

So I've always wondered: when does this gap actually close? In a moment like now, when AI is simultaneously accelerating tech adoption across every field, when does this slow neighborhood finally join the flow?

Over the past few days I dissected the macOS 1.0.0 build of STM32CubeMX2 — STMicroelectronics's next-generation STM32 configuration tool — disk-by-disk. About 839 MB across 5,628 files. The way the whole thing unpacks not into /Applications but under ~/Library/Application Support/STMicroelectronics/ already felt unfamiliar. The deeper I looked, the more "oh, this finally arrived in this neighborhood too" signals I kept finding.

Four of them, to be exact.

Signal 1 — They tore out NetBeans/Swing and rebuilt the UI on Theia/Electron

Classic STM32CubeMX sat on NetBeans + Java Swing. The kind of stack where the phrase "Java desktop GUI" tells you everything you need to know about its era. The screen where you drag a clock tree around with a mouse hadn't really changed since the early 2010s.

CubeMX2 rips out that foundation entirely. It's an IDE wrapped as Electron on top of Eclipse Theia. Theia is family with VS Code — same Monaco editor, same plugin API, same keybinding model. The package.json's theia.target is literally set to "electron". ST split its own functionality into Theia extensions under a @prg-cube/* namespace. Pinout, clock tree, DMA, NVIC, EXTI, middleware, HW platform composition — each is an independent module with its own semver.

None of this is a new story in the general SW world. VS Code came out in 2015, Theia has been public since 2017. But ST is one of the first embedded vendors to put their flagship tool on top of it. It took roughly a decade for the shape of the tool to catch up with the times.

Signal 2 — They handed the build system off to standards

This was the more meaningful signal. Classic CubeMX spat out its own Makefile. The build, the compiler abstraction, the dependencies — all of it sat on top of macros ST had written by hand.

CubeMX2 doesn't do this. The cube mx ide-project generate --format command has three options.

--format <CMake | EWARM | Open-CMSIS>

ST no longer builds. It only owns configuration and code generation, and exports the result into one of three standard formats. Export as CMake and it plugs straight into VS Code/CLion. Export as EWARM and it opens in the IAR IDE. Export as Open-CMSIS and you get a csolution.yml + cproject.yml + clayer.yml set that builds with cbuild.

And what's bundled inside is a vanilla bundle of Open-CMSIS-Toolbox 2.11.0 binaries — csolution, cbuild, cpackget, svdconv. The interesting bit is that the bin/ directory also contains launch-MCUXpressoConfigTools (NXP) and launch-Infineon_Dev_Config (Infineon). ST is building its tool while thinking not just about its own MCUs, but about cross-vendor integration.

Locking users into your own build system is a short-term win for the vendor. ST voluntarily releasing that lock and moving onto a standard means they're drawing a picture where, in the long term, the STM32 ecosystem must be able to run on the same build pipeline as other Cortex-M vendors. Decisions like this are common in the general SW world — there's no shortage of cases where someone abandoned their proprietary build tool and joined the standard. But for an embedded vendor to do this is a sign that the neighborhood mood is shifting.

Signal 3 — They treat data like packages

Personally, this is the part I liked most. Open cube-dcm.json (presumably "dependency/capability matrix") inside the CubeMX2 application body and you'll find something like this.

{
  "dependencies": {
    "descriptors": {
      "pinout":      { "compatibleWith": ">=1.0.0 <2.0.0-0" },
      "peripherals": { "compatibleWith": ">=1.3.0 <2.0.0-0", "developedWith": "1.3.0" },
      "DMA":         { "compatibleWith": ">=1.1.0 <2.0.0-0" },
      "middlewares": { "compatibleWith": ">=1.0.0 <2.0.0-0" },
      "bom-pcb":     { "compatibleWith": ">=1.0.0 <2.0.0-0" },
      "netlist":     { "compatibleWith": ">=1.0.0 <2.0.0-0" }
    }
  }
}

ST sliced device data into descriptor units, and pinned a semver compatibility range to each descriptor. The pinout model, the peripherals model, the DMA model — even board-level data like PCB/BoM/netlist — each carries its own independent version. Which descriptor major a given tool will accept is defined as a matrix. Data, models, and schemas are versioned like code — or more precisely, like npm packages.

The same thinking runs through the whole tool. Inside the bundles/ directory, every external tool sits in its own version folder — node/22.22.0+st.1, open-cmsis-toolbox/2.11.0+st.1, codegen/8.29.3, conversion-manager/0.2.13. The cube CLI can force a specific bundle version with --with <bundle@version>. The whole thing is built so you can use it for regression debugging or A/B experiments as-is.

On top of that, the data model has expanded from chip to board. Classic CubeMX focused on the pin mapping, clock, and peripherals of a single MCU. CubeMX2 treats PCB, BoM, netlist, connectors, and interconnections as first-class citizens — there's even a dedicated module called @prg-cube/stm32-cube-hw-platform-composition-feature. The center of gravity is shifting from a single-MCU configurator toward an HW platform composer.

Seeing npm/Cargo-style dependency thinking sitting inside a hardware vendor's tool was a little surreal. And the fact that they apply the same approach all the way down to board-level data left me with the feeling that there's a bigger picture here.

Signal 4 — Automation is a first-class citizen

The last signal, and the clearest one. Every GUI action is exposed 1:1 to the cube mx ... CLI. Pin assignment, clock setup, DMA configuration, peripheral activation, board search, pack install, build export — all of it. And nearly every subcommand carries --port/--host options.

Which means MX is actually an HTTP backend server, and both the GUI and the CLI are clients attaching to that server. Run cube mx start to bring up the backend, and a shell script can do everything. The GUI and the CLI can attach to the same backend simultaneously, so a workflow where you visually verify a CI-built configuration in the GUI feels natural.

This is not the shape of a tool where the GUI was built first and the CLI was bolted on later. It's the shape of a tool that was designed with automation in mind from day one, with the GUI laid on top. This separation is familiar in the general SW world, but I've never seen an embedded vendor tool designed this way. (I have more to say about this part, so I'll unpack it in a separate post.)

So why is this interesting

Look at these four signals individually and the story is just "ST built a nice new tool." Stack them together and a pattern emerges.

The embedded / hardware tooling space is finally starting to join the general SW way of thinking. Electron-based IDE, delegating builds to standards, package-manager-style dependency management, equal GUI/CLI separation — these four have been gradually becoming default in general SW for the last decade. The fact that they all show up in a single tool at once means the gap that's been accumulating is closing all at once.

Why now? I have two guesses.

First, the demographic mix of embedded developers has changed. Next to the generation that's used to dragging a clock tree around in a Java Swing GUI, a new generation has joined — one that collaborates over git in VS Code and puts everything on CI. When the latter becomes the majority, the tools follow. Talking to friends in firmware and automotive, in the last five years that ratio has noticeably tilted.

Second, the AI era is changing the very axes by which tools are evaluated. For an AI agent to operate a tool on behalf of a human, the tool can't be hiding behind a GUI. Automation has to be a first-class citizen, every action has to be exposed via CLI or API, and outputs have to be in standard formats. A tool built with this in mind is instantly distinguishable from one built without it. CubeMX2 is clearly on the "with" side.

When the gap closes

What I've always been curious about is the exact moment when a new paradigm arrives in these slow neighborhoods. Automotive, batteries, industrial firmware, communications equipment — when in these areas would tools and workflows finally catch up with general SW?

What dissecting CubeMX2 left me thinking is that the moment may be closer than I'd assumed. And once it arrives, the speed at which AI enters this space accelerates in proportion to the shape of the tools. When chip vendor tools behave like package managers, the build is standard, and every action is exposed via CLI, putting an agent on top is no longer science fiction. The tool first becomes that shape, and then the agent follows — that feels like the right order.

After ST does this, a second and a third vendor will surely follow. And it's only a matter of time before the same flow spreads into the development tools of automotive, battery, and IoT. As someone who's always been curious about the half-beat-slower spaces like hardware and firmware, the signal that STM32CubeMX2 1.0.0 sent felt genuinely welcome. It feels like the long-awaited spring has finally arrived in the neighborhood.