FreeRTOS vs. Zephyr Open-Source-Betriebssysteme für ressourcenlimitierte Geräte

Von Jan Altenberg* Lesedauer: 8 min |

Anbieter zum Thema

FreeRTOS ist der Platzhirsch unter den freien Betriebssystemen für Geräte mit limitierten Ressourcen. Der im Moment am stärksten wachsende Rivale ist Zephyr. Was sind die Unterschiede?

Zephyr: Das ist der Name einer griechischen Windgottheit. Dies inspirierte die Promotoren des gleichnamigen RTOS vermutlich dazu, einen Kinderdrachen im Logo zu verwenden.
Zephyr: Das ist der Name einer griechischen Windgottheit. Dies inspirierte die Promotoren des gleichnamigen RTOS vermutlich dazu, einen Kinderdrachen im Logo zu verwenden.
(Bild: Vogel Communications Group)

Unter den Vertretern freier Betriebssysteme für ressourcenlimitierte Geräte genießt FreeRTOS unbestritten den größten Bekanntheitsgrad und erfreut sich in der Industrie großer Beliebtheit. Das Projekt kann mittlerweile auf eine knapp zwanzigjährige Geschichte zurückblicken. Die Entwicklung begann 2003 mit den Arbeiten von Richard Barry und wurde in den folgenden Jahren von dessen Firma Real Time Engineers Ltd. weitergeführt.

Die FreeRTOS Community ist seit dieser Zeit stetig gewachsen, und das Projekt erschließt sich neben den klassischen Industrieanwendungen immer neue Anwendungsfelder, wie z.B. vernetzte Sensoren und andere Produkte im IoT-Umfeld. Diese neuen Einsatzgebiete sind vermutlich auch Folge einer im Jahre 2017 vorgenommenen Änderung in der Projektorganisation und einer damit verbundenen Umlizenzierung. Damals hat die Firma Amazon Web Services (AWS) die Rechte an FreeRTOS erworben und ab Version 10 statt der GPL-2.0 mit der sogenannten FreeRTOS Exception 2.0 auf die permissive MIT-Lizenz umgestellt.

Die ursprünglich verwendete FreeRTOS Exception ermöglichte es zwar, Anwendungen, die FreeRTOS lediglich über das API-Interface verwenden und selbst kein RTOS darstellen, unter eine eigene Lizenz zu stellen. Allerdings mussten Änderungen und Erweiterungen des FreeRTOS-Codes wegen des Copylefts der GPL-2.0 natürlich auch wiederum unter diese Lizenz gestellt werden, und außerdem enthielt die Exception die Einschränkung, dass Benchmarking-Ergebnisse nur mit schriftlicher Genehmigung der Firma Real Time Engineers Ltd. Veröffentlicht werden durften. Alle diese Einschränkungen entfielen nach der Umstellung auf die MIT-Lizenz.

Einfachheit und Flexibilität

Wer sich mit FreeRTOS auseinandersetzt, der muss zunächst die Projektstruktur verstehen. Ein grundlegendes Designkonzept des Projektes ist Einfachheit und Flexibilität. Diesem Konzept folgend besteht FreeRTOS aus einem schlanken Betriebssystemkern, der mittels Bibliotheken um Treiber und zusätzliche Funktionalität für den jeweiligen Anwendungsfall angepasst werden kann. Diese Aufteilung spiegelt sich auch in der Struktur der Projektrepositories wider:

Bild 1: Die Struktur der FreeRTOS Repositories
Bild 1: Die Struktur der FreeRTOS Repositories
(Bild: OSADL)

Bild 1 zeigt exemplarisch die Struktur und das Zusammenspiel der einzelnen Komponenten. Die wichtigsten Repositories sind auf Github zu finden und dort auf zwei Organisationen verteilt: FreeRTOS und AWS. Ausgangspunkt für die Entwicklung ist das Repository mit dem Namen FreeRTOS (https://github.com/FreeRTOS/FreeRTOS). Dieses beinhaltet den FreeRTOS Kernel und einige zentrale Komponenten. Zusätzliche Bibliotheken werden über den Mechanismus von Git-Submodules dort integriert. Die offiziell mit dem FreeRTOS Projekt verbundenen Bibliotheken werden in unterschiedliche Kategorien eingeteilt:

  • Core-Bibliotheken können auch unabhängig von FreeRTOS verwendet werden.
  • FreeRTOS-Plus-Bibliotheken können nur zusammen mit dem FreeRTOS-Kernel verwendet werden und erweitern diesen um je eine bestimme Funktionalität.
  • Lab-Project-Bibliotheken sind entweder unvollständig oder noch experimentell. Vor der Verwendung sollte immer die individuelle Dokumentation geprüft werden, um den Reife- und Fertigstellungsgrad beurteilen zu können.

FreeRTOS unterstützt eine große Auswahl von Zielsystemen und kann auf einer Vielzahl unterschiedlicher Architekturen verwendet werden. Der echtzeitfähige Kernel kommt mit einem Scheduler, der sowohl kooperatives als auch preemptives Scheduling beherrscht. Auch mit Energiesparfunktionen, wie einem „tickless idle mode“, kann das Betriebssystem aufwarten. Symmetrisches Multiprocessing wird in den offiziellen Repositories ebenfalls unterstützt. Allerdings sollten interessierte Anwender darauf achten, dass diese Funktionalität aktuell noch in einem separaten Branch gepflegt wird.

Für alle unterstützten Zielsysteme existiert ein funktionsfähiges und getestetes Beispiel, das als Basis für eigene Projekte verwendet werden kann. Die oben genannten Bibliotheken bieten ein breites Spektrum an Funktionalität, das von verschiedenen Treibern, Dateisystemen und auch einem Subset der POSIX API bis hin zu unterschiedlichen Netzwerkstacks reicht. Neben den klassischen Funktionen für industrielle Anwendungen finden sich auch immer mehr Erweiterungen, die auf das IoT-Umfeld abzielen, wie z.B. „Over the Air“-Updates.

Für die ersten Gehversuche mit FreeRTOS eignet sich der Quickstart Guide (https://www.freertos.org/FreeRTOS-quick-start-guide.html). Die dort beschriebenen Teilschritte können sogar ohne reale Hardware umgesetzt werden, da bei den oben genannten Beispielen auch ein Demoprojekt für den Emulator Qemu enthalten ist. Wer vor der Entscheidung steht, ein geeignetes Betriebssystem für ein Gerät mit beschränkten Ressourcen auszuwählen, der kann sich auf diesem Wege mit wenig Aufwand einen ersten Eindruck verschaffen.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Zephyr, der Gott des Windes

Zephyr trat zwar erst in den vergangenen Jahren in der Welt der Betriebssysteme in Erscheinung, die darunterliegende Technologie existiert jedoch schon deutlich länger. Die Ursprünge liegen in einem RTOS mit dem Namen Virtuoso, welches Anfang der 2000er Jahre von einem belgischen Unternehmen als Betriebssystem für DSPs entwickelt wurde. Dieses wurde von Windriver Systems übernommen und 2015 unter dem Namen Rocket unter eine Open Source-Lizenz gestellt. Kurze Zeit später wurde Rocket zu einem Collaborative Project der Linux Foundation beigetragen, welches unter dem Namen Zephyr unter der permissiven Apache-2.0 Lizenz veröffentlicht wurde.

Einen Teil dieser Geschichte trägt das Projekt bis heute in seinem Namen: Zephyrus ist einer der altgriechischen Götter der Winde, was unverkennbar auf das ursprünglich dahinterstehende Unternehmen hindeutet. Genauer gesagt handelt es sich um den Gott des Westwindes, was vermutlich auch die Namensgebung für das zentrale Werkzeug zur Entwicklung mit Zephyr erklärt: Dieses trägt den Namen „west“.

SEMINAR-TIPP

Embedded-Linux-Woche

Embedded-Linux-Woche

In den Einsteigerkursen der Embedded-Linux-Woche führen unsere Referenten Sie Schritt für Schritt in die Linux-Welt ein. Die Basis bildet der Grundlagen-Kurs. Im darauf aufbauenden Seminar "Embedded Linux" kann das Gelernte vertieft werden. Erlangen Sie in nur fünf Tagen das notwendige Wissen, um vom Linux-Neuling zum Fortgeschrittenen zu werden!

Weitere Details und Termine

Konzept und Funktionalität von Zephyr

Im zentralen Werkzeug „west“ zeigt sich bereits ein wesentlicher konzeptioneller Unterschied zu FreeRTOS. Während FreeRTOS großen Wert auf Einfachheit und wenige Abhängigkeiten legt, so liegt der Fokus bei Zephyr auf einem höheren Abstraktionslevel und einfacher Handhabung bei der Entwicklung. So abstrahiert „west“ unter anderem die Versionsverwaltung, die Buildkonfiguration, den Buildprozess, sowie das Deployment und auch das Debugging. Dieser Abstraktionsgrad ist mit höheren Anforderungen an das Entwicklungssystem verbunden; dennoch kann unter allen gängigen Linux-Distributionen problemlos für Zephyr entwickelt werden.

Auch die Projektstruktur ist sehr unterschiedlich gestaltet. Im Gegensatz zu FreeRTOS befindet sich der komplette Sourcecode von Zephyr in einem Repository. Im Buildprozess wird konfiguriert, welche Funktionalität im erstellten Executable enthalten sein soll. Grundsätzlich gilt: Wer bereits für Linux entwickelt hat, dem wird die Einarbeitung in Zephyr sehr leichtfallen. Viele zentrale Konzepte wurden in Anlehnung an Linux umgesetzt. So basiert der Buildprozess auf dem auch für den Linuxkernel verwendeten Buildsystem Kconfig und die Beschreibung der Hardware erfolgt per Devicetree. Aufgrund dieser und vieler anderer Ähnlichkeiten wird Zephyr sehr häufig auch als der kleine Bruder des Tux bezeichnet.

Zephyr unterstützt ein breites Spektrum an Architekturen und aktuell existieren im Projekt bereits BSPs für etwas mehr als 400 Zielsysteme. Auch Zephyr bietet für den Einstieg einen Quickstart Guide (https://docs.zephyrproject.org/latest/develop/getting_started/index.html), und genau wie FreeRTOS kann auch Zephyr mit Qemu verwendet werden.

Bei Zephyr handelt es sich um ein echtzeitfähiges, SMP-fähiges Betriebssystem, dessen Scheduler neben kooperativem und preemptivem auch ein Scheduling nach einem „earliest deadline first“ Algorithmus beherrscht. Das Angebot an verfügbaren Treibern ist sehr vielfältig. Neben der im industriellen Umfeld häufig verwendeten Peripherie kann Zephyr mit einer Vielzahl an Funktionen für Konnektivität (Ethernet, WLAN, Bluetooth) und für die unterschiedlichsten Sensoren aufwarten.

Der große Funktionsumfang im Bereich Sensorik und Konnektivität zeigt deutlich auf, dass Zephyr für das IoT-Umfeld entwickelt wurde. Es ist aber nicht darauf beschränkt. Auch für klassische Industrieanwendungen ist Zephyr eine zunehmend interessante Alternative. Die Community und somit auch der Funktionsumfang wachsen stetig. Doch neben den technischen Aspekten ist auch die Projektorganisation von großem Interesse.

Permissive Lizenzmodelle, die bei kleinen Betriebssystemen aufgrund der engen Verbindung zwischen Betriebssystem und Applikation häufig zum Einsatz kommen, sind für Open Source-Projekte mit einem gewissen Risiko verbunden: Weiterentwicklungen werden seltener geteilt, und es besteht ebenfalls eine einfachere Möglichkeit zur Weiterentwicklung in rein kommerziellem Rahmen. Mit der Linux Foundation steht eine herstellerunabhängige Organisation hinter der Entwicklung von Zephyr, wodurch die zuvor angesprochenen Risiken minimiert werden. Aufgrund der langen Produktlebenszeiten im industriellen Umfeld, und der damit verbundenen Tragweite bei der Auswahl eines geeigneten Betriebssystems, ist dies ein nicht unwesentlicher Aspekt.

Heterogene Systeme

Bild 2: Die Anwendungsbereiche von Linux, Zephyr und FreeRTOS
Bild 2: Die Anwendungsbereiche von Linux, Zephyr und FreeRTOS
(Bild: OSADL)

Sowohl FreeRTOS als auch Zephyr sind ganz klar für den Einsatz auf Geräten mit limitierten Ressourcen gedacht. Bei der Auswahl eines Open Source-Betriebssystems stellen diese also eine Alternative für die Systeme dar, auf denen Linux aufgrund der zu hohen Systemanforderungen nicht verwendet werden kann. Doch neben den klassischen Mikroprozessoren, die auf kleinen und auf Kleinstsystemen zum Einsatz kommen, bieten beide RTOSe auch Unterstützung für Applikationsprozessoren. Somit ergibt sich sogar eine Überschneidung mit Systemen, auf denen auch Linux zum Einsatz kommen kann. Bild 2 zeigt eine vereinfachte Darstellung der Bandbreite unterstützter Architekturen und die angesprochene Überschneidung.

Nun stellt sich die Frage, warum auf komplexen Applikationsprozessoren ein kleines RTOS wie Zephyr oder FreeRTOS verwendet werden soll, wenn sich der Einsatz von Linux doch viel komfortabler gestaltet. Die zunehmende Verbreitung von Multicoresystemen liefert die Antwort darauf: Auf Mehrkernsystemen ist es nicht unüblich, einzelne Kerne für einen bestimmten Zweck zu isolieren, oft nur für eine simple Aufgabe, wie z.B. die Verarbeitung eines hochfrequenten Signals.

Für manche Anwendungsbereiche ist eine Isolation auf Betriebssystemebene ausreichend. Doch gerade bei echtzeitkritischen Anwendungen mit sehr schnellen Reaktionszeiten ist es oft notwendig, ein System mit einem Hypervisor zu partitionieren. Wer innerhalb des Hypervisors allerdings direkt auf einem isolierten Core arbeitet, der muss sich auch mit der kompletten Komplexität moderner Applikationsprozessoren auseinandersetzen.

Bild 3: Zephyr und FreeRTOS als Gastsystem im Hypervisor
Bild 3: Zephyr und FreeRTOS als Gastsystem im Hypervisor
(Bild: OSADL)

Und genau hier kann der Einsatz von kleinen Betriebssystemen wie Zephyr und FreeRTOS von Interesse sein. Sie vereinfachen die Umsetzung der notwendigen Funktionalität, benötigen aber kaum Ressourcen und können sehr schnell auf externe Ereignisse reagieren. Bild 3 zeigt exemplarisch ein solches Szenario, umgesetzt mit dem Open Source-Hypervisor Jailhouse (https://github.com/siemens/jailhouse).

Zusammenfassung

Open-Source-basierte Betriebssysteme gewinnen auch im Bereich ressourcenbeschränkter Geräte immer mehr an Bedeutung. Neben der klassischen Anwendung auf Mikrocontrollern kommen diese Systeme auch zunehmend auf modernen Mehrkernprozessoren in Kombination mit einem Hypervisor zum Einsatz. Zu den etablierten Betriebssystemen wie FreeRTOS gibt es eine steigende Anzahl an Alternativen.

Das im Moment am stärksten wachsende Projekt in diesem Umfeld dürfte Zephyr sein. Aufgrund der üblicherweise permissiven Lizenzierung kleiner Betriebssysteme ist nicht nur die Funktionalität, sondern auch die Projektorganisation und die Steuerung der Weiterentwicklung ein wichtiger Aspekt, der bei der Auswahl in Betracht gezogen werden sollte. (jw)

* Jan Altenberg ist zuständig für Compliance und Technologie beim Open Source Automation Development Lab (OSADL) eG in Heidelberg. Der erfahrene Linux-Experte hält zudem Vorträge und Seminare auf dem ESE Kongress und anderen Veranstaltungen.

Artikelfiles und Artikellinks

(ID:49056832)