FreeRTOS und Echtzeit-Software

Das Wichtigste in Kürze

Was ist FreeRTOS?

FreeRTOS ist ein Echtzeitbetriebssystem für Mikrocontroller und Embedded-Systeme. Es stellt grundlegende Mechanismen bereit, um mehrere Software-Aufgaben auf einem Mikrocontroller zu organisieren. Dazu gehören Tasks, Scheduler, Queues, Semaphoren, Timer und Mechanismen zur Synchronisation zwischen Programmbestandteilen. Ein Mikrocontroller führt dabei weiterhin nur die Instruktionen aus, die seine Hardware erlaubt. FreeRTOS sorgt jedoch dafür, dass diese Ausführung nicht als einzelner unstrukturierter Programmablauf organisiert werden muss, sondern in getrennte Aufgabenbereiche aufgeteilt werden kann.

In einem typischen Embedded-System entstehen schnell mehrere parallele Anforderungen. Ein Sensor muss in festen Abständen ausgelesen werden. Eine Kommunikation über UART, SPI, I²C, CAN, Ethernet oder eine andere Schnittstelle muss Daten empfangen und senden. Eine Steuerlogik muss Zustände bewerten und Ausgänge setzen. Eine Bedienoberfläche oder Diagnosefunktion muss auf Benutzereingaben oder externe Anfragen reagieren. Ohne ein Betriebssystem werden solche Funktionen oft in einer Hauptschleife, Interrupt-Service-Routinen und Zustandsautomaten kombiniert. Das kann für kleine Programme ausreichen. Mit wachsender Funktionszahl wird jedoch schwerer nachvollziehbar, welche Aufgabe wann ausgeführt wird und welche Funktion eine andere blockiert.

FreeRTOS schafft hierfür eine technische Struktur. Jede Aufgabe kann als Task modelliert werden. Eine Task kann beispielsweise Messwerte erfassen, eine andere Task kann Kommunikationsdaten verarbeiten, eine weitere Task kann eine Regelung oder Steuerentscheidung ausführen. Der Scheduler entscheidet anhand der Prioritäten und Zustände der Tasks, welche Aufgabe gerade CPU-Zeit erhält. Dadurch wird die Software in Einheiten gegliedert, die fachlich und technisch besser voneinander getrennt werden können.

Für Projekte bedeutet das nicht, dass FreeRTOS automatisch jedes Timing-Problem löst. Die richtige Aufteilung in Tasks, die Wahl der Prioritäten, der Umgang mit Interrupts und die Speicherplanung müssen zum System passen. Eine falsch priorisierte Task kann zeitkritische Abläufe verzögern. Eine blockierende Funktion kann andere Bestandteile an der Ausführung hindern. Eine unklare Datenübergabe zwischen Tasks kann Fehler erzeugen, die nur unter bestimmten Lastsituationen auftreten. PICKPLACE betrachtet FreeRTOS deshalb nicht nur als Bibliothek, die eingebunden wird, sondern als Architekturentscheidung für das Embedded-System.

Zur Arbeit mit FreeRTOS gehört auch die Abgrenzung zwischen Interrupt-Kontext und Task-Kontext. Interrupts werden häufig genutzt, um schnell auf Hardware-Ereignisse zu reagieren, etwa auf einen empfangenen Datenblock, einen Timer-Ablauf oder einen externen Eingang. Die eigentliche Verarbeitung sollte jedoch oft in Tasks verschoben werden, damit Interrupts kurz bleiben und das Systemverhalten nachvollziehbar bleibt. FreeRTOS stellt dafür Mechanismen bereit, mit denen Interrupts Tasks benachrichtigen oder Daten an Queues übergeben können.

Auch Speicher spielt eine zentrale Rolle. Mikrocontroller verfügen häufig über begrenzten RAM und Flash-Speicher. Jede Task benötigt Stack-Speicher. Queues, Puffer und andere Datenstrukturen benötigen ebenfalls Speicher. In FreeRTOS-Projekten muss daher geklärt werden, welche Tasks wirklich notwendig sind, welche Stack-Größen angesetzt werden und wie mit dynamischer oder statischer Speichervergabe umgegangen wird. Diese Fragen sind nicht nur Implementierungsdetails, sondern beeinflussen die Fehlersuche und die Wartbarkeit der Software.

Wann braucht ein Mikrocontroller ein Echtzeitbetriebssystem?

Ein Mikrocontroller braucht ein Echtzeitbetriebssystem wie FreeRTOS nicht in jedem Projekt. Wenn ein Gerät nur eine einfache Funktion ausführt, wenige Eingänge abfragt und keine zeitkritische Kommunikation verarbeitet, kann eine Hauptschleife mit klaren Zustandsautomaten ausreichend sein. Ein Echtzeitbetriebssystem wird dann relevant, wenn mehrere Aufgaben mit unterschiedlichen zeitlichen Anforderungen koordiniert werden müssen und die Software ohne klare Trennung unübersichtlich oder fehleranfällig wird.

Typische Fälle sind Systeme mit Sensorik, Steuerungen, Kommunikation und Messfunktionen. Ein Messgerät kann beispielsweise regelmäßig Daten erfassen, gleichzeitig eine Anzeige aktualisieren und externe Kommunikationsanfragen beantworten. Eine Steuerung kann Eingänge überwachen, Aktoren ansteuern und Diagnosedaten bereitstellen. In solchen Systemen reicht es oft nicht, Aufgaben nacheinander in einer Schleife abzuarbeiten, wenn einzelne Funktionen länger dauern oder auf externe Ereignisse warten. FreeRTOS erlaubt es, wartende Aufgaben zu blockieren und anderen Tasks CPU-Zeit zu geben.

Ein weiterer Grund ist definiertes Reaktionsverhalten. Echtzeit bedeutet nicht, dass ein System besonders schnell sein muss. Entscheidend ist, dass bestimmte Reaktionen innerhalb festgelegter Zeitgrenzen erfolgen. Wenn ein Eingang innerhalb weniger Millisekunden ausgewertet werden muss, wenn ein Kommunikationsprotokoll Zeitfenster vorgibt oder wenn eine Steuerung periodisch mit festem Takt arbeiten soll, muss die Software dieses Zeitverhalten berücksichtigen. FreeRTOS bietet Timer, Task-Prioritäten und Synchronisationsmechanismen, mit denen solche Anforderungen abgebildet werden können.

Auch die Projektgröße kann den Einsatz von FreeRTOS begründen. Wenn mehrere Entwickler an unterschiedlichen Softwarebestandteilen arbeiten, hilft eine Task-Struktur dabei, Zuständigkeiten zu trennen. Eine Kommunikations-Task kann unabhängig von einer Mess-Task weiterentwickelt werden, solange Schnittstellen und Datenübergaben klar definiert sind. Das ersetzt keine Architekturarbeit, schafft aber eine Grundlage, um Funktionen getrennt zu beschreiben, zu testen und zu erweitern.

In Industrieelektronik, Maschinen, Fahrzeugen, Marine-Geräten und militärischen Systemen entstehen häufig Anforderungen an klare Zustände, nachvollziehbare Kommunikation und definierte Reaktionszeiten. In solchen Umgebungen können ungeplante Blockaden, Race Conditions oder Speicherprobleme schwer zu finden sein. FreeRTOS kann helfen, diese Themen systematisch zu bearbeiten, wenn es passend eingesetzt wird. Dabei muss jedes Projekt klären, welche Funktionen zeitkritisch sind, welche nur periodisch laufen, welche Ereignisse sofort behandelt werden müssen und welche Daten zwischen Tasks ausgetauscht werden.

Ein Echtzeitbetriebssystem ist auch dann naheliegend, wenn Kommunikationsschnittstellen neben Steuer- oder Messaufgaben betrieben werden. Kommunikation erzeugt häufig asynchrone Ereignisse: Daten treffen ein, Übertragungen enden, Timeouts laufen ab, Protokollzustände ändern sich. Werden diese Abläufe direkt mit Mess- oder Steuerfunktionen vermischt, kann die Software schwer lesbar werden. Mit FreeRTOS lassen sich Kommunikationsabläufe in eigenen Tasks oder Event-Strukturen organisieren. Dabei muss sorgfältig entschieden werden, wie Puffer verwaltet werden, wie lange Tasks blockieren dürfen und wie Fehlerzustände gemeldet werden.

Gegen den Einsatz spricht, wenn die zusätzlichen Mechanismen mehr Komplexität erzeugen als sie ordnen. FreeRTOS bringt einen Scheduler, Konfigurationsparameter und Laufzeitverhalten mit, das verstanden werden muss. Ein Projekt sollte deshalb nicht allein deshalb auf FreeRTOS setzen, weil mehrere Funktionen vorhanden sind. Es sollte geprüft werden, ob die Aufgaben wirklich parallel koordiniert werden müssen, ob harte oder weiche Zeitgrenzen bestehen und ob die Entwicklerstruktur eine Task-basierte Architektur unterstützt.

Warum nicht selbst schreiben?

Ein eigener Scheduler oder ein selbst entwickeltes Mini-Betriebssystem wirkt in frühen Projektphasen oft überschaubar. Eine Hauptschleife, einige Timer, ein paar Flags und Interrupts reichen zunächst aus, um erste Funktionen zu demonstrieren. Die Komplexität steigt jedoch, sobald Wartesituationen, Prioritäten, Datenübergaben, Timeouts, gegenseitige Ausschlüsse und Fehlerzustände hinzukommen. Viele Eigenentwicklungen beginnen als einfache Ablaufsteuerung und werden später zu einem schwer prüfbaren System aus Sonderfällen.

FreeRTOS bietet erprobte Grundmechanismen für genau diese Aufgaben. Tasks können blockieren, ohne die gesamte Anwendung anzuhalten. Queues können Daten zwischen Tasks übertragen. Semaphoren und Mutexes können Zugriffe auf gemeinsame Ressourcen koordinieren. Software-Timer können wiederkehrende oder verzögerte Aktionen auslösen. Diese Funktionen selbst zu schreiben ist möglich, erfordert aber ein genaues Verständnis von Scheduling, Interrupt-Verhalten, Stack-Nutzung, Speicherzugriffen und Nebenläufigkeit.

Besonders kritisch ist der Umgang mit Nebenläufigkeit. Wenn zwei Programmbestandteile dieselbe Ressource verwenden, etwa einen Kommunikationsbus, einen Speicherpuffer oder eine Zustandsvariable, können Fehler auftreten, die nicht bei jedem Testlauf sichtbar sind. Sie hängen davon ab, welche Aufgabe zu welchem Zeitpunkt unterbrochen wird. Solche Fehler lassen sich ohne klare Synchronisationsmechanismen schwer eingrenzen. FreeRTOS stellt Werkzeuge bereit, um diese Zugriffe zu strukturieren. Die Werkzeuge müssen jedoch richtig eingesetzt werden. Ein Mutex an der falschen Stelle kann Blockaden erzeugen, eine Queue mit falscher Größe kann Daten verlieren, eine zu hohe Priorität kann andere Tasks verdrängen.

Auch Timing-Fragen sprechen gegen eine unkontrollierte Eigenlösung. Ein selbst geschriebener Scheduler muss entscheiden, welche Aufgabe wann läuft. Er muss mit Interrupts umgehen, Wartezeiten abbilden und verhindern, dass langsame Funktionen zeitkritische Abläufe blockieren. In einfachen Systemen kann ein kooperativer Ansatz funktionieren, bei dem jede Funktion regelmäßig zurückkehrt. Sobald eine Funktion jedoch auf externe Daten wartet oder eine längere Berechnung ausführt, wird das Verhalten schwerer vorhersagbar. FreeRTOS ist für solche Szenarien ausgelegt, sofern die Architektur passend entworfen wird.

Ein weiterer Punkt ist die Fehlersuche. Bei einer Eigenentwicklung muss nicht nur die Anwendung, sondern auch die Ablaufsteuerung selbst überprüft werden. Wenn ein Fehler auftritt, ist unklar, ob die Ursache in der Fachlogik, im selbst geschriebenen Scheduler, in einem Interrupt oder in der Speicherverwaltung liegt. Bei FreeRTOS bleibt die Anwendung ebenfalls prüfpflichtig, aber die Grundmechanismen sind klar beschrieben und in vielen Mikrocontroller-Umgebungen verbreitet. Das erleichtert die Eingrenzung, wenn Projektbeteiligte die Konzepte und Konfigurationsoptionen verstehen.

PICKPLACE betrachtet die Frage „FreeRTOS oder eigene Lösung?“ als technische Abwägung. Bei sehr kleinen Systemen kann eine eigene, einfache Struktur sinnvoll sein. Bei Systemen mit mehreren zeitabhängigen Aufgaben, Kommunikation, Sensorik und begrenztem Speicher spricht häufig mehr für FreeRTOS oder ein vergleichbares Echtzeitbetriebssystem. Entscheidend ist nicht der Einsatz eines bestimmten Werkzeugs, sondern die Beherrschbarkeit der Software über den Projektverlauf.

Typische technische Fragestellungen in FreeRTOS-Projekten

Bei FreeRTOS und Echtzeit-Software beginnen viele Projekte mit der Frage, wie die vorhandenen Funktionen auf Tasks aufgeteilt werden. Nicht jede Funktion sollte eine eigene Task werden. Zu viele Tasks erhöhen den Speicherbedarf und erschweren die Priorisierung. Zu wenige Tasks können dazu führen, dass unabhängige Abläufe wieder miteinander vermischt werden. Eine sinnvolle Aufteilung orientiert sich an Zeitverhalten, Datenflüssen, Schnittstellen und Zuständigkeiten.

Die Priorisierung der Tasks ist ein weiterer Arbeitspunkt. Zeitkritische Aufgaben benötigen eine passende Priorität, dürfen aber nicht dauerhaft andere Aufgaben verdrängen. Kommunikations-Tasks müssen auf Ereignisse reagieren können, ohne das System mit Polling zu belasten. Diagnose- oder Hintergrundfunktionen sollten laufen, wenn keine höher priorisierten Aufgaben aktiv sind. Diese Prioritäten lassen sich nicht isoliert festlegen, sondern müssen mit Interrupts, Timern und Blockierverhalten betrachtet werden.

Interrupts müssen so gestaltet werden, dass sie Hardware-Ereignisse aufnehmen, aber keine umfangreiche Verarbeitung übernehmen. In vielen Fällen ist es sinnvoll, im Interrupt nur Daten zu sichern oder eine Task zu benachrichtigen. Die Verarbeitung erfolgt dann im Task-Kontext. Dadurch bleiben Interrupt-Laufzeiten begrenzt und das Systemverhalten wird besser nachvollziehbar.

Speicheranalyse gehört ebenfalls zur Projektarbeit. Jede Task benötigt Stack. Zu kleine Stacks führen zu schwer erkennbaren Fehlern. Zu große Stacks verschwenden RAM, der auf Mikrocontrollern begrenzt sein kann. Zusätzlich müssen Puffer für Kommunikation, Messdaten oder Zustandsinformationen geplant werden. Bei FreeRTOS-Projekten wird deshalb geprüft, welche Speicherbereiche statisch festgelegt werden können, wo dynamische Allokation vermieden oder kontrolliert werden sollte und wie Speicherfehler erkannt werden.

Typische Technologien und Stacks

• RTOS FreeRTOS
• Mikrocontroller STM32F407VG
• IDE STM32CubeIDE
• Debugger SEGGER J-Link
• Protocol Stack lwIP

Unsere Leistungen

PICKPLACE unterstützt Projekte rund um FreeRTOS und Echtzeit-Software durch Software-Entwicklung, das Aufsetzen von FreeRTOS und die Ausarbeitung von Task- und Thread-Management. Dabei geht es nicht nur um die technische Einbindung des Betriebssystems, sondern auch um die passende Struktur für die jeweilige Embedded-Anwendung.

Zu unseren Leistungen gehört die Analyse bestehender Mikrocontroller-Software. Wir prüfen, welche Aufgaben zeitkritisch sind, welche Abläufe blockieren können, welche Interrupts vorhanden sind und wie Daten zwischen Programmteilen ausgetauscht werden. Auf dieser Grundlage kann entschieden werden, ob FreeRTOS sinnvoll ist, welche Architektur passt oder ob eine bestehende Struktur angepasst werden sollte.

Beim Aufsetzen von FreeRTOS kümmern wir uns um die grundlegende Integration in die Embedded-Software. Dazu gehören die Konfiguration des Schedulers, die Anlage erster Tasks, die Einbindung von Timern und die Definition von Kommunikationsmechanismen zwischen Tasks. Die konkrete Ausgestaltung richtet sich nach Mikrocontroller, Peripherie, Speichergrenzen und vorhandener Softwarebasis.

Im Task- und Thread-Management strukturieren wir Funktionen nach Zuständigkeiten und zeitlichem Verhalten. Wir legen fest, welche Aufgaben als eigene Tasks laufen, welche Ereignisse über Queues oder Benachrichtigungen übertragen werden und wo Synchronisation notwendig ist. Dabei wird auch betrachtet, welche Funktionen im Interrupt-Kontext bleiben und welche in Tasks verschoben werden sollten.

PICKPLACE übernimmt außerdem Entwicklungsarbeiten an FreeRTOS-basierten Anwendungen. Dazu können Sensorabfrage, Kommunikationsverarbeitung, Steuerlogik, Messabläufe oder Diagnosefunktionen gehören, soweit sie aus dem Projektkontext hervorgehen. Bestehende Software kann weiterentwickelt, auf eine Task-basierte Struktur umgestellt oder auf Fehler im Zusammenspiel von Tasks, Interrupts und Speicher untersucht werden.

Bei Fehleranalyse und Debugging betrachten wir typische Ursachen in Echtzeit-Software: blockierende Tasks, falsche Prioritäten, Stack-Probleme, unklare Synchronisation, Timing-Abweichungen oder Datenverluste in Kommunikationspfaden. Ziel der Arbeit ist eine nachvollziehbare Eingrenzung der Ursache und eine Änderung, die zum Systemaufbau passt.

Für die Übergabe in die weitere Umsetzung dokumentieren wir die relevanten Architekturentscheidungen. Dazu zählen Task-Aufteilung, Prioritäten, Datenwege, Synchronisationspunkte, Speicherannahmen und bekannte Grenzen. Diese Dokumentation hilft, spätere Erweiterungen oder Fehlersuchen auf einer klaren technischen Grundlage durchzuführen.