When bare-metal still wins over an RTOS on Cortex-M
RTOS adoption is often treated as a maturity milestone. On many Cortex-M4 and M33 products we review, the scheduler adds RAM overhead and interrupt latency without reducing source line count—because the hard real-time work still lives in ISRs anyway.
Bare-metal remains appropriate when every microsecond of jitter in a motor control loop is contractual, when your SIL evidence already describes a cyclic executive, or when total SRAM is under 64 KB and you cannot afford idle task stacks plus heap guards.
That does not mean spaghetti in main(). We implement a table-driven scheduler: each entry has period, deadline, and last-run timestamp. Watchdog feeding and communication polling live in known slots; long-running CRC work is chunked across cycles. Unit tests run the scheduler on host with simulated ticks.
Where RTOS helps is genuine concurrency: separate protocol stacks, file system access, and UI threads with blocking calls. If your product roadmap adds those in eighteen months, design hooks now—mutex stubs, message queues behind interfaces—without paying RAM today.
We run a one-week architecture review that ends with a written recommendation, not a sales push toward FreeRTOS. RTOS integration follows only when the memo says so.