Zephyr
2
Agenda
What we will cover in this lecture
3
Part 1
What IoT demands from an RTOS
RTOSes for IoT
4
Typical IoT constraints
Why “tiny + connected + safe” is hard
Constrained resources
• RAM/flash are limited
• CPU budgets vary (MCUs → SoCs)
• Devices often need long battery life
Connectivity is non-optional
• IPv6/UDP/TCP + security (TLS/DTLS)
• IoT app protocols (CoAP, MQTT, LwM2M)
• Multiple link layers (802.15.4, BLE, Wi‑Fi, CAN)
Modern expectations
• Secure boot + signed updates
• Isolation (where hardware supports it)
• Testability, CI, reproducible builds
• Observability (logging/tracing/metrics)
• Fast bring-up across many boards
RTOSes for IoT — Zephyr OS focus
5
IoT protocol stacks (quick refresher)
From radios to application protocols
Key idea: enable only what you need to reduce RAM/flash usage.
Application
CoAP • MQTT • HTTP • LwM2M
Security
DTLS • TLS
Transport
UDP • TCP
Network
IPv6 • RPL
Adaptation
6LoWPAN
Link/PHY
802.15.4 • BLE • Wi‑Fi • CAN
RTOSes for IoT
6
Kernel & RTOS design patterns
A few concepts that matter on MCUs
Scheduling models
• Priority-based scheduling
• Preemptive vs cooperative threads
• Optional time slicing for equal priorities
• Specialized policies (e.g., EDF)
Memory & safety
• Static vs dynamic allocation
• Stack sizing + overflow detection
• Optional user mode (MPU/MMU backed)
• Fault handling & assertions
Power-aware idling
• Tickless idle (event-driven)
• System + device power management
• Minimize wake-ups
• Wake latency tradeoffs
Portability levers
• Hardware description (Devicetree)
• Feature selection (Kconfig)
• HAL/driver layers
• Consistent tooling (build/flash/debug)
RTOSes for IoT — Zephyr OS focus
7
Part 2
RTOS landscape
RTOSes for IoT — Zephyr OS focus
8
A quick landscape view
Different trade-offs for different products
FreeRTOS
Great when you want a small kernel + choose your own ecosystem.
Often paired with vendor SDKs and separate stacks.
Zephyr
“Batteries included”: kernel + drivers + networking + security services.
Highly configurable via Kconfig + Devicetree.
RIOT
IoT-friendly networking (6LoWPAN/IPv6/RPL/CoAP, etc).
Strong community and modular design.
Apache NuttX
POSIX-leaning RTOS with standards compliance focus.
Scales from tiny MCUs to larger systems.
Contiki-NG
Research-friendly OS with low-power IPv6 stacks (RPL/CoAP/LwM2M).
Strong for constrained network experiments.
Rule of thumb
Choose the smallest thing that still meets your
connectivity + security + maintainability targets.
RTOSes for IoT
9
Zephyr snapshot
What the project looks like today
Current release: 4.3 (GA)
Next releases move to a bi-yearly cadence in 2026.
Permissive Apache-2.0 licensing.
Why teams pick Zephyr for IoT products
RTOSes for IoT
10
Part 3
Zephyr deep dive
RTOSes for IoT
11
Zephyr system architecture
Kernel + OS services + connectivity stacks
Kernel services
Threads, scheduling, interrupts, synchronization primitives,
timers, memory domains (optional user mode).
OS services
Drivers, file systems, logging, IPC, crypto,
device management + power management.
Connectivity
Modular IP stack (IPv4/IPv6) + multiple L2 options.
App protocols like CoAP/MQTT can be enabled as needed.
RTOSes for IoT
12
Kernel scheduling in Zephyr
Priority-based with multiple policies
Thread types
• Cooperative threads (non-preemptible)
• Preemptible threads (priority-based preemption)
• Meta-IRQ / bottom-half style options
• Optional EDF scheduling (Earliest Deadline First)
Time slicing
Time slicing can be enabled for preemptible threads
of equal priority, with a configurable slice size.
Use this when fairness matters more than strict
single-thread latency.
Design takeaway
In embedded systems, scheduling decisions tie directly to:
• latency
• power (wakeups)
• memory (stack sizes)
Zephyr lets you configure policies to match your product constraints.
RTOSes for IoT
13
Portability: Devicetree vs Kconfig
Hardware description vs software feature selection
Devicetree (hardware)
• Describes the board/SoC hardware graph
• Pins, buses, peripherals, compatibles
• Overlays tweak board defaults
• Without editing upstream files
• Ex. change uart speed
Kconfig (software)
• Select features to compile into the image
• Drivers, protocols, logging levels, etc.
• Typically controlled through prj.conf and
menuconfig-like interfaces
Devicetree overlay example
1 /* boards/<board>.overlay (Devicetree) */�2 &uart0 {�3 current-speed = <115200>;�4 status = "okay";�5 };�6
Kconfig overlay example
1 /* prj.conf (Kconfig symbols) */�2 CONFIG_GPIO=y�3 CONFIG_LOG=y�4 CONFIG_NET_IPV6=y�5
RTOSes for IoT
14
A Zephyr “hello world” pattern
Devicetree-backed device handles
GPIO DT spec makes application code portable across boards:
blinky/src/main.c
1 #include <zephyr/kernel.h>� 2 #include <zephyr/drivers/gpio.h>� 3 � 4 #define LED0_NODE DT_ALIAS(led0)� 5 static const struct gpio_dt_spec led =� 6 GPIO_DT_SPEC_GET(LED0_NODE, gpios);� 7 � 8 int main(void) {� 9 if (!gpio_is_ready_dt(&led)) return 0;�10 gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE);�11 while (1) {�12 gpio_pin_toggle_dt(&led);�13 k_msleep(500);�14 }�15 }�16
Some key points
• No hardcoding of pin numbers
• LED alias comes from the board Devicetree
• gpio_dt_spec - captures pin + controller
• gpio_is_ready_dt() - verifies if driver is present and initialized
• gpio_pin_configure_dt() - pin becomes an active output
• gpio_pin_toggle_dt() - toggle the led
• k_msleep() uses kernel timing services
RTOSes for IoT
15
Tooling workflow
west + CMake provide a consistent developer experience
west (meta-tool)
• Manages multiple repositories
• Provides build/flash/debug commands
• Supports custom extension commands
CMake build system
• Two-stage configure + build
• Integrates app + Zephyr kernel
• Works across host platforms
Command-line workflow
1 # Typical session�2 west init -m https://github.com/zephyrproject-rtos/zephyr�3 west update�4 west zephyr-export�5 �6 # Build + flash (example board)�7 west build -b nrf52840dk_nrf52840 samples/basic/blinky�8 west flash�9
Tip: Use “west build -t menuconfig” for interactive Kconfig changes.
RTOSes for IoT — Zephyr OS focus
16
Networking in Zephyr
Modular IP stack with multiple L2 options
Core idea
Zephyr’s IP stack is modular and can be configured at build time.
You can minimize memory usage by enabling only required features.
Common IoT profiles
• 802.15.4 + 6LoWPAN + IPv6 + RPL
• Thread (IPv6 mesh over 802.15.4)
• BLE (incl. BLE Mesh in supported setups)
• Wi‑Fi + TCP/UDP + TLS/DTLS
• CoAP/MQTT application protocols
Thread example stack
Application: CoAP
Security: DTLS
Transport: UDP
Network: IPv6 + RPL
Adaptation: 6LoWPAN
Link: IEEE 802.15.4
Thread is an IPv6-based standard using 6LoWPAN over 802.15.4.
RTOSes for IoT
17
Security & firmware updates
From root-of-trust to OTA
Trusted Firmware‑M (TF‑M)
• TF‑M provides PSA Root of Trust services.
• Its secure boot image verifies secure and non-secure images.
• Protect the firmware update process via public signing keys.
DFU / OTA in Zephyr
• DFU subsystem - upgrade Zephyr-based applications at runtime.
• OTA downloads a new image to an update slot, then upgrades using the MCUboot process.
Key points
• “Secure boot” is a chain of trust
• Updates must be authenticated and rollback-safe
• Separate concerns: bootloader vs app vs transport
• Hardware features matter (TrustZone‑M, MPU, flash layout)
Also: Zephyr is permissively licensed under Apache‑2.0.
RTOSes for IoT
18
Power management
Tickless idling + system/device PM
Tickless idle (event-driven)
• A tickless kernel can sleep until the next event instead of
waking periodically for tick interrupts (“race to idle”).
• This reduces unnecessary wake-ups and saves energy.
System + device PM
• Zephyr’s PM subsystem supports system power states.
• Can suspend devices when the SoC goes to sleep (with care around ongoing transactions).
Practical angle
• Power is a system property, not a driver flag
• Measure: current draw vs latency vs duty cycle
• Choose wake sources and budgets early
• Configuration: what’s enabled affects power
(protocols, logging, timers, peripherals)
Zephyr PM docs: system PM + device PM.
RTOSes for IoT
19
Testing & developer experience
Why “upstream” matters
Twister (test harness)
• Zephyr includes a large automated test suite
• Recent releases have added tools to validate on-target behaviors
• Display output via captured frames (“display harness”)
Better diagnostics
• Zephyr 4.3 highlights include:
• dtdoctor - Devicetree diagnostics
• traceconfig - tools to inspect Kconfig provenance
Key development points
• Read build logs
• Debug Devicetree errors
• Track RAM/ROM changes when enabling network stacks
• Use reproducible builds (same commands, same results)
Takeaway: good tooling reduces “RTOS friction”.
RTOSes for IoT
20
Part 4
Hands-on: two small demos
RTOSes for IoT
21
Demo 1 — Blinky (portable)
Goal: blink the “led0” alias on any supported board
Steps
1) Install toolchain + west (per Getting Started)
2) Initialize workspace (west init/update) - Slide 15
3) Build for your board
4) Flash and observe LED toggle
Teaching points
• Board selected with “-b <board>”
• led0 alias comes from Devicetree
• prj.conf (Kconfig) enables needed subsystems
Terminal
1 # Build + flash�2 west build -b <your_board> samples/basic/blinky�3 west flash�4 �5 # Optional: open config UI�6 west build -t menuconfig�7
RTOSes for IoT — Zephyr OS focus
22
Demo 2 — Networking (conceptual path)
Goal: show how features are enabled and composed
Option A: IP over Wi‑Fi/Ethernet
Use Zephyr sockets (TCP/UDP) and a library protocol (CoAP/MQTT).
This is easiest to demo on dev boards with Wi‑Fi/Ethernet.
Option B: Thread mesh (802.15.4)
Thread is IPv6-based and uses 6LoWPAN over 802.15.4.
A Thread Border Router connects the mesh to the wider IP network.
Enable only what you need
1 # Build networking sample�2 west build -b <board> samples/net/sockets/echo_server�3 �4 # Example config knobs�5 CONFIG_NET_IPV6=y�6 CONFIG_NET_SOCKETS=y�7 # + enable desired L2: Wi-Fi / Ethernet / 802.15.4�8
Lesson: networking is “lego bricks” — stacks are compiled in, not installed at runtime.
RTOSes for IoT
23
Choosing the right OS
A pragmatic decision matrix
Ask these questions first:
Typical picks
RTOSes for IoT
24
References & further reading
Primary docs worth bookmarking
RTOSes for IoT