5 Möglichkeiten, wie eine Hardware-Abstraktionsschicht Ihre Projekte transformieren kann

Jakob von Benin | 05. Juni 2023

Entwickler eingebetteter Software haben in der Regel Hardware-Abstraktionsschichten (HALs) gemieden, indem sie behaupteten, dass sie die Leistung verringern und die Codekomplexität erhöhen. Wenn Entwickler einen HAL einführen, abstrahiert ein vom Anbieter bereitgestellter HAL leider oft nicht die Hardware und garantiert dennoch eine enge Kopplung mit der Hardware. Schließlich würde ein echtes abstrahiertes HAL es einem Entwickler ermöglichen, im Handumdrehen jeden Anbieter zu nutzen. Es gibt jedoch viele Möglichkeiten, wie sich die Verwendung oder Entwicklung Ihres eigenen HAL auf Ihre Software auswirken kann. In diesem Beitrag werden wir fünf überraschende Möglichkeiten untersuchen, wie ein HAL Ihre Softwareprojekte transformieren und Geschwindigkeit und Mehrwert freisetzen kann, die Sie nicht für möglich gehalten hätten.

Ich habe im Allgemeinen festgestellt, dass Entwickler oft einen bevorzugten Mikrocontroller-Anbieter haben. Normalerweise handelt es sich dabei um den Anbieter, bei dem Sie Ihre eingebettete Software zum ersten Mal geschrieben haben oder mit dem Sie vertraut sind. Ich habe wie jeder andere meine Favoriten, aber es kann gefährlich sein, Ihre Software abhängig von deren HAL oder Softwarebibliotheken zu schreiben. Was tun Sie beispielsweise, wenn Sie plötzlich keine Mikrocontroller mehr bekommen? Sie müssten einen neuen Lieferanten auswählen und dann Ihr Produkt umschreiben, testen und vielleicht sogar zertifizieren. Das ist weder schnell noch günstig! Auch wenn Sie das vielleicht für unwahrscheinlich halten, ist es während der COVID-19-Pandemie und schon oft zuvor passiert.

Mit einem guten HAL können Sie portableren und wiederverwendbareren Anwendungscode schreiben, der hardwareunabhängig ist. Das ist für viele eingebettete Teams eine gewaltige Veränderung. Beispielsweise könnten Sie Ihren Code mit Anbieter A ausführen und durch Ändern eines Flags in Ihrem Build für Anbieter B kompilieren. Hardware-Unabhängigkeit gibt Ihnen die Flexibilität, jede gewünschte Hardware zu verwenden, und beseitigt Ihre Abhängigkeit von Ihrem Mikrocontroller-Anbieter.

Wenn Ihnen die Idee gefällt, das vom Hersteller bereitgestellte HAL zu verwenden, ist das in Ordnung, solange Sie einige wesentliche Funktionen überprüfen. Erstens muss der HAL ein echter HAL sein. Das bedeutet, dass Sie über eine definierte Schnittstelle verfügen müssen, die die Hardwareabhängigkeit unterbricht. Wir haben dies in meinem Blog mit dem Titel „Writing Hardware Abstraction Layers (HALs) in C“ besprochen. Ich sehe oft „HALs“, die nichts anderes als Funktionen mit der Implementierung sind. Dies entspricht nicht dem Prinzip der Abhängigkeitsumkehr und ist genauso schwierig, Code zu aktualisieren. Als nächstes sollte die HAL getrennt von der Implementierung definiert werden. Schließlich sollten Sie in der Lage sein, die von der Schnittstelle aufgerufene Funktion schnell auszutauschen. Wenn Sie diese drei Dinge nicht haben, haben Sie keine Hardware-Unabhängigkeit; Sie haben Hardwareabhängigkeit!

Der Schlüssel zur Wertschöpfung und Transformation Ihrer Softwareentwicklung beginnt mit der Verwendung eines HAL. Der HAL ermöglicht darüber hinaus zusätzliche Transformationen wie die Aktivierung automatisierter Unit- und Integrationstests. Embedded-Entwickler haben oft Probleme mit Unit-Tests, weil sie Code schreiben, der die Hardware berührt. Das bedeutet, dass Sie Ihre Tests auf dem Mikrocontroller ausführen müssen. Wenn Sie über eine ordnungsgemäße HAL verfügen, müssen Sie Ihre Treiber zwar noch auf dem Ziel testen, aber plötzlich ist Ihr gesamter Anwendungscode freigegeben! Ihr Anwendungscode kann jetzt unabhängig von der Hardware auf einem Host-Computer Unit- und Integrationstests unterzogen werden.

Die Entfernung der Hardware aus der Gleichung und die Verlagerung der Tests auf den Host kommen den Entwicklern zugute. Erstens ist es schneller. Sie müssen sich keine Sorgen über all die langsamen Lösch- und Schreibzyklen des Teils machen. Zweitens müssen Sie sich keine Gedanken darüber machen, wie groß Ihr Testgeschirr wird oder wie viele Tests Sie durchführen. Anstatt zu versuchen, Ihren Code und Ihre Tests auf dem Mikrocontroller unterzubringen, testen Sie zunächst einfach den gesamten Anwendungscode auf Ihrem Host. Als nächstes können Sie durch die Umstellung auf Off-Target-Tests die kontinuierliche Integration und bei Bedarf sogar die kontinuierliche Bereitstellung nutzen. Dadurch werden Fehler früher und schneller erkannt, die Kosten gesenkt und die Qualität verbessert.

Wenn Sie mit einem guten HAL die Hardware aus der Gleichung herausholen, können Sie jede Implementierung dahinter einsetzen. Das bedeutet, dass Sie über eine Implementierung für Ihr Ziel, Ihren Testumfang und eine Simulationsumgebung verfügen können! In vielen Fällen müssen Entwickler eingebetteter Software mit dem Schreiben von Software beginnen, bevor Hardware verfügbar ist. Während wir also für den Einstieg Entwicklungsboards verwenden können, können wir mit einem guten HAL stattdessen Simulationen für unseren Anwendungscode ausführen!

Die Simulation von Anwendungscode bringt für Entwickler viele Vorteile mit sich. Erstens ermöglicht es ihnen, den Anwendungscode ihren Kunden eher früher als später zur Verfügung zu stellen. Wir alle wissen, dass Kunden gerne ihre Meinung ändern und Schwierigkeiten haben, sich vorzustellen, wie ein Produkt funktionieren wird, bis sie es ausprobieren können. Die Simulation kann dem Kunden helfen, das Produkt zu verstehen und früher produktives Feedback zu geben, wodurch teure und zeitaufwändige Änderungen später im Entwicklungszyklus vermieden werden.

Als nächstes ermöglicht die Simulation robustere Tests, indem sie es ermöglicht, Fehler und andere abweichende Verhaltensweisen ohne Hardware zu testen. Beispielsweise kann es oft eine Herausforderung sein, einen Sensor dazu zu bringen, sich falsch zu verhalten oder eine Hardware-Ausnahme auf dem Zielprozessor zu erzwingen. In einer Simulationsumgebung ist dies kein Problem. Das Ergebnis ist wiederum eine robustere Software.

Wenn Sie auf dem Ziel debuggen, gibt es bei jeder Änderung einen Zyklus aus Cross-Compilieren, Flash löschen, Flash programmieren und die Anwendung ausführen. Der gesamte Vorgang kann je nach Anwendung auch mit professionellen Werkzeugen eine ganze Weile dauern. Durch die Verwendung einer HAL zur Trennung der Anwendung kann der Code schneller debuggt werden! Auf einem Host ist der Kompilierungs- und Ausführungszyklus viel kürzer. Das bedeutet, dass Entwickler Probleme schneller bearbeiten und dann bei Bedarf die endgültige debuggte Version auf ihrer Hardware testen können.

Wenn Sie zulassen, dass die anderen Transformationen, die ein HAL bereitstellt, zum Tragen kommen, nutzen Sie Unit-Tests, um die Entwicklung voranzutreiben, was bedeutet, dass Sie sogar weniger Zeit mit dem Debuggen verbringen. Sie schreiben nur Code, um einen Test erfolgreich durchzuführen. Ihre Software wird in kleinen Schritten geschrieben und währenddessen durch Tests validiert. Wenn Sie etwas kaputt machen, wird es durch Regressionstests sofort erkannt. Das Ergebnis wird ein schnelleres und effizienteres Debuggen sein und die nahezu vollständige Entfernung des Debuggens aus Ihrem Leben und Projekt! Klingt das nicht wunderbar?

Die ultimative Transformation bei der Verwendung eines HAL zur Entwicklung eingebetteter Software besteht darin, dass Sie die Kosten und die Markteinführungszeit senken. Ein HAL schafft Flexibilität in der eingebetteten Software, von der die meisten Teams nie träumen würden. Sie können leicht erkennen, dass spät im Entwicklungszyklus weniger Nacharbeiten anfallen, wenn Sie schnell Kundenfeedback erhalten. Wenn Sie außerdem das Debuggen eliminieren können, ist das enorm! Die meisten Teams verbringen durchschnittlich 20–40 % ihres Entwicklungszyklus mit dem Debuggen! Das sind 2,4–4,5 Monate pro Jahr und Person! Alles nur, weil Sie einen HAL verwendet haben, der es Ihnen ermöglicht, Ihren Anwendungscode zu testen und die Debug-Zeit zu verkürzen.

Mit kürzeren Markteinführungszeiten wird deutlich, dass die Kosten geringer sind. Es wird sicherlich in die HAL-Entwicklung, Testumgebungen und andere Tools investiert, um sicherzustellen, dass der Entwicklungszyklus reibungslos verläuft. Allerdings sind diese Kosten oft um eine Größenordnung geringer als die Einsparungen. Ich habe noch nicht einmal die Wartungskosten erwähnt, die die anfänglichen Entwicklungskosten leicht übersteigen können.

Ich habe oft von Kunden und Kollegen kommentieren lassen, wie viel ich erledigen kann. Das Geheimnis liegt darin, dass ich die Transformationen freigeschaltet habe, die ein HAL eingebetteten Entwicklern bieten kann. Wie Sie in diesem Beitrag gesehen haben, kann die Verwendung eines „echten“ HAL Ihr Projekt und die Art und Weise, wie Sie eingebettete Software entwickeln, dramatisch verändern.

Einige der von uns besprochenen Transformationen mögen etwas fremdartig erscheinen, da Entwickler eingebetteter Software diese Techniken traditionell nicht verwendet haben. Es dauert jedoch nicht lange, sich mit ihnen vertraut zu machen und ihnen zu ermöglichen, die Entwicklung eingebetteter Software erheblich zu verbessern. Sie haben die Vorteile gesehen; Die Frage ist, ob Sie sie annehmen und damit beginnen werden, einen Mikrocontroller-unabhängigen HAL in Ihre Software zu integrieren. Wenn Sie das tun, werden Sie meiner Meinung nach die Art und Weise, wie Sie Ihre eingebetteten Produkte entwickeln, revolutionieren.

Weitere Informationen zu Textformaten