Warum ein Bare-Metal-Entwickler auf Betriebssysteme umgestiegen ist

Rückblick auf das 'Bare-Metal-Zeitalter'

Das erste Mal, dass ich von der eingebetteten Software wusste, war ungefähr 2008, ich war im zweiten Jahr und begann, das Programmieren auf einem 51-Chip zu lernen. Da ich Informatik studiert habe, wurden die meisten meiner Programme auf dem PC ausgeführt. Es war eine ganz andere Erfahrung, Programme auf einer Bare-Metal-Platine laufen zu sehen, und ich erinnere mich noch an die Aufregung, als mein erstes Fahrradlampenprogramm erfolgreich lief. Je mehr Bare-Metal-Programme ich jedoch schrieb, desto mehr Probleme begegneten mir. Ich fasse sie wie folgt zusammen: 

Gleichzeitigkeit

Bei Bare-Metal-Programmen gibt es zwangsläufig eine riesige „While (1)“-Schleife, die fast die gesamte Transaktionslogik des gesamten Projekts enthält. Jede Transaktion ruft eine oder mehrere Verzögerungsfunktionen auf und sie werden seriell ausgeführt, wenn die CPU eine Verzögerungsfunktion ausführt, der Rest der Transaktionen muss warten. Auf diese Weise wird ein Großteil der CPU-Zeit für leere Schleifen verschwendet, was zu einer ziemlich geringen Parallelität führt.

Modularität

Aus Sicht des Softwareprojektes wird im Entwicklungsprozess stets das Prinzip hoher Kohäsion und geringer Kopplung betont. Da Module in einer Bare-Metal-Software jedoch normalerweise stark voneinander abhängen, ist es nicht bequem, Software mit geringer Kopplung zu entwerfen, was die Entwicklung großer Projekte auf Bare-Metal-Platinen erschwert. Zum Beispiel:

• Wie oben erwähnt, werden die meisten Funktionen in einer riesigen "While (1)"-Schleife gesammelt und sind schwer in Module zu unterteilen.
• Als weiteres Beispiel müssen Entwickler darauf achten, Verzögerungsfunktionen zu verwenden, wenn der Watchdog-Timer beteiligt ist. Wenn die Verzögerungszeit zu lang ist, hat die Hauptfunktion keine Möglichkeit den Watchdog zurückzusetzen, dann wird der Watchdog während der Ausführung getriggert. Für die Bare-Metal-Entwicklung müssen also selbst beim Aufrufen einer Verzögerungsfunktion zu viele Dinge berücksichtigt werden. Je komplexer das Projekt ist, desto mehr Sorgfalt ist geboten.

Ökosystem

Viele fortgeschrittene Softwarekomponenten müssen von der Implementierung des untergeordneten Betriebssystems abhängen. Zum Beispiel:

• Ich habe ein Open-Source-Projekt basierend auf ‚FreeModbus‘ entwickelt, das ich auf verschiedene Plattformen übertragen wollte, sogar die Bare-Metal-Boards wurden berücksichtigt. Verglichen mit der bequemen Anpassung an verschiedene Betriebssysteme sind einige Funktionen jedoch zu komplex, um sie auf allen Bare-Metal-Boards zu implementieren. Andererseits müssen viele Implementierungen aufgrund fehlender Gemeinsamkeiten auf verschiedenen Hardwareplattformen von Grund auf neu entwickelt werden, was eine langweilige und zeitaufwändige Aufgabe ist. Im Moment kann meine Implementierung des Modbus-Stack immer noch nicht auf Bare-Metal-Boards ausgeführt werden.
• Viele WiFi-Softwareentwicklungskits (SDKs) von großen Unternehmen wie Realteck, TI und MediaTek können nur auf dem Betriebssystem ausgeführt werden. Sie veröffentlichen nicht den Quellcode der Firmware, damit der Benutzer sie ändern kann, sodass Sie sie nicht in der Bare-Metal-Umgebung verwenden können.

Echtzeit

Für einige Anwendungsfelder ist Echtzeitfähigkeit erforderlich. In dieser Situation müssen einige kritische Schritte der Software zu einem bestimmten Zeitpunkt ausgelöst werden. Für die Industriesteuerung müssen die mechanischen Geräte Aktionen in einer vorbestimmten Reihenfolge und zeitlichen Abfolge ausführen. Ist die Echtzeitfähigkeit nicht gewährleistet, kommt es zu Fehlfunktionen, die das Leben von Arbeitern gefährden können. Auf Bare-Metal-Plattformen ist es unmöglich, die Echtzeitfähigkeiten aufrechtzuerhalten, wenn alle Funktionen in einer großen „While (1)“-Schleife eingeklemmt sind.

Wiederverwendbarkeit

Die Wiederverwendbarkeit hängt direkt von der Modularität ab. Ich glaube, niemand möchte immer wieder die gleiche Arbeit machen, insbesondere beim Schreiben von Code. Auf verschiedenen Hardwareplattformen mit unterschiedlichen Chips muss jedoch dieselbe Funktion an unterschiedliche Hardware angepasst werden, deren Implementierungen stark von der Low-Level-Hardware abhängen. Es ist unvermeidlich, die Laufräder neu aufzubauen.

Der Vorteil von Betriebssystemen

Es war ungefähr 2010, als ich das Betriebssystem zum ersten Mal benutzte. Die Serie der STM32-MCUs begann, populär zu werden. Mit leistungsstarken Funktionen liefen viele Leute Betriebssysteme darauf. Ich habe damals das RT-Thread-Betriebssystem verwendet, für das es viele verfügbare, gebrauchsfertige Komponenten gibt. Im Vergleich zu anderen Betriebssystemen fühle ich mich wohler und entwickle seit 10 Jahren darauf.

Ausgehend von meinem Verständnis möchte ich die Vorteile von Betriebssystemen diskutieren:

Modularität

Mit dem Betriebssystem könnte die gesamte Software in mehrere Tasks (sogenannte Threads) aufgeteilt werden, jeder Thread hat seinen eigenen unabhängigen Ausführungsraum. Sie sind voneinander unabhängig, was die Modularität verbessert.

Gleichzeitigkeit

Wenn ein Thread die Verzögerungsfunktion aufruft, wird die CPU automatisch an andere benötigte Threads übergeben, was die Auslastung der gesamten CPU und letztendlich die Parallelität verbessert.

Echtzeit

Ein RTOS ist mit Echtzeitfähigkeiten ausgestattet. Jedem Thread wird eine bestimmte Priorität zugewiesen. Wichtigere Threads werden auf eine höhere Priorität gesetzt, weniger wichtige Threads werden auf eine niedrigere gesetzt. Auf diese Weise wird die Echtzeit-Performance der gesamten Software gewährleistet.

Entwicklungseffizienz

Das Betriebssystem bietet eine einheitliche Ebene abstrakter Schnittstellen, die die Ansammlung wiederverwendbarer Komponenten erleichtert und die Entwicklungseffizienz verbessert.

Das Betriebssystem ist ein Produkt der Weisheit einer Gruppe von Software-Freaks. Viele gängige Softwarefunktionen wie Semaphor, Ereignisbenachrichtigung, Mailbox, Ringpuffer, Einwegkettenliste / Zweiwegliste usw. sind gekapselt und abstrahiert, um diese Funktionen einsatzbereit zu machen.

Betriebssysteme wie Linux und RT-Thread implementieren einen Standardsatz von Hardwareschnittstellen für fragmentierte Hardware, das als Gerätetreiber-Framework bekannt ist. Daher müssen sich Software-Ingenieure nur auf die Entwicklung konzentrieren und müssen sich nicht mehr um die zugrunde liegende Hardware kümmern oder Räder neu aufbauen.

Software-Ökosystem

Der Reichtum des Ökosystems bringt den Prozess quantitativer Veränderungen zu qualitativen.

Die Verbesserung der Modularität und Wiederverwendbarkeit mit Betriebssystemen ermöglicht es uns, betriebssystembasierte, Embedded-freundliche wiederverwendbare Komponenten zu kapseln, die nicht nur in unseren Projekten verwendet werden können, sondern auch mit mehr Embedded-Entwicklern bei Bedarf geteilt werden können – wodurch der Wert der Software.

Ich bin ein Open-Source-Geek und habe einige eingebettete Software auf GitHub als Open-Source veröffentlicht. Bevor ich Open-Source-Software erstellte, habe ich selten mit anderen über meine Projekte gesprochen, weil ich dachte, dass mein Code kaum auf ihrer Hardware laufen könnte, weil die Leute unterschiedliche Chips oder Hardwareplattformen verwenden. Mit Betriebssystemen wird die Wiederverwendbarkeit von Software stark verbessert, viele Experten können über dasselbe Projekt miteinander kommunizieren. Sie kommen sogar aus verschiedenen Ländern. Dies ermutigt immer mehr Menschen, ihre Projekte zu teilen und über sie zu sprechen.