Een van de grootste succesverhalen in de opensourcewereld is de Linux-kernel. Maar wat als je een besturingssysteem wilt draaien op apparaten met heel wat beperkingen? Zephyr is stevig aan de weg aan het timmeren om de ‘Linux’ voor deze apparaten te worden.
Zephyr is een opensource realtime besturingssysteem (rtos) voor ‘connected resource-constrained devices’. Denk daarbij bijvoorbeeld aan iot-sensoren, bluetooth-trackers en hartslagmeters. Dankzij een hardware-abstractielaag ondersteunt Zephyr honderden ontwikkelbordjes en het besturingssysteem heeft protocollen zoals Bluetooth Low Energy, Thread, CAN, 6LoWPAN en CoAP ingebouwd.
Heel wat iot-apparaten zijn voorzien van Linux als besturingssysteem, maar dat heeft minimumeisen. Voor Arm-processoren heb je bijvoorbeeld al minstens een Cortex-A nodig. Voor meer gelimiteerde chips zoals een Cortex-M is een realtime besturingssysteem zoals Zephyr beter geschikt. Een typisch apparaat waarop Zephyr draait heeft een microcontroller met een klokfrequentie lager dan 100MHz, zonder memory management unit (mmu) en met 32 tot 256KB statisch ram en 512KB of minder on-chip nor-flashgeheugen.
Er is een heel gamma aan realtime besturingssystemen die zich op dit soort apparaten richten. FreeRTOS is met zijn ondersteuning voor veertig architecturen een populaire optie. Sinds 2017 vindt de ontwikkeling plaats door het Amazon Web Services-team. Het is echter een basic kernel zonder drivers, bestandssystemen, netwerkstacks enzovoort. Een andere populaire optie is Mbed OS van Arm, maar dit ondersteunt alleen 32-bits Arm Cortex-M-microcontrollers. Ook interessant is Apache Mynewt. De mogelijkheden hiervan lijken nog het meeste op die van Zephyr, maar Mynewt ondersteunt minder ontwikkelbordjes.
Het grootste deel van de code van Zephyr valt onder de Apache 2.0-licentie, met uitzondering van drivers van Nordic Semiconductor en NXP Semiconductors, die de BSD-Clause-3-licentie gebruiken. Sommige build tools vallen onder de GPLv2. Door de vrij permissieve licentie(s) is firmware op basis van Zephyr ook commercieel zonder licentiekosten te gebruiken, al zullen veel bedrijven supportcontracten met hardwarefabrikanten aangaan. Net zoals Linux heeft Zephyr een open, collaboratief ontwikkelingsmodel waarbij zelfs concurrerende bedrijven met elkaar samenwerken.
Concurrerende bedrijven werken in het Zephyr-project samen
Afbeelding: Getty Images/ DKosig
Belgische herkomst, focus op kwaliteit en veiligheid
Geschiedenis van Zephyr
De geschiedenis van Zephyr begon bij Eonic Systems. Dit Belgische softwarebedrijf ontwikkelde in 1991 een realtime besturingssysteem voor digitale signaalprocessoren (dsp’s), Virtuoso. In 2001 werd Eonic Systems overgenomen door Wind River Systems. Virtuoso werd in die tijd onder andere ingezet in de Rosetta-ruimtesonde van ESA.
Wind River Systems werd op zijn beurt in 2009 overgenomen door Intel. Daarna werd Virtuoso geport naar de x86-architectuur, en later ook naar Arm. In 2015 werd het besturingssysteem hernoemd naar Rocket en werd het project opensource gemaakt. Het kreeg zo een nieuwe bestemming als mini-besturingssysteem voor slimme sensoren. De kleinste versie van Rocket draaide zelfs op 32-bit-microcontrollers met maar 4KB geheugen.
In 2016 doneerde Wind River Systems zijn Rocket-kernel aan een nieuw project van de Linux Foundation, Zephyr. Andere deelnemers vanaf het begin waren Intel, NXP Semiconductors, Synopsys en UbiquiOS Technology. Ook Linaro, Texas Instruments en Nordic Semiconductor waren vroege supporters.
De originele Rocket-kernel, die uit een nanokernel en een microkernel bestond, werd in Zephyr 1.6 (in december 2016) vervangen door één monolithische kernel, die eenvoudiger was om op te programmeren.
Long-term support
De ontwikkelaars van Zephyr hebben heel wat van het ontwikkelmodel van Linux overgenomen. Zo zijn er ook lts-versies (long-term support). Dit zijn versies die langere tijd onderhouden worden, zodat bedrijven een stabiele basis hebben om op voort te bouwen voor hun producten. In het geval van Zephyr lts-releases is de ondersteuningstermijn minstens twee jaar. Een lts-release krijgt geen nieuwe functies of substantiële verbeteringen, maar wel oplossingen voor ernstige of beveiligingsgerelateerde fouten.
De eerste lts-release was Zephyr 1.14 uit april 2019, met 160 ondersteunde bordconfiguraties voor acht architecturen. Hij werd in oktober 2021 gevolgd door de tweede lts-versie, Zephyr 2.7. Die ondersteunt maar liefst vierhonderd bordconfiguraties voor twaalf architecturen.
Zephyr ondersteunt meer dan 400 ontwikkelbordjes van 12 architecturen
Kwaliteit en veiligheid
In 2019 was Zephyr een van de drie opensourceprojecten die de ‘gouden’ badge voor Best Practices van het Core Infrastructure Initiative ontvingen. Inmiddels hebben achttien projecten deze status en Zephyr heeft nog altijd de maximale score. Hiermee toont het project aan dat het goede ontwikkelpraktijken hanteert met een focus op kwaliteit en veiligheid.
De Zephyr-ontwikkelaars hebben diverse werkgroepen, en een daarvan is de Security Working Group. Deze handelt niet alleen gevonden kwetsbaarheden af, maar werkt ook aan een veilige architectuur voor het besturingssysteem. In de documentatie van Zephyr staat uitgebreid beschreven welke maatregelen de ontwikkelaars nemen op het gebied van veiligheid.
Zephyr haalt de maximale score van de OpenSSF Best Practices voor kwaliteit en veiligheid.
Buildsysteem
Zephyrs buildsysteem is gebaseerd op CMake. Elke Zephyr-applicatie heeft een bestand CMakeLists.txt dat het buildsysteem vertelt waar het de benodigde codebestanden vindt en hoe de applicatie met Zephyr gelinkt wordt.
Je kunt CMake rechtstreeks aanroepen om je applicatie te compileren, maar de standaard buildtool van Zephyr is west, dat dan op de achtergrond CMake aanroept. De Zephyr-ontwikkelaars beschrijven west als een ‘meta-tool’. Met west compileer je niet alleen je applicatie, maar flash je hem ook naar je apparaat en kun je ook repository’s beheren.
De ontwikkelomgeving van Zephyr draait zowel op Windows als macOS en Linux (Ubuntu is de ondersteunde distributie). Je installeert hiermee de compiler, assembler, linker en alle andere benodigde programma’s om Zephyr-applicaties te bouwen.
Modulaire opbouw
Zephyr is modulair opgebouwd. De applicatie die je ontwikkelt, wordt samen met Zephyr en eventuele externe bibliotheken gecompileerd en statisch gelinkt tot één stuk firmware dat je naar je apparaat flasht. Bij het compileren geef je aan welke subsystemen je al dan niet nodig hebt en in de firmware wilt opnemen. Op die manier kan Zephyr ook op apparaten met een breed bereik van mogelijkheden draaien, van de kleinste chips met 8KB ram tot ontwikkelbordjes waarop je zelfs Linux kunt draaien.
Voor je keuze van subsystemen die je gebruikt - en andere configuratie-opties - maakt Zephyr gebruik van Kconfig, het configuratiesysteem van de Linux-kernel. Je schakelt hiermee niet alleen subsystemen in en uit (zoals bluetooth, IPv6, LwM2M, I²C, …), maar configureert ze ook tot in de details. Ook architectuurspecifieke opties, drivers en allerlei softwarebibliotheken configureer je op deze manier.
De configuratie-opties voor je applicatie stel je in een bestand prj.conf in. Dat ziet er voor een bluetooth-sensorbordje bijvoorbeeld als volgt uit:
Hiermee schakel je de subsystemen voor bluetooth, I²C en sensoren in, evenals de driver voor de BME280-sensor die temperatuur, luchtdruk en luchtvochtigheid meet. Overigens schakelt het buildsysteem afhankelijk van het bordje waarvoor je je applicatie bouwt, op de achtergrond allerlei andere opties al standaard in.
Je kunt je configuratie ook opsplitsen in meerdere bestanden. Zo kent Zephyr het concept van een overlay config-file. In dit bestand zet je extra configuratie-opties die je in specifieke omstandigheden aan het standaardbestand prj.conf wilt toevoegen, bijvoorbeeld om een debugversie van de firmware te bouwen. Overlayconfiguratiebestanden voeg je toe met de CMake-variabele OVERLAY_CONFIG.
Het exacte configuratiebestand waarmee je toepassing wordt gebouwd, na het toepassen van de expliciet opgegeven configuratiebestanden en overlays en de standaardconfiguratie voor het gekozen bordje, vind je na het bouwen in het bestand zephyr/build/zephyr/.config.
Devicetree, protocollen en netwerkapplicaties
Hardware-abstractielaag
Een ander hulpmiddel dat Zephyr van de Linux-kernel heeft geleend, is de Devicetree. Dit is een hiërarchische structuur die hardware beschrijft. Voor elk ondersteund ontwikkelbordje heeft Zephyr een devicetree die beschrijft welke hardware er aanwezig is, zoals een uart, I²C- en spi-bus, adc, gpio’s, sram, flash, bluetooth, enzovoort. Wanneer je je applicatie compileert, geef je op voor welk bordje je dat wilt doen. Het buildsysteem kiest dan de juiste devicetree voor dit bordje en genereert een C-header.
De apparaatdrivers en je eigen applicatie kunnen deze gegenereerde header includen om de hardware, zoals bijvoorbeeld een sensor, aan te spreken. Zephyr heeft een generiek model voor apparaatstuurprogramma’s. Elk type driver (bijvoorbeeld uart, spi, I²C) heeft een generieke api. In je applicatie hoef je doorgaans dus niet voor elk apparaat op te zoeken hoe je die specifieke driver moet gebruiken. Verschillende hardwarefabrikanten, zoals Nordic Semiconductor, STMicroelectronics en NXP Semiconductors, onderhouden hun eigen hardware-abstractielaag voor Zephyr.
Een krachtig concept dat hiermee samenhangt is een devicetree overlay. Hiermee pas je een bestaande devicetree aan. Stel dat je een applicatie wilt compileren voor een ontwikkelbordje, maar je hebt hier zelf allerlei sensoren op aangesloten. Dan creëer je een overlay die beschrijft dat je bordje in tegenstelling tot het standaardbordje die sensoren heeft. Het buildsysteem pikt automatisch de overlay op als de bestandsnaam bestaat uit de naam van het bordje en de extensie .overlay. Deze wordt dan met de originele devicetree samengevoegd. Je kunt ook expliciet overlays toevoegen met de CMake-variabele DTC_OVERLAY_FILE.
Stel dat je op een nRF52840-dongle een BME280-sensor hebt aangesloten via I²C. Dan maak je een device overlay in het bestand nrf52840dongle_nrf52840.overlay met de volgende inhoud:
Zoals je ziet, definieer je hierin een I²C-bus met de sda- en scl-pinnen, en een BME280-sensor met zijn I²C-adres 0x76.
Sluit je een BME280-sensor op een nRF52840 aan, dan ondersteun je die eenvoudig in Zephyr met een device overlay.
Communicatieprotocollen
Zephyr ondersteunt usb, controller area network (can), I²S audio, I²C, spi en uart. Aangezien het besturingssysteem in de markt wordt gezet voor iot-apparaten, is ook de ondersteuning van netwerken en draadloze communicatieprotocollen essentieel. De Bluetooth Low Energy-protocolstack van Zephyr is een populaire keuze voor de ontwikkeling van BLE-apparaten. Zo heeft Nordic Semiconductor, een populaire producent van BLE-chips, zijn nRF Connect SDK op Zephyr gebaseerd.
Ook Thread, het opkomende IPv6-gebaseerde draadloze meshnetwerk, heeft ondersteuning in Zephyr. Daarvoor integreert Zephyr de implementatie OpenThread. Andere ondersteunde netwerktechnologieën zijn IEEE 802.15.4, ethernet en PPP. Ondersteuning van Wi-Fi op de ESP32 is nog maar een recente toevoeging van vorig jaar.
Voor IP-gebaseerde iot-apparaten maak je doorgaans gebruik van een high-level applicatieprotocol. Zephyr ondersteunt Constrained Application Protocol (CoAP), dat een lichtgewicht versie aanbiedt van een rest-api. Met Zephyr kun je zowel een CoAP-client als een CoAP-server ontwikkelen. Bovenop CoAP kun je Lightweight M2M (LwM2M) draaien, een protocol voor devicemanagement, rapportage en aansturing van apparaten. Zephyrs implementatie ondersteunt LwM2M 1.0.2. Verder beschikt Zephyr ook over een MQTT-client met ondersteuning voor MQTT 3.1.0 en 3.1.1. Je kunt die rechtstreeks over tcp gebruiken of over tls.
Bestandssystemen
Zephyr ondersteunt allerlei bestandssystemen en als ontwikkelaar van een applicatie hoef je hun interne functies niet aan te spreken. Je maakt doorgaans immers gebruik van de generieke api van de Virtual Filesystem Switch (VFS). Tot de ondersteunde bestandssystemen behoren FAT en LittleFS.
De opslag van het bestandssysteem kan op het interne flashgeheugen of op extern flashgeheugen, op een SD-kaart over een spi-bus of via een on-chip controller, of in het ram. Je kunt meerdere bestandssystemen aankoppelen op verschillende mountpoints die beschikbaar zijn voor je applicatie.
Devicemanagement
Zephyr heeft ook een managementsubsysteem waarmee je Zephyr-gebaseerde apparaten beheert. Hiervoor maakt het besturingssysteem gebruik van het opensourceproject MCUmgr, dat oorspronkelijk voor het concurrerende RTOS Apache Mynewt is ontwikkeld. Met de bijbehorende commandlinetool mcumgr beheer je je apparaten via Bluetooth Low Energy, een seriële verbinding (UART) of UDP over IP. Je kunt zo systeemimages bekijken, wissen en uploaden, bestanden downloaden en uploaden, het apparaat herstarten en een shell openen.
Het subsysteem device firmware upgrade (dfu) integreert met de bootloader MCUboot, die oorspronkelijk ook voor Apache Mynewt is ontwikkeld. MCUBoot is een hardware- en besturingssysteemonafhankelijke bootloader voor 32-bitmicrocontrollers. Heb je deze bootloader op een apparaat gezet, dan kun je Zephyr-toepassingen flashen via de seriële herstelmodus van MCUboot. Met MCUboot kun je je applicaties ondertekenen zodat de bootloader alleen updates aanvaardt die door dezelfde geheime sleutel zijn ondertekend.
Aan de slag met voorbeeldapplicaties
Voorbeeldapplicaties
Wil je zelf aan de slag met Zephyr, dan kun je na de installatie van de ontwikkelomgeving het best enkele van de voorbeeldtoepassingen bouwen en op een ondersteund bordje flashen om je wat vertrouwd te maken met het systeem. Het project heeft een uitgebreide collectie voorbeeldapplicaties, van een eenvoudig blink-programma dat een led doet knipperen tot complexe netwerktoepassingen en bluetooth-peripherals.
Wil je bijvoorbeeld het iBeacon-voorbeeld op een nRF52840 Development Kit van Nordic Semiconductor flashen, ga dan naar de Zephyr-directory op je computer en bouw de voorbeeldapplicatie als volgt:
west build -b nrf52840dk_nrf52840 samples/bluetooth/ibeacon
Sluit dan de ontwikkelkit op je computer aan en flash de firmware met de volgende opdracht:
west flash
Daarna is je nRF52840 Development Kit via bluetooth op je telefoon als iBeacon te zien.
Tussen de voorbeelden vind je ook bordspecifieke voorbeeldcode en voorbeelden voor drivers van specifieke hardware, zoals sensoren. Verder zijn er voorbeelden van hoe je een externe bibliotheek of een out-of-tree driver of bordje gebruikt. In de documentatie van elk van de voorbeelden vind je wat de code doet, hoe je de firmware bouwt en wat je kan verwachten van de uitvoer.
Veel van de voorbeeldapplicaties maken intensief gebruik van devicetree overlays en overlayconfiguratiebestanden om ze zo algemeen mogelijk te maken. Zo ondersteunt het voorbeeld Socket Echo Server OpenThread, IEEE 802.15.4, bluetooth IPSP, PPP, tls of IP-tunneling, allemaal via hun eigen overlayconfiguratiebestand.
Voor je eigen toepassingen is het in veel gevallen het eenvoudigst dat je vertrekt van een van de voorbeeldapplicaties die het dichtst bij je toepassing liggen, en daarop voortbouwt. De code vind je in de GitHub-repository van Zephyr en in je lokale kopie van de Zephyr-code.
Waar wordt Zephyr gebruikt?
Zephyr wordt in heel wat opensourceprojecten gebruikt, bijvoorbeeld in de firmware ZMK voor toetsenborden. Er bestaat ook Zephyr-firmware voor de smartwatch PineTime. Hardwarefabrikanten lopen er daarentegen doorgaans niet mee te koop om te veel informatie te geven over hoe ze hun firmware bouwen. Door de permissieve licentie van Zephyr zijn ze ook niet verplicht de broncode te publiceren of zelfs maar te vermelden dat hun code op Zephyr is gebaseerd.
Zephyr is een flexibel en modulair realtimebesturingssysteem voor apparaten die niet krachtig genoeg zijn voor Linux. Er is standaard al veel functionaliteit inbegrepen en de licentie is vriendelijk voor commercieel gebruik.
Bovendien is het project erin geslaagd om in vijf jaar tijd een bloeiende community op te bouwen waarin ook talloze hardwareproducenten een centrale rol spelen. Het is dus goed mogelijk dat Zephyr het succes van Linux kan evenaren.
Dat je voor ARM Linux minstens een Cortex-A nodig hebt is natuurlijk aperte onzin. Zelfs een ARM9 draait moeiteloos de laatste Kernel versie.
Voor Linux is een MMU vereist, omdat het een protected memory model heeft.. En de implementatie van een MMU heeft vaak evenveel chip-oppervlakte nodig als de CPU zelf. De chip wordt daarmee ergens tussen de 50% en 150% groter. Dus duurder. Veel halfgeleiderfabrikanten laten hem op de goedkopere SoCs om die reden achterwege. Dit beperkt de ontwikkelaar in zijn OS keuze, in ruil voor een lagere prijs.
Geen MMU betekent ook geen hardware geheugenbescherming. Verschillende processen hebben toegang tot elkaars geheugen. Voor toepassingen waar het OS met de applicatie mee gecompileerd wordt, is dat geen probleem.
Zephyr OS is dan ook geen concurrent voor Linux. Het is een concurrent voor FreeRTOS. En wat mij betreft een superieure concurrent voor FreeRTOS.
Welke ARM9 is dan meer de vraag. Niet elke ARM9 draait moeiteloos de laatste kernel.
In de ARM9 tijd was het onderscheid iets minder duidelijk.
Daarnaast zijn er ook processoren die zonder MMU ook hardware geheugen bescherming ondersteunen. Die draaien dan ook niet gelijk Linux maar het is allemaal wat minder zwart/wit als jij het stelt.
Ziet er wel goed uit, maar ik maak me toch zorgen over een 30 jaar oud besturingssysteem welke ontwikkeld is in C. Ik ben bang dat je een eindeloze stroom security updates krijgt terwijl het apparaat die deze nodig heeft na een tijd niet meer wordt ondersteund door de fabrikant (kost hen tijd en geld en levert niets op).
TockOS is een veel moderner variant geschreven in Rust maar waar je ook modules in C kan toevoegen. Ook ben ik vanwege de veiligheid een voorstander van micro-kernels en zijn monolithische kernels een te groot risico in het internet tijdperk.
Wel mooi dat DFU ondersteunt wordt, want dat is meestal een ondergeschoven kindje.
Daarnaast vraag ik mij af of processoren niet zo krachtig worden en geheugen zo goedkoop dat het onderscheidt tussen embedded en full-size verdwijnt. Fuchsia van Google zou bijvoorbeeld ook op "embedded" kunnen draaien en dit is een van de best doordachte besturingssystemen die ik ooit gezien heb (behalve het nadeel dat het ook in C is geschreven).
[Reactie gewijzigd door Godson-2 op 31 juli 2024 12:06]
Ik denk dat het juist staat en valt met ondersteuning. Feit dat ze nadenken over LTS en daar dus security / bug-fixes pushen geeft mijn inziens aan dat hier in iedergeval aan gewerkt wordt.
Juist bij "exotische" of minder gebruikte OS'en komen dit soort issues minder snel aan het licht (ken TockOS niet verder).
Feit dat het 30 jaar oud is geeft misschien juist wel wat voordelen omdat er al veel kennis in zit. hoeft in ieder geval niet fout te zijn, daarnaast is ook C zeker geen foute taal. De taal is een middel, en als de owners & community meer bedreven zijn in C vs een andere taal, is de kans op fouten daarin kleiner. Nieuw is niet altijd beter
Daarnaast denk ik ook niet dat monolitisch vs micro per definitie fout is op gebied van veiligheid, fouten kun je overal maken. Hangt af van je developers en community.
Buiten bovenstaande, er is geen wedstrijd dus blijft het per product dat je ontwikkelt je eigen keuze en afweging om voor X of Y te gaan.
Je kan bij micro-kernel besturingssystemen ook fouten maken, maar die hebben qua security geen of weinig impact. Ook bij een fout in de software kan men nog steeds niet inbreken of code uitvoeren.
[Reactie gewijzigd door Godson-2 op 31 juli 2024 12:06]
Ik denk dat je goed moet bedenken dat Zephyr waarschijnlijk bedoeld is voor een andere applicaties dan bijvoorbeeld TockOS en Fuchsia.
Die twee besturingssystemen zijn gebouwd met het kunnen draaien van 3rd party applicaties bovenop het OS. In toepassingen van Zephyr is de applicatie volledig verweven met het OS, het wordt één binary.
Voor de security moet je dan meer kijken naar de hele applicatie en hoe het RTOS geconfigureerd/gebouwd wordt. Security updates voor apparaten met Zephyr zullen praktisch altijd een compleet nieuwe firmware worden.
Wat betreft processorkracht: ik denk dat er altijd een markt is voor zo simpel/goedkoop mogelijke producten. Het heeft weinig meerwaarde om een volledig OS met 3rd party applicaties te kunnen draaien op een hartslagsensor, dus waarom zou je zo'n sensor 1 euro duurder maken?
Ook snap ik niet hoe de programmeertaal invloed zou hebben op de veiligheid van een product? Kun je dat uitleggen?
Ook snap ik niet hoe de programmeertaal invloed zou hebben op de veiligheid van een product? Kun je dat uitleggen?
Het probleem van C is dat het een erg lage programmeertaal is. Er zijn veel redenen waarom het onveilig is. Om te beginnen werkt het met pointer-arithmetic. Dat betekend dat het mogelijk is om zonder controle buiten een array te lezen (buffer overrun / underrun). Tevens is er een probleem met alle variabelen - de implementatie van bijvoorbeeld een int staat niet vast. Er is eigenlijk geen runtime, en geen memory management. Die worden allemaal met functies uitgevoerd, maar dat betekend dus ook dat je memory leaks kan hebben. Vele functies uit bibliotheken zijn niet veilig, wat het maken van een veilige applicatie ook een stuk lastiger maakt. Het gaat allemaal nog veel dieper dan dit, maar als je dingen als stack execution gaat wat ver hier.
Als je er meer over wil weten kijk dan naar deze gratis cursus. Merk op dat alleen de cryptografie en software security cursus van deze "cybersecurity specialization" zich op een goed niveau bevinden.
Merk op dat ik had gehoopt dat statische code analyse de meeste van deze problemen zou oplossen. En hoewel er dagelijks fouten in C-code wordt gevonden met scanning tools zien we tevens dat er nog steeds veel security problemen zoals buffer overruns blijven bestaan. Uiteindelijk is het lastig om een kasteel te bouwen op modder. Niet onmogelijk natuurlijk, maar voor de gewone sterveling een brug te ver.
[Reactie gewijzigd door uiltje op 31 juli 2024 12:06]
Er is eigenlijk geen runtime, en geen memory management.
Hier zit hem de crux denk ik, op een MCU heb je geen runtime en MMU.
Overigens heeft Zephyr op de MCUs met MMU wel de optie om threads voor elkaar te beveiligen.
Je zou in theorie misschien een andere taal kunnen gebruiken, maar in praktijk zijn de toepassingen waarvoor Zephyr gemaakt is té beperkt (qua geheugen en MCU core) om brede ondersteuning in te bouwen voor hogere talen. In de MCU-wereld is C toch wel de meest gebruikte taal en ik denk dat bij de meeste producten in grote aantallen het voordeel in kosten opweegt tegen de extra moeite tijdens de ontwikkeling.
Voorbeeldje is Micropython, die heeft al 256KB ROM nodig om te kunnen draaien. Er zijn genoeg MCUs met maar 128KB mét Zephyr ondersteuning.
Uiteindelijk maken hogere programmeertalen het makkelijker om veilige software te maken, maar het is niet onmogelijk in C veilige software te maken. Het is alleen lastiger.
Mja, maar talen als Rust en Golang bieden wel dit soort geheugenbeveiliging, goed gedefinieerde variabele typen, veilige bibliotheken enzovoort. En ze zijn gewoon volledig gecompileerd. Python en Java (ik was Java Card developer) zijn niet echt geschreven als veilige vervangers.
Overigens krijg ik altijd weer tranen in mijn ogen als ik zie dat veel embedded C developers nog steeds niet met statische code analyzers werken (en fuzz testing etc.). Dat je een onveilige taal gebruikt is tot daar aan toe maar gebruik dan tenminste de security tools die je dat beetje extra zekerheid kunnen bieden.
[Reactie gewijzigd door uiltje op 31 juli 2024 12:06]
Ik ken in mijn vakgebied ook genoeg 'cowboys' wat dat betreft en ik ben ook zeker voorstander van alles wat je noemt.
De Zephyr code heeft wel statische code analyse en fuzz testing, dus beveiliging is alles behalve een ondergeschoven kindje.
Het heeft weinig meerwaarde om een volledig OS met 3rd party applicaties te kunnen draaien op een hartslagsensor, dus waarom zou je zo'n sensor 1 euro duurder maken?
Ik kan me voorstellen dat een zo laag mogelijk energieverbruik en een zo klein mogelijk apparaat bij een hartslagsensor belangrijkere criteria zijn om voor zo'n beperkte processor te kiezen dan de prijs.
Dat maakt weinig uit. Veel Windows Embedded machines draaien ook maar een kiosk applicatie en toch zit er een compleet server besturingssysteem in. Idem Linux.
Processoren worden zo krachtig en geheugen zo goedkoop dat het niet meer zinvol is om niet een full-size besturingssysteem te gebruiken. Er zitten ook schaalvoordelen om besturingssystemen te gebruiken die in miljarden apparaten zitten. Kijk maar naar Windows Embedded en Linux.
Excuus, maar voor een kiosk-systeem heb je al een redelijke stack nodig, dat is niet ver verwijderd van een volledig OS. Dit OS gaat minder naar de richting van een kiosk, en meer naar een wifi/bluetooth/ZigBee-lamp of sensor. Daar wil je om meerdere redenen (niet alleen kosten, ook grootte, hitte en verbruik) geen grotere CPU en resources dan nodig.
En ik betoog dat dit onderscheid steeds kleiner wordt. Veel krachtige microcontrollers kunnen al Linux draaien en verbruiken, omdat ze steeds kleinere proces structuren hebben, net zo weinig stroom. Een 8-bits controller is tegenwoordig net zo duur en soms zelfs duurder dan een 32-bit ARM controller.
Als je een TCP/IP stack wil hebben dan ga je toch al meestal richting een full-size systeem, want je wil dan ook hogere protocollen, JSON, USB, FAT, threads en goede ontwikkeltools zoals GDB en Make die al decennia lang op Unix systemen draaien. Ja, Zephyr kan dit ook, maar waarom weer een ander besturingssysteem ondersteunen als je ook Linux kan gebruiken welke al op miljarden devices draait?
En dat stroomverbruik klopt dus gewoon niet. Er zijn microcontrollers (overigens nog steeds veel goedkoper dan wat er in zelfs de eerste Pi zit) die echt duizendsten van de standby-stroom verbruiken van een chip die Linux kan draaien. En als je een standalone chip hebt die Zigbee regelt, hoef je die alleen in leven te hebben als er iets gebeurt. JSON, USB, FAT, threads, en TCP/IP zijn dan echt overbodig,
Er zullen misschien processoren zijn die een ultra-low power OS nodig hebben zoals Zephyr maar ik betoog dat dit er procentueel steeds minder zullen zijn. Men wil gewoon steeds meer features toevoegen en op een gegeven moment is het handiger om een full-size OS te gebruiken.
En als je echt ultra-low power wil dan kan je je afvragen of je überhaupt wel een besturingssysteem nodig hebt en niet gewoon rechtstreeks op de hardware wil draaien.
Een volledig OS zoals Windows / Linux is een compleet andere toepassing, het zijn niet eens concurrenten.
Zephyr is te gebruiken op systemen met een kostprijs vanaf 1 dollar, een goed voorbeeld is een Ikea tradfri lamp die te koop is voor 7 euro.
Als ik jouw retoriek gebruik, dan zal diezelfde lamp 15 euro kosten, meer energie verbruiken, trager opstarten en groter worden qua formaat.
Apparaten gaan over het algemeen veel langer mee dan de software ondersteund wordt. Als je een twintig jaar oud computergestuurd apparaat hebt dan moet dit gewoon veilig zijn no matter what.
Wat mij betreft slopen ze gewoon de internet verbinding er gewoon helemaal uit of moet er een fysieke "kill switch" zijn om deze uit te zetten.
[Reactie gewijzigd door Godson-2 op 31 juli 2024 12:06]
Laat ik beginnen met zeggen dat ik hiervoor nog nooit van Zephyr had gehoord dus misschien heb ik geen recht van spreken.
In het artikel wordt vermeld dat het oorspronkelijke project uit 1991 stamt, waarschijnlijk vandaar die 30 jaar die @DaWaN noemde Hoeveel van die 30 jaar oude code nog terug te vinden is in Zephyr en in hoeverre die code nog achterloopt op de huidige stand van zaken of dat Zephyr van de grond af aan opnieuw is opgebouwd in 2016 zou ik natuurlijk niet weten, misschien dat jij daar iets meer over weet?
Ik zou het wel interessant vinden als Zephyr dan vergeleken wordt met dus een free-RTOS, of een Mbed-OS. Hoe verhoudt een identiek programma (qua functionaliteit) zich tussen die qua snelheid, en vooral ook qua geheugen/opslag gebruik.
En begrijp ik het goed dat dan veel devices, zoals een BME280, ondersteund worden in het OS zelf? Dus niet met een externe library die je toevoegt?
Ik denk dat Zephyr meer biedt dan FreeRTOS.
FreeRTOS is vooral het RTOS zelf, bij Zephyr krijg je veel meer: een HAL, buildsysteem, alle drivers, devicetree, modules, etc. Volgens mij zit er ook een driver in voor de BME280 ja.
Mbed-OS geen ervaring mee, maar aangezien dat gemaakt wordt door ARM zal het lastig zijn om te draaien op bijvoorbeeld RISC-V MCUs.
Ik ben zelf embedded firmware ontwikkelaar en ik heb ook Zephyr gebruikt voor een product met een nRF52 met BLE.
Ik moet zeggen dat ik erg onder de indruk ben van het geheel, je kunt zeer snel en gemakkelijk zelf een firmware bouwen. Ook het toevoegen van extra drivers en/of modules is eenvoudig.
Het feit dat Nordic Semiconductor het volledig omarmd heeft voor hun ontwikkelomgeving betekend dat het nu veel momentum oppakt. Overigens gebruikt de gemiddelde applicatie in de Nordic ontwikkelomgeving ook nog een aardig brok Nordic-specifieke code die niet uit de Zephyr repo komt. Als andere fabrikanten het willen gebruiken zullen ze waarschijnlijk ook redelijk wat IP-gevoelige code (o.a. BLE stacks) graag in eigen beheer houden zoals Nordic.
Ik ben benieuwd of andere fabrikanten het ook gaan omarmen, dan kan Zephyr inderdaad wel eens het meest dominante RTOS voor microcontrollers worden.
Het RTOS is overigens wél de kern van het project, maar ik denk dat uiteindelijk de kracht van Zephyr voornamelijk in het totaal plaatje zit: open-source (tooling), het build- en configuratiesysteem en de kwaliteit van de code/documentatie.
Nou dat is maar goed ook.
Moet je toch niet aan denken dat je die puinhoop naar je microcontroller haalt. In de browser proberen we er juist vanaf te komen (typescript / webassembly).
Zelf de uitvinder van JavaScript heeft sorry gezegd over z'n eigen taal. Dat soort zelfreflectie kan ik daarentegen wel waarderen.
Ik denk dat in het verkeerde blokje aan het typen was. Ik kan me ook niet voorstellen dat je JavaScript op een embedded controller wil draaien. Doe dan Python of Kotlin als je een veiliger high level alternatief wil bieden en Rust of Golang voor de snelle afhandeling van native code.
Dan zou ik geen abonnement nemen en deze artikelen niet lezen? Of bedoel je de waarde van dit artikel? Ik vind telkens de kritiek op plus over plus om plus een beetje afgezaagd worden.
Ik vind het wel informatief met name omdat ik vaak alleen maar lees over kwetsbaarheden in iot en dit toch een beter beeld geeft wat de toekomst kan brengen. En dat niet alleen gekeken wordt naar wat kan naar hoe het veilig kan.
Als dit een soort standaard of basis wordt zijn we beter af dan wanneer iedere fabrikant zelf iets in elkaar knutselt.
Edit: zin toegevoegd ter verduidelijking
[Reactie gewijzigd door gaskabouter op 31 juli 2024 12:06]
Het is zeker interessant om te lezen, dat er een standaard is en dat er aan security gedacht wordt.
Maar krijg vooral de indruk, dat dit artikel een vertaling is van de website met wat extra woorden om het plus waardoor te maken.
/off-topic
Dan zou ik geen abonnement nemen en deze artikelen niet lezen?
Laat ik het zo zeggen, af en toe hoop ik op een hoogwaardig artikel. Wat mij doet inzien, dat ik aan 3 gratis artikelen niet genoeg heb
Als je als hobbyist een toepassing voor Zephyr wil maken, zoals een printje dat wat relais aanstuurt, ben je dan gebonden aan programmeren in C? Of ondersteunt dit systeem ook bijv. Python of een andere (meer toegankelijke) taal?
[Reactie gewijzigd door pmeter op 31 juli 2024 12:06]
Mooi dat het zo weinig resources gebruikt, deed linux ook tig jaar geleden…
Heel wat iot-apparaten zijn voorzien van Linux als besturingssysteem, maar dat heeft minimumeisen. Voor Arm-processoren heb je bijvoorbeeld al minstens een Cortex-A nodig. Voor meer gelimiteerde chips zoals een Cortex-M is een realtime besturingssysteem zoals Zephyr beter geschikt. Een typisch apparaat waarop Zephyr draait heeft een microcontroller met een klokfrequentie lager dan 100MHz
Mijn eerste kennismaking met linux was op een 25Mhz 386 met wel 2 hele megabytes aan ram en wel 30 MB aan harde schijf
Zo’n cortex M draait daar rondjes om..
Maar goed, interessant systeem
Klopt, de Flops zijn er ondertussen wel al, maar storage is vak toch beperkt in vergelijking met toen. Een handvol KB Ram, en meestal maar 512kb of 1mb rom.
/i/2004908512.png?f=imagenormal)
/i/2004908514.png?f=imagenormal)
/i/2004908516.png?f=imagenormal)
:strip_exif()/i/2004908518.jpeg?f=imagenormal)
:strip_exif()/u/28891/avatar.gif?f=community){kind=avatar}
/u/238475/crop5db01b7054bdf_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/200845/crop6707a73aa05be_cropped.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/68763/wielGoT.jpg?f=community){kind=small}
/u/1830/acm.png?f=community){kind=small}
/u/381607/have%2520a%2520nice%2520day%2520-%2520small.png?f=community){kind=small}
/u/581347/crop64beea7e7f624_cropped.png?f=community){kind=small}
Hoeveel van die 30 jaar oude code nog terug te vinden is in Zephyr en in hoeverre die code nog achterloopt op de huidige stand van zaken of dat Zephyr van de grond af aan opnieuw is opgebouwd in 2016 zou ik natuurlijk niet weten, misschien dat jij daar iets meer over weet?
:strip_icc():strip_exif()/u/145751/check-in-minion-small2.jpg?f=community){kind=small}
/u/107677/linuxmintlogo60.png?f=community){kind=small}
:strip_exif()/u/47900/baph.gif?f=community){kind=small}
:strip_exif()/u/44206/poes.gif?f=community){kind=small}