§ Guide
Zephyr vs Yocto vs bare-metal.
Choosing an operating model for an edge AI device isn't either/or. The right answer is often 'both at once' — a rich Linux core plus a real-time companion on the same module.
Three options cover almost every edge AI device. The trick is matching each workload to the right one — and, on heterogeneous silicon, running more than one on a single module.
Decision table
| Bare-metal | Zephyr (RTOS) | Yocto (Linux) | |
|---|---|---|---|
| Footprint | Smallest (KB) | Small (KB–MB) | Large (MB–GB) |
| Real-time | Hard real-time | Hard real-time (RTOS) | Soft real-time |
| Ecosystem | Minimal | Growing RTOS ecosystem | Full Linux (OpenCV, networking) |
| Boot time | Instant | Milliseconds | Seconds |
| Best for | Tiny sensors, ultra-low power | Real-time control, M-class cores | Rich apps, vision, A-class cores |
Run more than one, per core
On a heterogeneous E1M-X module you don't have to pick one. TheAlp SDK declares the OS per core in a singleboard.yaml — Yocto on the application cluster, Zephyr on the real-time companion — and produces a dual-image build with IPC wired in. See theE1M-X modules that support it.
Frequently asked questions
- Should I use Zephyr, Yocto, or bare-metal for an edge AI device?
- Use bare-metal or Zephyr RTOS for resource-constrained, hard-real-time control (kilobytes of RAM, microsecond latency). Use Yocto Linux when you need a rich stack like OpenCV, full networking, or a filesystem. Many edge AI devices need both at once — a Linux application core plus a real-time companion.
- Can I run more than one OS on a single module?
- Yes, on heterogeneous modules. E1M-X pairs application-class (Cortex-A) cores with real-time (Cortex-R/M) cores. The Alp SDK lets you declare the OS per core in one board.yaml — for example Yocto on the A-cluster and Zephyr on the M companion — and builds a dual-image with the inter-processor communication stitched in.
- Is an RTOS or Linux better for AI inference?
- It depends where the NPU sits and how heavy the model is. Lightweight always-on models run well under an RTOS or bare-metal for the lowest power; larger vision pipelines benefit from Linux for tooling and memory. With one SDK across both, you can split the work across cores rather than choosing one.