Memory Efficiency and Scalability Trade-Offs Between Bare-Metal and FreeRTOS on Arm Cortex-M Microcontrollers for IoT and TinyML Applications: A Systematic Literature Review

The choice between a bare-metal super-loop and a lightweight real-time operating system (RTOS) in embedded development has traditionally been made informally. As concurrent workloads such as TinyML inference and hard-deadline sensor tasks are consolidated onto a single microcontroller, that choice increasingly determines whether deadlines are met and which models fit in memory, and it warrants systematic evaluation. This review synthesizes embedded-systems research published between 2018 and 2025 on the trade-off between bare-metal implementations and FreeRTOS, treated strictly as a microkernel and scheduler, across three dimensions: memory footprint, execution determinism, and heap fragmentation. The scope is deliberately bounded to Arm Cortex-M class devices and to FreeRTOS so that the measured overhead can be attributed to scheduling alone rather than to an accompanying middleware ecosystem. Synthesizing kernel design specifications and the reported measurements, we estimate that a representative five-task deployment incurs on the order of 20–40 KB of RAM overhead before application data is allocated; this is an estimate derived from design specifications and architectural analysis rather than a measured constant, and it is consequential on devices where a TensorFlow Lite Micro Tensor Arena already claims a substantial share of RAM. Pre-emptive scheduling delivers bounded task-activation latency that a cooperative loop cannot guarantee once a long, non-decomposed computation enters the loop body, although hardware interrupts pre-empt a super-loop irrespective of the scheduling model. Dynamic heap allocation introduces runtime unpredictability, a risk that a fully static FreeRTOS build avoids as completely as bare metal does. We consolidate these findings into a scalability crossover heuristic and a Decision Matrix keyed to the RAM effectively available after the arena is reserved. The resulting thresholds—approximately two concurrent real-time tasks and an overhead fraction of roughly one half of non-arena RAM—are offered as indicative design guidance requiring empirical calibration on hardware, not as universally applicable limits.