Neues Echtzeitbetriebssystem embOS-Ultra

RTOS – Energiesparen ohne System-Tick

28. März 2022, 6:00 Uhr | Von Frank Riemenschneider
Real Time Operating embOS-Ultra mit einen völlig neuen Ansatz für das Scheduling. Gegenüber herkömmlichen RTOS zählt neben höherer Präzision der energieeffizientere Betrieb – quasi per Default
© everythingpossible/adobe.stock.com

Fast 40 Jahre nach der Vorstellung des ersten RTOS für Embedded-Systeme stellt Segger Microcontroller mit embOS-Ultra einen völlig neuen Ansatz für das Scheduling vor. Zu den Vorteilen gegenüber herkömmlichen RTOS zählt neben höherer Präzision der energieeffizientere Betrieb – quasi per Default.

In der Embedded-Welt, in der die Forderung nach »harter« Echtzeit eher die Regel als die Ausnahme ist, hat sich der Einsatz eines Echtzeitbetriebssystems (RTOS) mehr und mehr durchgesetzt. Der Grund hierfür ist einfach: Untersuchungen im Software Engineering haben bereits Ende der 80er-Jahre ergeben, dass die höchste Produktivitätssteigerung in der Softwareentwicklung durch Wiederverwendung erreicht werden kann.

Schon bei einer vergleichsweise einfachen Anwendung wie der Steuerung einer Waschmaschine müssen Temperaturen und Drücke gemessen und Motoren und Pumpen angesteuert werden. Eine Umsetzungsmöglichkeit ohne RTOS ist die sogenannte Super-Loop-Programmierung – auch bekannt als »Bare-Metal-Programmierung«. Hierbei wird kein Betriebssystem eingesetzt und die Programmstruktur ist recht einfach: In der main()-Funktion werden alle Variablen, Treiber, Bibliotheken usw. eingerichtet und anschließend eine oder mehrere periodische Aufgaben in einer while-Schleife ausgeführt (Bild 1).

Anbieter zum Thema

zu Matchmaker+
Bei der Super-Loop-Programmierung gibt es kein Betriebssystem. In der main()-Funktion werden eine oder mehrere periodische Aufgaben in einer while-Schleife ausgeführt
Bild 1. Bei der Super-Loop-Programmierung gibt es kein Betriebssystem. In der main()-Funktion werden eine oder mehrere periodische Aufgaben in einer while-Schleife ausgeführt.
© Segger Microcontroller

Externe Ereignisse müssen auf der Interrupt-Ebene des Prozessors programmiert werden, die mit Funktionen aus der Hauptschleife über globale Variablen kommuniziert. Es gibt immer Abhängigkeiten zwischen Daten, Zeit, Funktionen und Prioritäten. Ein großes Problem tritt auf, wenn Programmteile aus der Hauptschleife erweitert werden, dann ändert sich nämlich das Zeitverhalten der ganzen Applikation. Auch ein Programm prioritätsorientiert abzuarbeiten, ist mit diesem Ansatz schwer.

Kommt es zu Störungen in einer Funktion sind alle anderen Funktionen mitbetroffen, das System ist daher sehr fehleranfällig. Weitere Nachteile sind Rechenzeitverlust durch Polling und fehlendes Multitasking, da ein Eingriff in den Programmablauf nur durch Interrupts möglich ist.

Natürlich gibt es noch weitere Herausforderungen wie die händische Verwaltung von Ressourcen z.B. von Timern, Schnittstellen, Speicher und Rechenzeit, die ja allesamt geteilt werden müssen.

Vorteile der Nutzung eines RTOS

Durch den Einsatz eines RTOS werden die beschriebenen Nachteile beseitigt, da sich das Betriebssystem um all diese Aufgaben wie z.B. das Ressourcenmanagement kümmert. Die Anwendung wird vom Programmierer in sogenannte Threads aufgeteilt, wodurch ein hohes Maß an Modularität erreicht wird. Aufgaben, die mit unterschiedlicher Priorität ablaufen sollen, werden als getrennte Threads realisiert (Bild 2).

 Bei einem RTOS wird das Programm in Threads aufgeteilt. Aufgaben, die mit unterschiedlicher Priorität ablaufen sollen, werden als getrennte Threads realisiert
Bild 2. Bei einem RTOS wird das Programm in Threads aufgeteilt. Aufgaben, die mit unterschiedlicher Priorität ablaufen sollen, werden als getrennte Threads realisiert.
© Segger Microcontroller

Jeder Thread hat zu jedem Zeitpunkt einen bestimmten Zustand. Die drei grundlegenden Zustände sind:

  • Running: Der Thread wird ausgeführt. Auf einem Single-Core-Mikrocontroller kann zu einem bestimmten Zeitpunkt natürlich nur ein Thread im Running-Zustand sein, da es ja nur eine CPU gibt.
  • Ready: Die Tasks im Ready-Zustand sind laufbereit und warten auf die Zuteilung der CPU.
  • Waiting: Die Tasks sind momentan nicht laufbereit. Erst wenn bestimmte Ereignisse eingetreten sind, wie z. B. Daten verfügbar sind oder ein bestimmter Zeitpunkt erreicht wurde, werden die Threads Ready.

Die zentrale Schaltstelle des RTOS ist der Scheduler. Er bestimmt, welcher Thread wann die CPU zugeteilt bekommt. Alle Threads sollen oder müssen vor Ablauf ihrer Frist ausgeführt werden. Die Frist ist dabei die maximal zulässige Zeit, die vom Eintreffen eines Ereignisses bis zur Beendigung der dazugehörenden Funktion vergehen darf, ohne dass es zu Problemen – welcher Art auch immer – kommt.

Threads können quasi gleichzeitig ausgeführt werden, auch wenn das Embedded-System, auf dem sie laufen, nur eine einzige CPU hat. Dies geschieht auf eine von zwei Arten: Zeitscheibenverfahren oder prioritätsgesteuertes Scheduling. Die meisten RTOS, wie beispielsweise Seggers embOS, erlauben es, beide Arten des Schedulings zu kombinieren.

Zeitscheiben- und prioritätsgesteuertes Scheduling

In einem Zeitscheibensystem, auch bekannt als »Round-Robin«-Scheduling-System, werden alle Threads, die zur Ausführung bereit sind, für eine bestimmte Zeit (die Zeitscheibe) ausgeführt. Danach wird der nächste Thread für eine bestimmte Zeitspanne – in der Regel die gleiche Zeitspanne – ausgeführt. Auf diese Weise teilen sich alle Threads die CPU gleichmäßig. Eine Zeitscheibe dauert in der Regel 1 ms oder ein Vielfaches davon.

Der Nachteil des Zeitscheibenverfahrens besteht darin, dass die Ausführung einer bestimmten Aufgabe mehrere Zeitscheiben, d.h. einige Millisekunden oder sogar Dutzende von Millisekunden, in Anspruch nehmen kann. Dies mag zwar für einige Dinge wie die Benutzeroberfläche (UI) unkritisch sein, der Nutzer wird eine Verzögerung von z.B. 10 ms bei der Antwort nicht bemerken. Für einen Netzwerk-Stack, der in einem separaten Thread arbeiten kann, kann sich eine solche Verzögerung jedoch kritisch auswirken. Wenn der Netzwerkstapel so viel Zeit für die Reaktion benötigt, kann er seine Aufgabe möglicherweise nicht erfüllen.

Die Lösung hierfür ist das prioritätsgesteuerte Scheduling, bei dem zeitkritischere Tasks in der Regel eine höhere Priorität haben als weniger zeitkritische Tasks. In diesem Beispiel hätte der UI-Task eine niedrigere Priorität als der Netzwerk-Task. Der Netzwerk-Task kann auf diese Weise auf ein Ereignis warten. Das Ereignis kann durch einen Interrupt in der Interrupt Service Routine (ISR) ausgelöst werden, wenn ein Datenpaket empfangen wurde. Dies ermöglicht es dem RTOS, den Netzwerk-Task sofort zu aktivieren, der dann das eingehende Paket sofort verarbeiten und darauf reagieren kann.

Ein weiterer nicht zu unterschätzender Vorteil beim Einsatz eines RTOS ist die Hardwareabstraktion: Gerade jetzt in der Chipkrise ist die Bedeutung der Portierbarkeit von Programmcode von einer Hardwareplattform auf eine andere deutlich sichtbar geworden. Bei Eigenentwicklungen ist man – unabhängig vom höheren Entwicklungs- und Wartungsaufwand – auf einen bestimmten Mikrocontroller festgelegt, Betriebssysteme wie z. B. Seggers embOS unterstützten dagegen fast 1.000 unterschiedliche Mikrocontroller, sodass man sehr einfach den Mikrocontroller wechseln kann, ohne den Programm-Code verändern zu müssen [1].


  1. RTOS – Energiesparen ohne System-Tick
  2. RTOS-Revolution Cycle Resolution Scheduling

Verwandte Artikel

SEGGER Microcontroller GmbH & Co. KG