Most embedded products don't need the most capable OS their hardware can run.
A lot of projects choose embedded Linux when the actual requirements are a scheduler, a TCP/IP stack and a UI. Then they inherit a kernel, userspace, filesystem, boot architecture, processes, services and a much larger software lifecycle.
The justification is usually “future proofing” or “application flexibility.” Sometimes that's valid. Sometimes it's complexity purchased for requirements that never arrive.
If Zephyr on an STM32 solves the problem, use Zephyr. If FreeRTOS on an ESP32 solves it, use FreeRTOS. If a bare-metal state machine on a Cortex-M4 solves it, don't add an OS just because you can.
With the smaller system, the constraints are explicit. Startup is easier to bound. Interrupt latency is easier to characterise. Memory use is obvious. There are fewer execution paths competing with your timing and power budget.
Linux is a tool, and sometimes absolutely the right one. Rich graphics, sophisticated networking, filesystems, large application frameworks, process isolation and complex userspace are strong reasons to use it.
But “we might need Python later” or “the processor has four cores anyway” isn't architecture. It's speculation.
Choose the smallest platform that satisfies the actual requirements, not the hypothetical ones.
What feature justification ended up becoming unused complexity in your project?
#EmbeddedSystems #EmbeddedLinux #RTOS #BareMetal #FirmwareEngineering #Zephyr #FreeRTOS #EmbeddedC