Von DerSchneider<\/strong><\/p>\n\n\n\n Einleitung: Die Stille vor dem Betriebssystem<\/strong><\/p>\n\n\n\n In der Welt der Desktop-Computer und Smartphones ist ein Leben ohne Betriebssystem unvorstellbar. Windows, macOS, Linux, Android \u2013 sie alle sind die unsichtbaren Vermittler zwischen Anwendung und Hardware, verwalten Speicher, starten Programme, treiben Ger\u00e4te an. Ohne sie w\u00e4re ein moderner PC nur ein teures Briefbeschwerer.<\/p>\n\n\n\n In der Embedded World ist das oft anders. Millionen von Mikrocontrollern laufen ihr ganzes Leben lang ohne jedes Betriebssystem. Ihr Programm sitzt direkt auf der Hardware, spricht unvermittelt mit Registern und Interrupts, kennt keinen Scheduler und keinen Speicherschutz. Diese Art der Programmierung nennt man „Bare-Metal“ \u2013 nacktes Metall.<\/p>\n\n\n\n Dieser Artikel taucht ein in diese urspr\u00fcngliche Form der Embedded-Entwicklung. Wir lernen, wie ein Bare-Metal-Programm aufgebaut ist, warum dieser Ansatz trotz seiner Einfachheit oft die beste Wahl ist \u2013 und wann man besser zu einem Betriebssystem greift.<\/p>\n\n\n\n Hauptteil<\/strong><\/p>\n\n\n\n 1. Was bedeutet „Bare-Metal“?<\/strong><\/p>\n\n\n\n Der Begriff „Bare-Metal“ bedeutet w\u00f6rtlich „nacktes Metall“ und meint: Das Programm l\u00e4uft direkt auf der Hardware, ohne Zwischenschicht. Es gibt kein Betriebssystem, das Ressourcen verwaltet, keine Treiber, die die Hardware abstrahieren, keinen Scheduler, der Tasks koordiniert.<\/p>\n\n\n\n Das Programm hat die vollst\u00e4ndige Kontrolle \u00fcber den Mikrocontroller \u2013 und die volle Verantwortung. Es muss selbst daf\u00fcr sorgen, dass alle Peripherie richtig initialisiert wird, dass Interrupts korrekt behandelt werden, dass der Stack nicht \u00fcberl\u00e4uft und dass Zeitbedingungen eingehalten werden.<\/p>\n\n\n\n In einem Bare-Metal-System verschmilzt die Anwendungssoftware mit der Systemsoftware. Es gibt keine Trennung zwischen „User Space“ und „Kernel Space“. Alles l\u00e4uft in einem einzigen Adressraum, mit den h\u00f6chsten Privilegien.<\/p>\n\n\n\n 2. Die Urform: Die Super-Loop<\/strong><\/p>\n\n\n\n Das Herzst\u00fcck jedes Bare-Metal-Programms ist die Super-Loop \u2013 eine endlose Schleife, die immer wieder durchlaufen wird. Das Grundger\u00fcst sieht so aus:<\/p>\n\n\n\n c<\/p>\n\n\n\n Nach der einmaligen Initialisierung im Dieses Muster ist einfach, \u00fcberschaubar und deterministisch. Solange alle Aufgaben zusammen in jedem Schleifendurchlauf Platz finden, funktioniert es hervorragend.<\/p>\n\n\n\n 3. Die Herausforderung: Unterschiedliche Zeitanforderungen<\/strong><\/p>\n\n\n\n Die Super-Loop hat ein grundlegendes Problem: Alle Aufgaben werden in fester Reihenfolge abgearbeitet, und die Zeit f\u00fcr einen kompletten Durchlauf ist die Summe aller Aufgaben.<\/p>\n\n\n\n Wenn eine Aufgabe sehr lange dauert, verz\u00f6gern sich alle anderen. Wenn manche Aufgaben schnell reagieren m\u00fcssen (Echtzeit!), andere aber viel Zeit brauchen, ger\u00e4t das System schnell an seine Grenzen.<\/p>\n\n\n\n Stellen Sie sich vor:<\/p>\n\n\n\n In einer einfachen Super-Loop w\u00fcrde die Berechnung alle anderen Aufgaben blockieren. Der Taster w\u00fcrde nur alle 200 ms abgefragt \u2013 viel zu langsam f\u00fcr eine zuverl\u00e4ssige Entprellung.<\/p>\n\n\n\n 4. Die L\u00f6sung: Zeitgesteuerte Aufgaben<\/strong><\/p>\n\n\n\n Die erste Verbesserung besteht darin, Aufgaben nicht einfach der Reihe nach abzuarbeiten, sondern zeitgesteuert. Mit einem Timer, der regelm\u00e4\u00dfig Interrupts ausl\u00f6st, kann man einen „Takt“ erzeugen:<\/p>\n\n\n\n c<\/p>\n\n\n\n Jetzt wird der Taster alle 10 ms abgefragt, auch wenn die Berechnung l\u00e4uft. Die 5. Kooperatives vs. Pr\u00e4emptives Multitasking<\/strong><\/p>\n\n\n\n Die obige L\u00f6sung ist ein Beispiel f\u00fcr kooperatives Multitasking<\/strong>: Jede Aufgabe muss von sich aus die Kontrolle abgeben, damit andere drankommen. Das ist einfach und sicher (keine gleichzeitigen Zugriffe), aber eine Aufgabe, die sich nicht kooperativ verh\u00e4lt (z.B. eine Endlosschleife), blockiert das ganze System.<\/p>\n\n\n\n Die Alternative ist pr\u00e4emptives Multitasking<\/strong>, bei dem der Scheduler Aufgaben unterbrechen kann. Das erfordert aber ein Betriebssystem (RTOS) und ist deutlich komplexer.<\/p>\n\n\n\n In Bare-Metal-Systemen ist kooperatives Multitasking die Regel. Die Kunst besteht darin, alle Aufgaben so zu schreiben, dass sie regelm\u00e4\u00dfig zur\u00fcckkehren \u2013 typischerweise in sogenannten „Zustandsmaschinen“, die nach jedem Schritt pausieren k\u00f6nnen.<\/p>\n\n\n\n 6. Zustandsmaschinen als Retter<\/strong><\/p>\n\n\n\n Komplexere Abl\u00e4ufe lassen sich oft elegant als Zustandsmaschine (State Machine) modellieren. Statt einer langen, blockierenden Funktion hat man eine Funktion, die bei jedem Aufruf einen Schritt weitergeht.<\/p>\n\n\n\n Beispiel: Ein Ampelsystem<\/p>\n\n\n\n c<\/p>\n\n\n\n Diese Funktion wird in der Super-Loop regelm\u00e4\u00dfig aufgerufen. Sie blockiert nie, macht immer nur einen Schritt und kehrt sofort zur\u00fcck.<\/p>\n\n\n\n 7. Die Vorteile von Bare-Metal<\/strong><\/p>\n\n\n\n Warum programmiert man heute noch Bare-Metal, wo es doch RTOS-L\u00f6sungen f\u00fcr fast jeden Mikrocontroller gibt?<\/p>\n\n\n\n Einfachheit:<\/strong> Ein Bare-Metal-Programm ist oft \u00fcberschaubarer als ein RTOS-System. Keine komplexen Scheduler-Konfigurationen, keine Synchronisationsprobleme, kein Speicherschutz.<\/p>\n\n\n\n Ressourceneffizienz:<\/strong> Ein RTOS braucht Speicher und Rechenzeit. Bei winzigen 8-Bit-Controllern mit 2 KB RAM ist das oft nicht vorhanden.<\/p>\n\n\n\n Determinismus:<\/strong> In einem gut geschriebenen Bare-Metal-System ist genau vorhersagbar, wann welche Aufgabe l\u00e4uft. Bei RTOS kann es durch Priorit\u00e4ten und Interrupts zu komplexen, schwer vorhersagbaren Abl\u00e4ufen kommen.<\/p>\n\n\n\n Kontrolle:<\/strong> Man hat die vollst\u00e4ndige Kontrolle \u00fcber alles. Keine Black Box, keine \u00dcberraschungen durch Betriebssystem-Verhalten.<\/p>\n\n\n\n 8. Die Grenzen von Bare-Metal<\/strong><\/p>\n\n\n\n Aber Bare-Metal hat auch klare Grenzen:<\/p>\n\n\n\n Komplexit\u00e4t:<\/strong> Sobald viele Aufgaben mit unterschiedlichen Priorit\u00e4ten koordiniert werden m\u00fcssen, wird der Code schnell un\u00fcbersichtlich. Eine Zustandsmaschine mit Dutzenden Zust\u00e4nden ist schwer zu warten.<\/p>\n\n\n\n Sicherheit:<\/strong> Es gibt keine Isolierung zwischen Aufgaben. Ein Fehler in einer Aufgabe kann das ganze System zum Absturz bringen.<\/p>\n\n\n\n Wiederverwendbarkeit:<\/strong> Code ist oft eng mit der spezifischen Hardware verzahnt und schwer auf andere Plattformen zu portieren.<\/p>\n\n\n\n Kommunikation:<\/strong> Wenn Aufgaben Daten austauschen m\u00fcssen, muss man selbst Mechanismen daf\u00fcr bauen (globale Variablen, Queues, etc.).<\/p>\n\n\n\n 9. Ein Praxisbeispiel: Kleiner Datenlogger<\/strong><\/p>\n\n\n\n Stellen wir uns einen einfachen Datenlogger vor: Ein Temperatursensor wird alle 10 Sekunden ausgelesen, der Wert auf einem Display angezeigt und auf einer SD-Karte gespeichert. Ein Taster erlaubt das Umschalten der Anzeige.<\/p>\n\n\n\n Ein Bare-Metal-Design k\u00f6nnte so aussehen:<\/p>\n\n\n\n c<\/p>\n\n\n\n Das System ist einfach, robust und stromsparend \u2013 perfekt f\u00fcr einen batteriebetriebenen Datenlogger.<\/p>\n\n\n\n 10. Der \u00dcbergang: Wann wird ein RTOS n\u00f6tig?<\/strong><\/p>\n\n\n\n Irgendwann st\u00f6\u00dft Bare-Metal an seine Grenzen. Typische Anzeichen:<\/p>\n\n\n\n Dann ist es Zeit, \u00fcber ein Echtzeitbetriebssystem (RTOS) nachzudenken \u2013 das Thema unseres n\u00e4chsten Artikels.<\/p>\n\n\n\n Fazit und Ausblick<\/strong><\/p>\n\n\n\n Bare-Metal-Programmierung ist die Urform der Embedded-Entwicklung. Sie ist einfach, effizient und gibt maximale Kontrolle. Mit Techniken wie zeitgesteuerten Aufgaben und Zustandsmaschinen lassen sich auch komplexere Anwendungen realisieren. F\u00fcr viele \u2013 vielleicht die meisten \u2013 Embedded-Projekte ist Bare-Metal v\u00f6llig ausreichend.<\/p>\n\n\n\n Doch wenn die Komplexit\u00e4t w\u00e4chst, wird ein Betriebssystem zur sinnvollen Abstraktion. Es \u00fcbernimmt das Scheduling, die Synchronisation und die Kommunikation \u2013 und erlaubt dem Entwickler, sich auf die eigentliche Anwendung zu konzentrieren.<\/p>\n\n\n\n Mit diesen Echtzeitbetriebssystemen besch\u00e4ftigen wir uns im n\u00e4chsten Artikel.<\/p>","protected":false},"excerpt":{"rendered":" Nacktes Metall \u2013 Programmieren ohne Betriebssystem (Bare-Metal) Von DerSchneider Einleitung: Die Stille vor dem Betriebssystem In der Welt der Desktop-Computer und Smartphones ist ein Leben ohne Betriebssystem unvorstellbar. Windows, macOS, Linux, Android \u2013 sie alle sind die unsichtbaren Vermittler zwischen Anwendung und Hardware, verwalten Speicher, starten Programme, treiben Ger\u00e4te an. Ohne sie w\u00e4re ein moderner […]<\/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-2142","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\/2142","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=2142"}],"version-history":[{"count":0,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/2142\/revisions"}],"wp:attachment":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/media?parent=2142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/categories?post=2142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/tags?post=2142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\n\n\n
\n\n\n\nvoid main(void) {\n \/\/ Initialisierung: Hardware konfigurieren<\/em>\n init_hardware();\n init_peripherie();\n init_interrupts();\n \n \/\/ Super-Loop<\/em>\n while(1) {\n task1(); \/\/ Aufgabe 1 erledigen<\/em>\n task2(); \/\/ Aufgabe 2 erledigen<\/em>\n task3(); \/\/ Aufgabe 3 erledigen<\/em>\n \/\/ ...<\/em>\n }\n}<\/pre>\n\n\n\nmain<\/code>-Programm l\u00e4uft der Mikrocontroller f\u00fcr den Rest seines Lebens in dieser Schleife. Jeder Durchlauf erledigt der Reihe nach alle anstehenden Aufgaben.<\/p>\n\n\n\n\n
volatile int tick = 0;\n\n\/\/ Timer-Interrupt, alle 1 ms<\/em>\nISR(TIMER_ISR) {\n tick++;\n}\n\nvoid main(void) {\n init_timer(1); \/\/ Timer alle 1 ms<\/em>\n int letzteTaster = 0;\n int letzteDisplay = 0;\n \n while(1) {\n if (tick - letzteTaster >= 10) { \/\/ alle 10 ms<\/em>\n taster_abfragen();\n letzteTaster = tick;\n }\n \n if (tick - letzteDisplay >= 50) { \/\/ alle 50 ms<\/em>\n display_aktualisieren();\n letzteDisplay = tick;\n }\n \n \/\/ Langsame Aufgabe, die immer l\u00e4uft<\/em>\n langsame_berechnung();\n }\n}<\/pre>\n\n\n\nlangsame_berechnung()<\/code> muss nur darauf achten, regelm\u00e4\u00dfig zum Hauptprogramm zur\u00fcckzukehren (kooperatives Multitasking), damit die anderen Aufgaben drankommen.<\/p>\n\n\n\ntypedef enum {ROT, ROT_GELB, GRUEN, GELB} ampel_zustand_t;\nampel_zustand_t zustand = ROT;\nint letzterWechsel = 0;\n\nvoid ampel_schritt(int zeit) {\n switch(zustand) {\n case ROT:\n if (zeit - letzterWechsel >= 5000) { \/\/ 5 Sekunden<\/em>\n zustand = ROT_GELB;\n letzterWechsel = zeit;\n led_rot(ON);\n led_gelb(ON);\n led_gruen(OFF);\n }\n break;\n \n case ROT_GELB:\n if (zeit - letzterWechsel >= 1000) { \/\/ 1 Sekunde<\/em>\n zustand = GRUEN;\n letzterWechsel = zeit;\n led_rot(OFF);\n led_gelb(OFF);\n led_gruen(ON);\n }\n break;\n \n \/\/ weitere Zust\u00e4nde...<\/em>\n }\n}<\/pre>\n\n\n\nvolatile int sekunden = 0;\n\n\/\/ Timer-Interrupt alle 1 Sekunde<\/em>\nISR(TIMER_ISR) {\n sekunden++;\n}\n\nvoid main(void) {\n init_timer(1000); \/\/ 1 Sekunde<\/em>\n int letzteMessung = 0;\n int letzteDisplay = 0;\n int anzeigeModus = 0;\n \n while(1) {\n \/\/ Taster abfragen (entprellt)<\/em>\n if (taster_gedrueckt()) {\n anzeigeModus = !anzeigeModus;\n }\n \n \/\/ Alle 10 Sekunden messen<\/em>\n if (sekunden - letzteMessung >= 10) {\n int temp = sensor_lesen();\n sd_karte_schreiben(temp);\n letzteMessung = sekunden;\n }\n \n \/\/ Display alle 500 ms aktualisieren<\/em>\n if (sekunden - letzteDisplay >= 0.5) { \/\/ mit Timer-Aufl\u00f6sung<\/em>\n display_aktualisieren(anzeigeModus);\n letzteDisplay = sekunden;\n }\n \n \/\/ Schlafen, wenn nichts zu tun<\/em>\n power_save();\n }\n}<\/pre>\n\n\n\n\n
\n\n\n\n