HACKER Q&A
📣 halfmatthalfcat

Why does STM32 (or embedded generally) development suck?


I'm getting into embedded development. Got me a STM32F3Discovery (recommended by Embedded Rust). Started going down the embedded rust rabbit hole before I got tired of the complexity (though do like the idea of Embassy), wanted to look for something simpler.

Started looking into embedded Zig. Looks promising but still not there, not a ton of hardware support yet.

Allergic to getting close to C++ due to all it's baggage, decide to start getting into C. Learning C was easy so started to look into getting my stuff onto a chip, again using the Discovery as my base board.

Have a slew of IDE choices, STM32CubeMX, Keil uV, various VSCode extensions. All of them are quite complex and when you get them working, they lay down A TON of files that seem somewhat irrelevant (and noisy) to creating simple programs.

The HALs are confusing so want to just leverage CMSIS and bit bang my way to greatness. ARM has system CMSIS but vendors have vendor-specific CMSIS, so (finding them) and piecing them together sucks.

Oh then you need linkers and startup scripts, where are those? Again, vendor specific that the CubeMX or uV basically pull from STM32's Github org. That org btw, tons of repos of stuff that isn't super obvious what is what, what should be used with what, etc.

Now you have what you need but you need to then flash the chip, again a couple different ways to do this.

I just want a utility that plunks down the necessary CMSIS, linker and startup so I can get my base level bearing and actually do development...why is there so much noise and cruft everywhere?

  👤 the__alchemist Accepted Answer ✓
The main official tools I use:

  - Stm32CubeIDE: Graphical IDE, sort of, that shows you how to configure the peripherals. I mainly use it to get clock scalers and linker config, but you can use it to configure all peripherals. Note that the linker config is straightforward for most STM32s, but is messier on H5 and H7.
  - Stm32CubeProgrammer: Flashing for production use, e.g. in DFU mode
I've been using Rust tools for everything else. I had to built a lot of tooling along the way (HAL and interaction with specific peripherals), but it was worth it. There's some boilerplate, but it's not too bad.

The PAC team has done a great job smoothing over errors in ST's IDE. The Knurling team behind `defmt`, and the probe-rs team have also be integral to this being a smooth experience. I'd go as far as saying this is one of rust's core strengths. (Easy builds and in embedded constext, flashing/debugging)

The workflow to build and flash with debugging is: `cargo run --release`.

👤 steveklabnik
Hardware companies care about hardware, not software. Simple as that.

You’ve picked one of the better ones, even. It’s only downhill from here.

👤 npalli
You should try PlatformIO. It solves exactly the problem (last line) for known boards. I did some hobby work but your mileage might vary. Caution that it is C++ first platform (rather than C), so if you are having allergic reaction* might try some other toolkits.

*Given you initially chose Rust for this, I would have tagged you as someone who is into vibes/feeling good rather than getting things done, and the suggestion would have been wasted on you, but you seem to have learned your lesson so rather than dismiss C++ out of hand, take a look.

👤 actionfromafar
You can use Zig in a less ambitious way, by using the regular C or C++ interface for the SDK, but your own Zig code for the rest.
👤 sinenomine
TLDR: the whole embedded dev is a cost center, very underfunded compared to normal SWE. I say it from position of compassionate interest.