STM Configurator

01 · The Problem

Standing up firmware for a new board is death by a thousand clicks. Every time I wanted to try something on a Nucleo, I was back in the same ritual: click through a graphical config tool, hand-wire peripherals, untangle pin conflicts by eye, generate code, set up the build, flash.

The slowest part of embedded was never the engineering. It was the setup. And pin conflicts tend to surface late, often not until a failed bring-up on the bench.

02 · The Solution

Two halves:

• The console: a single-page React app with peripherals and sensors in collapsible banks (connectivity, analog, timers and PWM, sensors, expansion, firmware base), a live H755 pin map showing used, free and conflicting pins, and a build panel.
• The engine: a FastAPI service with WebSocket build logs, running on an NVIDIA Jetson in the lab.

The pipeline: toggle → validate pins → generate HAL → compile → stream log → .bin.

03 · The Workflow

1. Select: toggle the peripherals and sensors I want.
2. Check: conflicts are flagged live, pin by pin.
3. Generate: HAL init code per peripheral, plus main.c.
4. Build: arm-none-eabi-gcc against the STM32CubeH7 HAL, with the log streaming live.
5. Flash: the image lands on a USB drive, and STM32CubeProgrammer does the flashing.

04 · The Hook — Conflicts at Config Time

The moment two peripherals fight over the same pin, that pin lights red, the offending peripherals flag, and the build button locks until I clear it.

Conflicts aren’t guessed at compile time. Every claimed pin is checked against a ground-truth table of the board, so they’re known the instant two peripherals claim the same pin.

FIG 1 · Two peripherals want PA0. The pin goes red, the conflict count goes to 1, and the build locks.

05 · What Saves Time

• No clicking through pin views: the pin map is the source of truth, and it updates as I toggle.
• Docs in reach: reference documents are full-text searchable from inside the tool, not in another window.
• Watching the build: the compiler log streams over a WebSocket as it runs.

06 · The Result — Honestly

What works: conflict detection and the build lock, HAL code generation, the streamed compile pipeline for the H755 (CM7 core), and local doc search.

What it isn’t yet:

• One board: the pin table covers the NUCLEO-H755ZI-Q, hand-entered.
• No live fetching: it doesn’t pull packages or pin data from ST on its own. That’s the big piece of future work.
• Builds aren’t board-proven: the build path is a prototype; the M4 core isn’t built, and images haven’t been verified on hardware.

It’s a working prototype that already changed how I start a board. The goal was never to replace ST’s tools. It was to remove the friction between having an idea and watching it run on real hardware.

07 · Future Work

• Real auto-fetch: type a part number and pull its pin data and docs.
• More boards: starting with the STM32N6.
• One-click flash: STM32CubeProgrammer inside the tool.
• Snapshots and diffs: versioned configs, and exactly which pins and init code changed between two.

One screen between an idea and a flashed board.

← R&D Log