[rurban]

I write baremetal fw for those chips. No debugger, extremely bad stdlib which I rewrote, no qemu. Horrible modem interface. But still much more pleasent than Linux FW or raspi's.

They are cheap, last 10 years with a single battery, and do only what they need to do. Also secure. No crazy attack vectors. And easily symbolically verifiable. And I wrote tons of simulators and fuzzers for them.

[DoingIsLearning]

Let me flip this around, I am looking for ways to improve testing, specially now that I am mostly remote. In your experience, what targets have a stress-free experience with qemu emulation?

[rurban]

Working on it in my github rurban/qemu-stm32 fork. Checkout supported platforms for qemu and better renode. There you also have debugging interfaces.

Stressfree qemu support was only for my even smaller avr targets, the 1281. But AVR is crazy compared to the Cortex-M4. We switched to arm completely, no avr's anymore. Anyway, no need for qemu or other emulators, when you can easily write simulators. You just throw in some mmaps, the simulated libc, the UART, and networking. Much better than emulators.

[patricktlo]

Your simulations sound super interesting, I'd love to read more if you're willing to write about it!

[jononor]

Not the parent, but I wrote a little bit about this here: https://www.jonnor.com/2017/03/host-based-simulation-for-emb...

The key thing is to make the majority of the code portable enough to run on a PC. I find the best way to do that is to keep things data-oriented, using Plain Old Data type data structures and pure functions as much as possible. Alternative view: isolate out any device-specific pieces, like I/O into as small and simple pieces as possible. When one takes this mindset one realizes that even things that are considered as "device specific", like device drivers usually have a lot of logic that can actually be separate from the I/O. And by having a swappable I/O backend (say for I2C) one can actually test the vast majority of this logic on a computer. One should also have an implementation of the Hardware Abstraction Layer (HAL) that is "host", allowing to run on a PC, potentially with virtual inputs and outputs. This allows to run essentially all of the firmware on a PC. If one uses a embedded-friendly test framework, like Unity, then one can also run the same tests that is used on the PC on the device - to make sure that there is no difference when ran on host vs device.

Unfortunately, the code from embedded device vendors is rarely amenable to this, so that code can end up as "untestable" under this scheme. For them portability" is only considered between their own hardware devices, not to a computer. Then one has to trust that they have done their own QA. Which is usually not that great - looking at you ST HAL....

[patricktlo]

That's a great article, thanks for pointing me to it :)