Ein Angebot von

Hardwarenahe Softwareentwicklung

| Autor / Redakteur: Christian Siemers* / Christine Kremser

Hardwarenahe Softwarentwicklung ist aufgrund beschränkter Systemressourcen oft unabdingbar.
Hardwarenahe Softwarentwicklung ist aufgrund beschränkter Systemressourcen oft unabdingbar. (Bild: gemeinfrei / CC0)

Ein Thema wie hardwarenahe Programmierung in einer Hochsprache sollte es eigentlich gar nicht geben. Dennoch kann auf Grund eingeschränkter verfügbarer Ressourcen oft auf hardwarenahe Softwareprogrammierung nicht verzichtet werden. Wie geht man am besten mit diesem scheinbaren Konflikt um?

In einer Hochsprache zu Programmieren impliziert eigentlich Hardwareunabhängigkeit – und nicht ein spezifisches Eingehen auf die Eigenheiten selbiger. Deswegen sollte es eigentlich so etwas wie hardwarenahe Softwareentwicklung in einer Hochsprache nicht geben. Und dennoch ist das Thema der Hardwarenähe in der Praxis nicht wegzudenken. Das ergibt sich aus den folgenden Gründen:

  • Ressourcenbeschränkungen (gerade in eingebetteten Systemen)
  • Umständliche Konfiguration von Peripherieelementen (diese ist eher auf Bit- und Byte-Ebene zu sehen)
  • Extreme Anpassung der Software auf Hardwaregegebenheiten, z.B. bei spezialisierter Hardware oder fehlenden Hardwarekomponenten
  • Echtzeitprogrammierung bei sehr knappen Rechenzeiten

Ressourcenbeschränkungen am Beispiel der Diskreten Fouriertransformation

Fouriertransformation (FT): Die Fouriertransformation ist die Analyse eines (meist zeit-) kontinuierlichen Signals auf die beinhalteten Frequenzen. Hierbei geht man zunächst von periodischen Signalen aus, die sich also nach einer bestimmten Zeit wiederholen. Diese Wiederholungsfrequenz ergibt dann die so genannte Grundfrequenz, das Frequenzspektrum ist diskret.

Der Übergang von periodischen auf aperiodische Signalformen ergibt dann den Übergang vom diskreten auf das kontinuierliche Spektrum. Umgekehrt kann man die ursprüngliche Signalform g(x) durch phasen- und amplitudenkorrektes Überlagern der im Spektrum vorhandenen Frequenzen wieder erzeugen (Fourier-Synthese). In Bild 1 sind die Formeln zur Berechnung in der reellen Schreibweise zu finden, wobei angenommen wird, dass g(x) eine reellwertige Funktion ist.

Diskrete Fouriertransformation (DFT): In Rechnern ist die „Zeitachse“ niemals kontinuierlich, sondern immer diskret. Dies liegt u.a. daran, dass selbst die AD-Wandler niemals zeitkontinuierlich, sondern immer nur zeitdiskret von der analogen in die digitale Welt übertragen können. AD-Wandler diskretisieren sowohl Daten- als auch Zeitwerte.

Damit werden die Berechnungsintegrale der allgemeinen Fouriertransformation zu Berechnungssummen, die vergleichsweise einfach in Form von Algorithmen implementiert werden können [1]. T bezeichnet in den Gleichungen (Bild 1b) die Periode des Signals, ∆t den zeitlichen Abstand zweier aufeinanderfolgender Messpunkte.

Die DFT wird genutzt, wenn die Zahl der Messpunkte pro Periode nicht vorherbestimmt oder ungleich einer Zweierpotenz ist. Bei Zweierpotenzen wie 512 oder 1024 jedoch bietet sich die Implementierung als Fast Fourier Transformation (FFT) an. Die Komplexität der DFT liegt bei O(N²), die der FFT bei O(N*log(N)).

DFT-Algorithmus mit Fließkommazahlen

Die Formeln in Bild 1 b) können vergleichsweise leicht in einem Algorithmus aufgenommen werden, z.B. in C (siehe Listing 1 in der Bildergalerie).

Dieses Programm beinhaltet mit NUM_OF_COEFFICIENTS eine Konstante, die anzeigt, wie viele Koeffizienten a und b aus Bild 1 berechnet werden sollen; diese Konstante kann natürlich auch leicht als Variable formuliert werden. Was man aber sehr leicht beurteilen kann: Hier sind eine Menge an Additionen und Multiplikationen enthalten, von der Berechnung der Sinus- und Cosinuswerte ganz abgesehen. Dieser Algorithmus auf einem Mikroprozessor oder DSP implementiert, der keine Floating-Point-Unit aufweist, kann schon überraschend große Laufzeiten aufweisen, da das Floating-Point-Format recht umständlich emuliert werden muss.

Umsetzung in ein Festkommaformat

Es liegt also nahe, die Umsetzung in ein Festkommaformat durchzuführen und dann mit erhöhter Performance zu rechnen. Eine weitere Verbesserung ist z.B. geringerer Platzbedarf, was aber ggf. zweitrangig ist. Die grundsätzliche Formel zur Umsetzung ist (siehe (1), wobei mit Δ der so genannte Offset (Versatz des Nullpunkts) und mit Q zunächst ein linearer Skalierungsfaktor bezeichnet wird.

Diese Abbildung betrifft aber zunächst nur das Mapping einer physikalischen (Prozess-) Größe auf eine analoge (!) Größe. Interpretiert man die Formel (1) jedoch so, dass Q eine Quantisierungsgröße darstellt, und dass die Abbildung in Quanten erfolgt, dann erhalten wir die gewünschte Abbildung von physikalischen Größen in Darstellungen in Computer-verwendbaren Datenwerten.

Gleichung (2) in der Bildergalerie wird gerne noch dahingehend vereinfacht, dass man den Offset Δ zu Null setzt. Hierdurch werden arithmetische Operationen wie Addition, Subtraktion usw. erheblich vereinfacht.

So schön einfach die Formel (2) auch erscheint, sie birgt noch einen Pferdefuß in sich, denn sie gilt nur für einen eingeschränkten Wertebereich von xphys. Diese Größe repräsentiert ja die physikalische Außenwelt bzw. eine Messgröße, und da der Zahlenbereich aller Darstellungen im Rechner beschränkt ist, ist auch die Messgröße in einem zulässigen Intervall zu halten.

Mehr noch, wenn man xphys durch xfloat ersetzt – genau dies soll hier ja geschehen, es soll die Fließkomma- durch eine Fixkomma-Darstellung ersetzt werden –, dann gelten für beide Zahlenformate Intervallgrenzen für die Zulässigkeit, aber eben unterschiedliche. Dies muss bei der Umsetzung unbedingt berücksichtigt werden.

Das Qm.n-Format

Das verwendbare Festkommaformat muss man sich als Abwandlung des bekannten Integer-Formats denken, bei dem der Abstand zwischen zwei benachbarten darstellbaren Werten eben nicht 1, sondern z.B. 0,5, 0,25 oder 0,1 ist. Üblicherweise nimmt man in der digitalen Welt auch hierfür Zweier-Potenzen, und das resultierende Format wird als Qn.m bezeichnet.

Der Index n steht hierbei für die Anzahl der Bits vor dem Komma, m für die Anzahl danach. Ferner wird wie im Integer-Fall zwischen vorzeichenlosen und vorzeichenbehafteten Darstellungen unterschieden, wobei dies nicht in der Formatbezeichnung sichtbar wird.

Rechnen mit Qn.m unterscheidet sich nicht sonderlich vom Rechnen mit Integerzahlen, solange das Komma bei den Operanden immer an der gleichen Stelle steht. Sind die Darstellungen der Operanden allerdings unterschiedlich, d.h., stimmen n und m für die jeweiligen Operanden untereinander nicht mehr überein, dann ist Gehirnarbeit und Bitschieberei angesagt.

Sinus und Cosinus

Und es wartet noch eine Aufgabe im Sourcecode (siehe Listing 2 in der Bildergalerie), die für eine Übersetzung gelöst werden muss: Die transzendenten Funktionen Sinus und Cosinus. Diese Funktionen sind üblicherweise für Fließkommawerte in Bibliotheken vorhanden, aber genau dieser Datentyp soll hier nicht verwendet werden.

Die Lösung besteht z.B. darin, die Sinus- und Cosinuswerte vor der Laufzeit zu berechnen und in einem Datenbereich im Qn.m-Format (hier z.B. vorzeichenbehaftetes Q1.30) zu speichern (siehe Listing 2). Um dann zur Laufzeit präzise Werte zu allen Eingangsparameter verfügbar zu haben, kann man sich aus der Grundtabelle eine zweite Tabelle (oder direkt die Werte) durch lineare Interpolation erstellen. Dieses Verfahren ist sehr schnell, auch für einfache Prozessoren.

… und nun die DFT

Mit den gerade diskutierten Ansätzen zur hardwarenahen Softwareentwicklung wird nun die Transformation des Algorithmus aus Listing 1 in eine Version, die lediglich Integer-Wert nutzt, durchgeführt. Folgende Details sind dabei wichtig:

  • Alle Rechnungen werden als Integerberechnungen durchgeführt, kein Casting!
  • Eine (Muster-)Sinuskurve wird in Form von 513 (= 512 + 1) Werten im signed-Q1.30-Format gespeichert, und zwar nur das erste Viertel (weil sich daraus alle anderen ergeben). Die vollständige Kurve hat dann 2048 Werte.
  • Der Zugriff auf diese Wertetabelle ist durch Zugriffsfunktionen wie i32GetCosineValue( uint16 ui16Index ) gekapselt. Dies ist eine Anleihe aus der objektorientierten Programmentwicklung.
  • Für die DFT sind eine Sinus- und eine Cosinustabelle notwendig, deren Periode exakt gleich der Anzahl der Messpunkte ist. Diese wird zu Beginn berechnet (durch lineare Interpolation), und anschließend werden die jeweiligen Werte von dort mithilfe der Funktionen (i32GetSine¬TableValue() und i32GetCosineTableValue()gelesen.

Die zentrale Routine zur Berechnung der DFT sehen Sie in Listing 3 der Bildergalerie.

Als Testfunktion wird ein Rechteckt mit 5 Perioden auf 1000 Punkte gewählt, da hier das Ergebnis bekannt ist: Wenn die Grundwelle eine Höhe von 1 aufweist, dann sind alle geraden Oberwellen 0, und alle ungeraden Oberwellen (Index k) weisen eine Amplitude von 1/k auf. Bild 2 zeigt das Ergebnis für die in Floating Point realisierte Variante, Bild 3 für die im Festkommaformat.

Die Bilder weisen unübersehbare Unterschiede auf, obwohl sie den gleichen Algorithmus implementieren. Zudem sieht man zumindest qualitativ, dass Bild 2 ein korrektes Ergebnis anzeigt, da das Ergebnis mit der Theorie übereinstimmt. Hierzu gleich eine Anmerkung: Will man die wirkliche Korrektheit der Ergebnisse prüfen, muss man zu einer logarithmische Darstellung wechseln und die Differenz der berechneten und der theoretischen Werte logarithmisch betrachten. Je nach Anzahl der signifikanten Bits ergibt dies einen Wert, der unter dem erreichbaren Signal/Rausch-Abstand liegen muss.

Zurück zur Auswertung: Der Grund für das Scheitern der DFT-Berechnung im Festkommaformat sind Datenüberläufe. Die Berechnung verwendet Sinus- und Cosinuswerte von 16 bit Breite. Diese werden in dem Beispiel mit 13 bit Werten (dem gewählten Format für das Rechteck, 12 bit Wert + Vorzeichen) multipliziert, dies ergibt 29 signifikante Bits, und dann 1000fach aufsummiert, was zu 10 weiteren Bits führt (10 = log2(1024)). Insgesamt können die Ergebnisse also 39 Bit Breite aufweisen, da wundert es nicht, wenn es für 32 bit Variablen überlaufen kann.

Die Lösung des Problems

Man kann nun an zwei verschiedenen Schrauben justieren, um das Problem des Datenüberlaufs zu lösen: Geringere Datenbreiten, also ein Verlust an Genauigkeit, oder größere Datentypen, z.B. also 64 bit. Der erste Weg bietet sich an, wenn die Genauigkeit, die erzielbar wäre, gar nicht gefordert ist, der zweite, wenn der Genauigkeitsverlust nicht akzeptabel ist.

Die Aufteilung auf zwei Variablen, also die Emulation höherer Datenbreiten durch softwaremäßige Kopplung bleibt ebenfalls als durchaus performante Lösung. Bild 4 zeigt das Ergebnis der Fouriertransformation für einen korrekten, die entstehenden Datenbreiten berücksichtigenden Algorithmus im Festkommaformat.

Die Performance ist dabei schon beeindruckend. Während ein DSP mit einer intrinsischen Datenbreite von 16 bit ohne Fließkommaeinheit für eine 1000-Punkte-DFT immerhin 7 Sekunden benötigte, schlugen für die Festkommavariante nur 700 ms und nach Optimierung (Abbildung der Divisionsbefehle auf sukzessive Subtraktion) nur 120 ms zu Buche.

Als Fazit bleibt, dass beim Übergang auf Festkommadarstellung ein einfaches Codieren des Algorithmus oft nicht zielführend ist, da insbesondere bei arithmetischen Operationen mit Datenüberläufen zu rechnen ist. Es ist dringend zu empfehlen, sich mit den möglichen Datenwerten, auch den Zwischenergebnissen zu befassen.

Zugriff auf Hardware mit besonderen Eigenschaften

Ein ganz anderes Thema sind Lese- und Schreibzugriffe auf Bereiche, die sich im Programm wie RAM-Speicher verhalten (Lese- und Schreizugriffe), diesen aber nur durch eine besondere Funktionalität emulieren. Wenn dann der Compiler oder der Treiber diesen Zugriff noch verdeckt, kann es schon zu unerwünschten Wechselwirkungen kommen.

Variablen im EEPROM

Das Thema „Variablen im ROM“ sieht nach einem Widerspruch in sich aus, stellt doch ein ROM einen Festspeicher, ein Read-Only Memory dar. Seit der Einführung von EEPROM, also einem elektrisch löschbarem, wiederbeschreibbarem ROM, ist das jedoch kein Widerspruch mehr, und einige Compiler unterstützen das sogar, indem mithilfe des (nicht-Standard-) Schlüsselwortes eeprom dem Compiler/Linker angezeigt wird, die Werte auch im EEPROM abzulegen.

Angenommen, ein Satz von 16 Daten soll in das EEPROM eines Mikrocontrollers geschrieben werden, weil die Werte bei Abschalten der Spannung gespeichert sein sollen. Dies können z.B. Konfigurationswerte sein, die bei jedem Neustart geladen werden.

Das Schreiben in das EEPROM wird wie erwähnt von entsprechenden C-Compilern mithilfe von Laufzeitbibliotheken unterstützt, aus Sicht der Anwendungsprogrammierung ist dies eine einfache Sache (siehe Listing 4 in der Bildergalerie).

Das Gefährliche an dieser Codesequenz ist, dass hinter der scheinbar einfachen Wertzuweisung an eepIBasicConfig[] eine ganze Laufzeitroutine mit blockierender Kommunikation steckt, was so nicht ersichtlich ist. Meistens wird der erste Wert sofort geschrieben (weil in der Hardware ein Pufferplatz vorhanden ist), ab dem zweiten Wert wartet man dann auf die Fertigstellung des Schreibens des Vorgängerwerts – was durchaus einige Millisekunden dauern kann.

Das Gefährliche an dieser Codesequenz ist, dass hinter der scheinbar einfachen Wertzuweisung an eepIBasicConfig[] eine ganze Laufzeitroutine mit blockierender Kommunikation steckt, was so nicht ersichtlich ist. Meistens wird der erste Wert sofort geschrieben (weil in der Hardware ein Pufferplatz vorhanden ist), ab dem zweiten Wert wartet man dann auf die Fertigstellung des Schreibens des Vorgängerwerts – was durchaus einige Millisekunden dauern kann.

Die Kunst der nicht-blockierenden Kommunikation

Die Kunst der nicht-blockierenden Kommunikation will es nun, dass man nur hineinschreibt, wenn dies sofort möglich ist (weil der Puffer oder das Netzwerk frei ist, die notwendigen Ressourcen also verfügbar sind), ansonsten sich merkt, dass noch etwas zu schreiben/lesen ist, und zur weiteren Programmausführung zurückkehrt. Hierbei muss dann gewährleistet sein, dass das Schreiben etwa durch zyklisches Design irgendwann fertig gestellt wird, und dass es keine Seiteneffekte gibt.

Ideal ist es hier, wenn man im Rahmen eines kleinen Betriebssystems einen Thread starten kann, der genau die gewünschte Aktion startet und sich mit dem gleichen Parameter aufruft, falls die Aktion nicht durchführbar war. Wenn der erneute Aufruf später wieder aktiviert wird, wird erneut geprüft, ob die Aktion durchzuführen ist, bis alles fertiggestellt ist bzw. anderweitig abgebrochen wird.

Dies bedeutet allerdings einen etwas höheren Initialaufwand. Wie es ohne Betriebssystem gemacht wird, steht beispielsweise in [1], ansonsten kann man solche nicht-blockierende Kommunikation auch in Interrupt-Service-Routinen, durch einen Timer aufgerufen, unterbringen.

Fazit

Es sollte hier exemplarisch gezeigt werden, was eine hardwarenahe Softwareentwicklung bedeutet und welche Konsequenzen das für die Entwicklung hat. Die Software verliert hierbei natürlich ihren Anspruch, Hardware-unabhängig und damit portierbar zu sein. Dies ist eine häufig implizit vorhandene extrafunktionale Anforderung.

Andererseits werden andere, ebenfalls extrafunktionale Anforderungen erfüllbar(er), so dass es sich lohnt, über einige Anpassungen nachzudenken.

In jedem Fall bedeutet hardwarenahe Softwareentwicklung, dass man sich mit der Hardware und ihren Eigenschaften und/oder den Eigenschaften von Datentypen befassen muss, sowohl, um diese auszunutzen, als auch, um nicht zu scheitern.

Literatur

[1] Christian Siemers, Embedded Systems Engineering Handbuch. http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/management/articles/340538/

* Christian Siemers ist Professor für Automatisierungstechnik an der TU Clausthal und Professor für Technische Informatik an der Hochschule Nordhausen.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44094515 / Implementierung)