Wanneer kies je Zephyr voor een embedded product?

Productteams moeten vroeg kiezen tussen bare-metal, een RTOS en embedded Linux. Zephyr is een sterke optie zodra je firmware uitgroeit van een eenvoudige control loop tot een connected softwareplatform. Tegelijk heeft niet elk microcontrollerproject een RTOS nodig. Voor eenvoudige, deterministische taken is bare-metal vaak kleiner, transparanter en makkelijker te onderhouden. Hieronder lees je hoe we die afweging maken.

Van firmware naar softwareplatform

Veel microcontrollerprojecten beginnen eenvoudig. Je leest een paar inputs, werkt een state machine bij, stuurt outputs aan en begint opnieuw. Voor dat soort toepassingen werkt een klassieke bare-metal architectuur vaak uitstekend. Dat verandert snel zodra het product Bluetooth, Wi-Fi, LTE-M, Ethernet, TLS, MQTT, lokale opslag, firmware-updates, power management of meerdere taken tegelijk krijgt.

Vanaf dan schrijf je eigenlijk geen firmware rond een control loop meer, maar bouw je een klein softwareplatform. Daar begint Zephyr interessant te worden.

Zephyr is meer dan een scheduler. Het combineert een real-time kernel met drivers, networking, Bluetooth, storage, logging, power management, cryptografie, configuratie, hardwarebeschrijving en integraties voor secure boot en firmware-updates.

Wat Zephyr meebrengt

• Pre-emptive en cooperative scheduling, threads, timers en synchronization primitives.
• Een breed driver model voor GPIO, I²C, SPI, UART, CAN, sensoren, flash en andere peripherals.
• Networking stacks en protocollen, onder meer IPv4/IPv6, TCP/UDP, MQTT en Bluetooth.
• Kconfig voor de configuratie tijdens het compileren en DeviceTree voor de hardwarebeschrijving.
• CMake en west voor builds, dependencies en workflows over meerdere repositories.
• Infrastructuur voor logging, een shell, settings, storage en power management.
• Integratie met MCUboot en ecosystemen voor signed firmware en firmware-updates.

DeviceTree en Kconfig houden hardware en software uit elkaar

Waar Zephyr verschilt van veel klassieke firmwareprojecten, is dat het de hardwarebeschrijving en de softwareconfiguratie expliciet structureert. DeviceTree beschrijft welke hardware er is en hoe die verbonden is. Kconfig bepaalt welke softwarecomponenten en features in de build terechtkomen.

Dat helpt vooral bij productfamilies. Product A, B en C kunnen elk een eigen board definition en DeviceTree overlay hebben, terwijl een groot deel van de applicatielogica dezelfde blijft. Varianten beheren en code hergebruiken wordt daardoor een pak eenvoudiger.

Wanneer Zephyr echt interessant wordt

Zephyr loont vooral wanneer verschillende soorten complexiteit samenkomen in één product:

• Er lopen meerdere activiteiten tegelijk, zoals communicatie, sensoren, control loops, logging en achtergrondtaken.
• Het toestel is connected via BLE, Wi-Fi, Ethernet of cellular.
• Je hebt TLS, certificaten, MQTT of andere protocollen nodig die je liever niet als losse libraries integreert.
• Dezelfde firmware moet op meerdere hardwarevarianten of boards draaien.
• Het product vraagt remote updates, secure boot en lifecycle management.
• Het is een low-power product waarin je verschillende subsystemen en wake-up bronnen op elkaar moet afstemmen.

Het vendor-ecosysteem maakt het verschil

De waarde van Zephyr zit niet alleen in het upstream project. Chipfabrikanten bouwen er steeds vaker uitgebreide SDK’s rond. Nordic Semiconductor is daar een goed voorbeeld van met de nRF Connect SDK. Voor een cellular product op bijvoorbeeld een nRF9151 krijg je daarmee één samenhangend platform voor het modem, LTE-M/NB-IoT, GNSS, TLS, MQTT, power management en firmware-updates.

De vraag of een MCU Zephyr ondersteunt, is dus maar het begin. Minstens even belangrijk is hoe volwassen de drivers, voorbeelden, vendor libraries, debugging tools, releaseprocessen en long-term support zijn voor precies de peripherals die jouw product nodig heeft.

Soms is bare-metal gewoon beter

Een RTOS is geen doel op zich. Elke abstractielaag brengt eigen concepten, configuratie en dependencies mee. Is de toepassing klein en overzichtelijk, dan kost die extra infrastructuur je soms meer dan ze oplevert.

In onze X Series displays zit bijvoorbeeld een eenvoudige AVR32DD32-microcontroller voor ondersteunende taken rond de hoofdcomputer. De firmware schakelt de power rails in de juiste volgorde, bewaakt de ignition, beheert de statusindicatie en communiceert op een eenvoudige manier met de hoofdprocessor, onder meer voor de shutdown-sequentie. Dat is een compacte, deterministische state machine met weinig concurrency en zonder complexe networking. Zephyr zou daar functioneel weinig toevoegen. Bare-metal is hier kleiner en directer, en je kunt de code volledig doorgronden.

We kiezen daarom de kleinste softwarearchitectuur die de requirements robuust en onderhoudbaar afdekt. Voor die power controller komt dat hierop neer:

• Enkele GPIO’s, timers, UART/I²C en een overzichtelijke state machine.
• Geen BLE, IP networking, TLS of complexe protocolstack.
• Geen tientallen onafhankelijke taken.
• Strikte controle over het bootgedrag en de timing regel je gewoon rechtstreeks.
• Een kleine codebase houdt review, debugging en onderhoud op lange termijn overzichtelijk.

Zephyr of FreeRTOS

FreeRTOS en Zephyr overlappen, maar ze komen historisch uit een andere hoek. FreeRTOS is in de kern een compacte en heel breed gebruikte RTOS-kernel, die je meestal aanvult met een vendor-SDK en aparte libraries. Zephyr profileert zich eerder als een geïntegreerd embedded platform.

Aspect	Zephyr	FreeRTOS
RTOS-kernel	Ja	Ja
Hardwarebeschrijving	DeviceTree, geïntegreerd	Meestal specifiek per vendor of project
Configuratie	Kconfig	Specifiek per project of vendor
Drivers en subsystems	Breed geïntegreerd platform	Vaak via een vendor-SDK of libraries
Networking en BLE	Sterk geïntegreerd	Afhankelijk van de gekozen stack of SDK
Build workflow	CMake en west	Sterk afhankelijk van het ecosysteem
Typische sterkte	Complexe of connected MCU-producten	Compacte RTOS-basis, brede adoptie bij vendors

Een universele winnaar is er niet. Voor sommige producten volstaat een compacte FreeRTOS-opzet perfect. Bij andere haalt het bredere Zephyr-platform juist veel integratiewerk weg.

Zephyr of embedded Linux

Zephyr vervangt embedded Linux niet, want ze lossen een ander probleem op. Op een Cortex-M microcontroller draait Zephyr dicht bij de hardware, met lage latency, beperkt geheugen en een snelle boot. Linux hoort thuis op krachtige application processors met een rijke HMI, multimedia, containers, grote applicaties en een complexe userspace. Welke Linux-distributie je dan kiest, bespreken we in Yocto vs Ubuntu vs Debian.

	Zephyr	Embedded Linux
Typische CPU	Cortex-M, MCU	Cortex-A, MPU
Geheugen	KB tot enkele MB	Honderden MB tot GB
Boot	Milliseconden, zeer snel	Typisch enkele seconden
Real-time control	Sterk	Andere architectuur, RT-opties mogelijk
Rijke HMI	Beperkt	Sterk, met Qt, web en andere
Containers en procesisolatie	Niet het doel	Sterk

Vaak is het antwoord trouwens: allebei. Een industrieel product kan perfect een Linux application processor gebruiken voor de HMI, de cloudconnectiviteit en de dataverwerking, samen met een MCU op Zephyr voor real-time I/O, sensoren, motor control of ondersteunende functies die met safety te maken hebben.

Security, secure boot en firmware-updates

Connected firmware moet je kunnen onderhouden zolang het product meegaat. Zephyr past goed in een architectuur waarin je firmware signing, secure boot, versioning en remote updates van bij het begin meeneemt.

In Zephyr-ecosystemen wordt vaak MCUboot als secure bootloader gebruikt. Afhankelijk van de MCU, de flasharchitectuur en de productrequirements kun je werken met signed images, verschillende rollbackstrategieën en verschillende updateflows. Hoe veilig het resultaat is, hangt altijd af van de gekozen MCU, de opslag van de keys, de boot chain en de updatearchitectuur. Dat je Zephyr gebruikt, maakt een product op zich nog niet veilig.

Zodra een toestel verbonden is, horen updatebaarheid, kwetsbaarheden, de opvolging van SBOM en CVE’s en een gecontroleerd releaseproces bij de volledige levenscyclus van het product, en niet enkel bij de eerste firmwareontwikkeling.

Hoe we dat voor Linux-images aanpakken, lees je in SBOM en CVE-monitoring met Yocto.

De keerzijde: complexiteit en een leercurve

Zephyr heeft ook een prijs, en die moet je vooraf kennen:

• DeviceTree, Kconfig, CMake en west vormen samen een krachtige maar allesbehalve triviale toolchain.
• Door de abstractielagen is debuggen minder direct dan in een kleine bare-metal codebase.
• De footprint is niet te verantwoorden voor elke heel kleine MCU of minimale toepassing.
• Vendor forks en SDK-versies moet je bewust beheren.
• Niet elke peripheral of driver is op elke SoC even volwassen.
• In een goede architectuur beperk je vendor-specifieke API’s tot waar de standaard Zephyr-interfaces niet volstaan.

Upstream Zephyr of een vendor-SDK?

In de praktijk werk je vaak niet rechtstreeks op upstream Zephyr. Een leverancier neemt Zephyr op in een eigen SDK, samen met proprietary of vendor-specifieke libraries, tooling en releases. Voor hardware enablement en support is dat vaak een groot voordeel, maar je kiest daarmee ook voor een afhankelijkheid van die leverancier.

Wij gebruiken de standaard Zephyr-API’s waar dat zinvol is, houden vendor-specifieke functionaliteit bewust apart, en leggen vooraf vast hoe we updates van de SDK en van Zephyr zelf beheren zolang het product meegaat.

Een praktische keuzehulp

Producttype	Logische startkeuze
Eenvoudige power controller of supervisor	Bare-metal
Kleine machine-I/O controller	Bare-metal of een RTOS, afhankelijk van de concurrency
BLE-sensor	Zephyr is vaak sterk
LTE-M- of NB-IoT-toestel	Zephyr, of een vendor-SDK op Zephyr, is vaak sterk
Connected IoT-toestel op batterij	Zephyr is vaak interessant
Complexe grafische HMI	Embedded Linux
Industriële panel-pc	Embedded Linux met Yocto
HMI met een real-time peripheral controller	Linux plus een MCU met Zephyr of bare-metal

Kies het platform op basis van het product

Welk framework het populairst is, zegt weinig over wat bij jouw toestel past. Kijk eerst naar de timing, de connectiviteit, het stroomverbruik, security, updatebaarheid, de hardwarevarianten, de levensduur van het product en hoe complex de software naar verwachting wordt.

Bij Invisto werken we over de volledige embedded stack, van kleine microcontrollerfirmware en connected devices op Zephyr tot custom Yocto Linux-platformen en HMI-applicaties. Zo kunnen we de softwarearchitectuur uit het product laten volgen, in plaats van elk product in hetzelfde platform te duwen. Hoe dat samenhangt met de keuze van de hardware, lees je in SOM vs custom PCB en, voor de licenties van de HMI, in Qt-licenties voor embedded devices.