RTOS or bare-metal on STM32 for industrial work?
The two approaches compared on response time, maintainability and validation cost, with a decision guide for each class of machine.
RTOS or bare-metal on STM32: a decision, not a preference
Every industrial firmware team eventually has this argument, and it usually gets settled by habit rather than by the actual requirements of the machine. Here's a more useful way to decide.
Response time
Bare-metal, interrupt-driven code gives you deterministic, sub-microsecond response with no scheduling jitter — because there's no scheduler. An RTOS adds task-switch latency, typically single-digit microseconds on a Cortex-M4 at 168 MHz, which is negligible for most industrial loops but matters if you're closing a current loop at 100 kHz.
Maintainability as the codebase grows
This is where bare-metal starts to hurt. Once you're juggling more than four or five concurrent responsibilities — comms, motion control, safety monitoring, logging — a flat superloop turns into a web of flags and state machines that only the original author can safely modify. An RTOS (FreeRTOS is the practical default on STM32) gives you tasks, queues, and semaphores as first-class primitives, and a new engineer can reason about one task without reading the whole codebase.
Validation and certification cost
If the product needs IEC 61508 or similar functional-safety sign-off, every task, every interrupt priority, and every shared resource becomes something an auditor will ask about. Bare-metal has a smaller surface area to certify. An RTOS is certifiable (SafeRTOS exists precisely for this), but budget real engineering time for it — it is not a drop-in replacement for FreeRTOS in a safety case.
A rough decision guide
- Single motor axis, hard real-time loop, small team: bare-metal superloop with interrupts.
- Multi-axis machine with comms stack, HMI, and logging running alongside control: RTOS.
- Safety-rated machine: whichever you choose, budget for a certified kernel or a rigorously reviewed bare-metal core — don't improvise here.
- Team growth expected: RTOS pays for itself once you have more than two firmware engineers touching the same binary.
A middle ground worth considering
Plenty of production STM32 designs run a lightweight cooperative scheduler — not a full RTOS, not a flat superloop — which gives task separation without the overhead or certification burden of a preemptive kernel. If your timing budget is generous and your team is small, this is often the pragmatic answer nobody mentions in the RTOS-vs-bare-metal debate.
Bottom line: decide based on your hardest real-time constraint and your team's growth trajectory, not on what you used last time.