Von DerSchneider<\/strong><\/p>\n\n\n\n Einleitung: Der Dirigent im Chaos<\/strong><\/p>\n\n\n\n Im letzten Artikel haben wir die Welt der Bare-Metal-Programmierung erkundet \u2013 die Kunst, mit einer einfachen Super-Loop und geschickt platzierten Interrupts auch komplexe Abl\u00e4ufe zu bew\u00e4ltigen. Doch diese Kunst hat ihre Grenzen. Sobald ein System mehr als ein halbes Dutzend Aufgaben koordinieren muss, sobald Priorit\u00e4ten eine Rolle spielen und Aufgaben miteinander kommunizieren m\u00fcssen, wird der Code schnell un\u00fcbersichtlich, fehleranf\u00e4llig und schwer wartbar.<\/p>\n\n\n\n Hier kommen Echtzeitbetriebssysteme ins Spiel \u2013 Real-Time Operating Systems, kurz RTOS. Sie sind die Dirigenten im Chaos der vielen Aufgaben. Sie \u00fcbernehmen das Scheduling, die Synchronisation und die Kommunikation und erlauben dem Entwickler, sich auf die eigentliche Anwendungslogik zu konzentrieren.<\/p>\n\n\n\n Dieser Artikel f\u00fchrt in die Welt der RTOS ein. Wir lernen die grundlegenden Konzepte kennen, verstehen, wie sich ein RTOS von Desktop-Betriebssystemen unterscheidet, und sehen an Beispielen, wie Tasks, Queues und Semaphoren die Entwicklung komplexer Embedded Systems erleichtern.<\/p>\n\n\n\n Hauptteil<\/strong><\/p>\n\n\n\n 1. Was ist ein RTOS \u2013 und was nicht?<\/strong><\/p>\n\n\n\n Ein Echtzeitbetriebssystem ist ein Betriebssystem, das f\u00fcr Anwendungen mit Zeitbedingungen entwickelt wurde. Es garantiert, dass bestimmte Aufgaben innerhalb vorgegebener Fristen ausgef\u00fchrt werden.<\/p>\n\n\n\n Wichtig: Ein RTOS ist nicht<\/strong> einfach eine abgespeckte Version von Windows oder Linux. Die Unterschiede sind fundamental:<\/p>\n\n\n\n Ein RTOS ist kein Monolith, sondern eine Sammlung von Diensten, die der Entwickler nach Bedarf zuschalten kann. Es passt in wenige Kilobyte Speicher und l\u00e4uft auf Mikrocontrollern, die zu schwach f\u00fcr auch nur einen Linux-Thread w\u00e4ren.<\/p>\n\n\n\n 2. Die Grundbausteine: Tasks<\/strong><\/p>\n\n\n\n Das zentrale Konzept jedes RTOS ist der Task (auch Thread oder Prozess genannt). Ein Task ist eine eigenst\u00e4ndige Ausf\u00fchrungseinheit mit eigenem Stack und eigener Priorit\u00e4t.<\/p>\n\n\n\n Im Gegensatz zur Super-Loop, wo alles in einer einzigen Schleife l\u00e4uft, werden bei einem RTOS die verschiedenen Aufgaben auf mehrere Tasks verteilt:<\/p>\n\n\n\n c<\/p>\n\n\n\n Jeder Task lebt sein eigenes Leben. Der Scheduler entscheidet, welcher Task wann l\u00e4uft \u2013 basierend auf Priorit\u00e4ten und Ereignissen.<\/p>\n\n\n\n 3. Das Herzst\u00fcck: Der Scheduler<\/strong><\/p>\n\n\n\n Der Scheduler ist die wichtigste Komponente eines RTOS. Er entscheidet, welcher Task als n\u00e4chstes die CPU bekommt.<\/p>\n\n\n\n Die g\u00e4ngigsten Scheduling-Verfahren:<\/p>\n\n\n\n Priorit\u00e4tsbasiertes Scheduling:<\/strong> Jeder Task hat eine Priorit\u00e4t. Immer der Task mit der h\u00f6chsten Priorit\u00e4t, der lauff\u00e4hig ist, bekommt die CPU. Das ist einfach und effizient, kann aber dazu f\u00fchren, dass niederpriore Tasks verhungern, wenn hochpriore immer etwas zu tun haben.<\/p>\n\n\n\n Round-Robin:<\/strong> Tasks gleicher Priorit\u00e4t teilen sich die CPU fair, indem sie abwechselnd f\u00fcr eine feste Zeitscheibe laufen. Verhindert das Verhungern, aber weniger deterministisch.<\/p>\n\n\n\n Rate-Monotonic-Scheduling:<\/strong> Eine mathematisch fundierte Methode, bei der Tasks mit k\u00fcrzeren Perioden h\u00f6here Priorit\u00e4ten bekommen. F\u00fcr bestimmte Aufgabenklassen l\u00e4sst sich damit mathematisch beweisen, dass alle Fristen eingehalten werden.<\/p>\n\n\n\n Die meisten RTOS verwenden eine Mischung: priorit\u00e4tsbasiertes Scheduling mit optionalem Round-Robin f\u00fcr gleiche Priorit\u00e4ten.<\/p>\n\n\n\n 4. Kommunikation: Queues und Mailboxen<\/strong><\/p>\n\n\n\n In einem Multitasking-System m\u00fcssen Tasks miteinander kommunizieren. Ein Task produziert Daten, ein anderer konsumiert sie. Daf\u00fcr gibt es Queues (Warteschlangen):<\/p>\n\n\n\n c<\/p>\n\n\n\n Die Queue entkoppelt die Tasks. Der Sensor-Task kann Werte produzieren, auch wenn der Logger-Task gerade besch\u00e4ftigt ist. Die Werte werden zwischengespeichert. Und wenn die Queue voll ist, kann der Sender warten oder einen Fehler melden.<\/p>\n\n\n\n 5. Synchronisation: Semaphoren und Mutexe<\/strong><\/p>\n\n\n\n Wenn Tasks gemeinsame Ressourcen nutzen (z.B. eine serielle Schnittstelle oder einen Speicherbereich), m\u00fcssen sie sich synchronisieren, damit nicht beide gleichzeitig zugreifen.<\/p>\n\n\n\n Bin\u00e4re Semaphore:<\/strong> Ein einfaches Flag, das anzeigt, ob ein Ereignis eingetreten ist. Ein Task wartet darauf, ein anderer signalisiert es.<\/p>\n\n\n\n c<\/p>\n\n\n\n Mutex (Mutual Exclusion):<\/strong> Ein spezieller Semaphor f\u00fcr den Zugriff auf gemeinsame Ressourcen. Er verhindert, dass zwei Tasks gleichzeitig auf dieselbe Ressource zugreifen.<\/p>\n\n\n\n c<\/p>\n\n\n\n Ohne Mutex w\u00fcrden sich die Ausgaben der beiden Tasks wild vermischen. Mit Mutex ist sichergestellt, dass jeder Task die Ausgabe ungest\u00f6rt zu Ende bringen kann.<\/p>\n\n\n\n 6. Zeitdienste: Timer und Delays<\/strong><\/p>\n\n\n\n RTOS bieten auch komfortable Zeitdienste:<\/p>\n\n\n\n Task-Delay:<\/strong> Software-Timer:<\/strong> Timer, die nach Ablauf eine Funktion aufrufen oder einen Task benachrichtigen. N\u00fctzlich f\u00fcr periodische Aktionen.<\/p>\n\n\n\n Timestamp-Dienste:<\/strong> Funktionen, um die vergangene Zeit hochpr\u00e4zise zu messen.<\/p>\n\n\n\n 7. Ein RTOS im Vergleich: FreeRTOS<\/strong><\/p>\n\n\n\n Das mit Abstand am weitesten verbreitete RTOS ist FreeRTOS. Es ist Open Source, extrem portabel, l\u00e4uft auf Dutzenden von Plattformen und ist klein genug f\u00fcr winzige Mikrocontroller.<\/p>\n\n\n\n FreeRTOS bietet:<\/p>\n\n\n\n Ein komplettes FreeRTOS-System passt oft in 5-10 KB Flash und 1 KB RAM \u2013 Platz genug f\u00fcr erstaunlich komplexe Anwendungen.<\/p>\n\n\n\n 8. Die Kosten eines RTOS<\/strong><\/p>\n\n\n\n Ein RTOS ist kein Geschenk. Es hat seinen Preis \u2013 nicht in Geld, aber in anderen Ressourcen:<\/p>\n\n\n\n Speicher:<\/strong> Jeder Task braucht eigenen Stack. Bei vielen Tasks kann das den RAM schnell f\u00fcllen.<\/p>\n\n\n\n CPU-Zeit:<\/strong> Der Scheduler verbraucht Rechenzeit. Bei jedem Taskwechsel, bei jedem Interrupt l\u00e4uft RTOS-Code.<\/p>\n\n\n\n Komplexit\u00e4t:<\/strong> Ein RTOS-System ist schwerer zu debuggen als eine Super-Loop. Task-Wechsel, Priorit\u00e4ten und Synchronisation k\u00f6nnen zu schwer reproduzierbaren Fehlern f\u00fchren.<\/p>\n\n\n\n Determinismus:<\/strong> Obwohl RTOS f\u00fcr Echtzeit gemacht sind, k\u00f6nnen sie durch Priorit\u00e4tsinversion und andere Effekte unvorhersehbares Verhalten zeigen.<\/p>\n\n\n\n 9. Priorit\u00e4tsinversion \u2013 Die RTOS-Falle<\/strong><\/p>\n\n\n\n Ein klassisches Problem in RTOS ist die Priorit\u00e4tsinversion. Stellen Sie sich vor:<\/p>\n\n\n\n Der hochpriore Task H muss warten, bis der mittelpriore Task M fertig ist \u2013 eine Umkehrung der Priorit\u00e4ten.<\/p>\n\n\n\n L\u00f6sung: Priority Inheritance. Wenn ein niederpriorer Task eine Ressource h\u00e4lt, die ein hochpriorer braucht, bekommt der niederpriore kurzzeitig die Priorit\u00e4t des hochprioren. So kann er schnell fertig werden und die Ressource freigeben.<\/p>\n\n\n\n 10. Wann RTOS, wann Bare-Metal?<\/strong><\/p>\n\n\n\n Die Entscheidung ist nicht immer einfach. Hier eine Faustregel:<\/p>\n\n\n\n Bare-Metal<\/strong> ist besser, wenn:<\/p>\n\n\n\n RTOS<\/strong> ist besser, wenn:<\/p>\n\n\n\n Viele Embedded-Entwickler haben beide Ans\u00e4tze im Werkzeugkasten und entscheiden von Projekt zu Projekt.<\/p>\n\n\n\n Fazit und Ausblick<\/strong><\/p>\n\n\n\n Echtzeitbetriebssysteme sind m\u00e4chtige Werkzeuge f\u00fcr komplexe Embedded-Anwendungen. Sie entlasten den Entwickler von der Koordination der vielen Aufgaben und bieten bew\u00e4hrte Mechanismen f\u00fcr Kommunikation und Synchronisation. Tasks, Queues und Semaphoren sind die Grundbausteine, aus denen sich auch anspruchsvolle Systeme bauen lassen.<\/p>\n\n\n\n Doch mit der Macht kommt die Verantwortung. Ein RTOS ist kein Allheilmittel. Es erfordert ein tiefes Verst\u00e4ndnis der Konzepte und der m\u00f6glichen Fallstricke. Priorit\u00e4tsinversion, Deadlocks und Race Conditions sind die Schreckgespenster, die im RTOS-Schrank lauern.<\/p>\n\n\n\n Aber selbst das beste Betriebssystem n\u00fctzt nichts, wenn das Programm Fehler enth\u00e4lt. Wie findet man Fehler in einem System, das keine Tastatur und keinen Bildschirm hat? Wie debuggt man Code, der in Echtzeit auf unsichtbare Hardware zugreift?<\/p>\n\n\n\n Mit dieser Kunst des Debuggens besch\u00e4ftigen wir uns im n\u00e4chsten Artikel.<\/p>","protected":false},"excerpt":{"rendered":" Wenn es komplex wird \u2013 Echtzeitbetriebssysteme (RTOS) f\u00fcr Embedded Systems Von DerSchneider Einleitung: Der Dirigent im Chaos Im letzten Artikel haben wir die Welt der Bare-Metal-Programmierung erkundet \u2013 die Kunst, mit einer einfachen Super-Loop und geschickt platzierten Interrupts auch komplexe Abl\u00e4ufe zu bew\u00e4ltigen. Doch diese Kunst hat ihre Grenzen. Sobald ein System mehr als ein […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[46,26],"tags":[2069],"class_list":["post-2145","post","type-post","status-publish","format-standard","hentry","category-industrie-4-0","category-mit-den-handen","tag-embedded-world"],"_links":{"self":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/2145","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/comments?post=2145"}],"version-history":[{"count":0,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/2145\/revisions"}],"wp:attachment":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/media?parent=2145"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/categories?post=2145"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/tags?post=2145"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\n\n\n
\n\n\n\nMerkmal<\/th> Desktop-OS (Windows, Linux)<\/th> RTOS (FreeRTOS, Zephyr)<\/th><\/tr><\/thead> Ziel<\/td> Durchschnittlicher Durchsatz<\/td> Garantierte Reaktionszeiten<\/td><\/tr> Scheduling<\/td> Fairness, alle kommen dran<\/td> Priorit\u00e4ten, wichtige Tasks zuerst<\/td><\/tr> Speicherschutz<\/td> Gesch\u00fctzte Adressr\u00e4ume<\/td> Meist ein gemeinsamer Adressraum<\/td><\/tr> Vorhersagbarkeit<\/td> Nicht garantiert<\/td> Deterministisch<\/td><\/tr> Gr\u00f6\u00dfe<\/td> Gigabyte<\/td> Kilobyte<\/td><\/tr> Echtzeit<\/td> „Weich“ (meist)<\/td> „Hart“ (garantiert)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n \/\/ Task f\u00fcr Tasterabfrage<\/em>\nvoid task_taster(void *params) {\n while(1) {\n int taster = gpio_lesen(TASTER_PIN);\n if (taster) {\n xQueueSend(tasterQueue, &taster, 0);\n }\n vTaskDelay(pdMS_TO_TICKS(10)); \/\/ 10 ms warten<\/em>\n }\n}\n\n\/\/ Task f\u00fcr Display-Aktualisierung<\/em>\nvoid task_display(void *params) {\n while(1) {\n display_aktualisieren();\n vTaskDelay(pdMS_TO_TICKS(50)); \/\/ 50 ms warten<\/em>\n }\n}\n\n\/\/ Task f\u00fcr Sensorauslesung<\/em>\nvoid task_sensor(void *params) {\n while(1) {\n int wert = sensor_lesen();\n daten_speichern(wert);\n vTaskDelay(pdMS_TO_TICKS(1000)); \/\/ 1 Sekunde warten<\/em>\n }\n}<\/pre>\n\n\n\n\/\/ Queue erstellen<\/em>\nQueueHandle_t sensorQueue = xQueueCreate(10, sizeof(int));\n\n\/\/ Task 1: Sensor auslesen und Wert in Queue senden<\/em>\nvoid task_sensor(void *params) {\n int wert;\n while(1) {\n wert = sensor_lesen();\n xQueueSend(sensorQueue, &wert, portMAX_DELAY);\n vTaskDelay(100);\n }\n}\n\n\/\/ Task 2: Werte aus Queue empfangen und verarbeiten<\/em>\nvoid task_logger(void *params) {\n int wert;\n while(1) {\n xQueueReceive(sensorQueue, &wert, portMAX_DELAY);\n sd_karte_schreiben(wert);\n }\n}<\/pre>\n\n\n\n\/\/ Taster-ISR<\/em>\nvoid ISR_taster(void) {\n xSemaphoreGiveFromISR(tasterSem, NULL); \/\/ Semaphor geben<\/em>\n}\n\n\/\/ Task wartet auf Taster<\/em>\nvoid task_taster_aktion(void *params) {\n while(1) {\n xSemaphoreTake(tasterSem, portMAX_DELAY); \/\/ Warten<\/em>\n aktion_ausfuehren(); \/\/ Wird bei Tastendruck ausgef\u00fchrt<\/em>\n }\n}<\/pre>\n\n\n\n\/\/ Gemeinsame Ressource: Serielle Schnittstelle<\/em>\nvoid task_send1(void *params) {\n while(1) {\n xSemaphoreTake(serialMutex, portMAX_DELAY);\n printf(\"Task 1: Hallo Welt\\n\");\n xSemaphoreGive(serialMutex);\n vTaskDelay(100);\n }\n}\n\nvoid task_send2(void *params) {\n while(1) {\n xSemaphoreTake(serialMutex, portMAX_DELAY);\n printf(\"Task 2: Guten Tag\\n\");\n xSemaphoreGive(serialMutex);\n vTaskDelay(100);\n }\n}<\/pre>\n\n\n\nvTaskDelay(100)<\/code> l\u00e4sst den Task f\u00fcr 100 Ticks schlafen. Der Scheduler l\u00e4uft inzwischen andere Tasks.<\/p>\n\n\n\n\n
\n
\n
\n
\n\n\n\n