fota.systems

MCU or Linux? They are different problems

The same words describe two jobs with almost nothing in common.

On embedded Linux you have gigabytes, a real bootloader, a filesystem and usually mains power or a decent battery. Keeping two copies of the system is affordable, so A/B with rollback is the standard answer. On a microcontroller you may have a few hundred kilobytes of flash, a battery that must last years, and a radio link that drops. The update must be small, resumable and safe to interrupt at any instant.

This is why the tooling split. Mender, balena, Foundries and Torizon assume Linux. Golioth, Memfault and ESP RainMaker assume constrained devices and a bootloader such as MCUboot doing the swap. hawkBit and AWS sit above both because they only move artifacts and never touch the device side.

Top picks

1Linux OTAEmbedded Linux

MMender

Linux side: the A/B model that made rollback ordinary.

2MCU cloudMCU (Zephyr-first)

GGolioth

MCU side: Zephyr-native, priced per connection and per megabyte.

3MCU observability + OTAMCU + embedded Linux

MMemfault

MCU side, when the important question is why a device crashed.

4Vendor platformESP32 family

EESP RainMaker

MCU side, if the silicon is ESP32 and you want the whole stack from one vendor.

5OSS update serverAny (device-agnostic)

EEclipse hawkBit

Above both: an artifact and rollout server that does not care what the device is.

Bottom line

If a comparison does not tell you which of these two worlds it is describing, it is not describing either of them carefully.

Want a second opinion on the shortlist?

Tell us the target hardware, roughly how many devices, and what happens commercially if one bricks. You get back a shortlist and the reasoning. No vendor is given your details.