Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
48 Elektronik 10 2021 Embedded Technology Sobald der Anwendungscode geladen ist und ausgeführt wird ist ein umfassender Speichertest nicht mehr möglich Eine wortweise Prüfung kann jedoch möglich sein wobei etwas »Hintergrund«-CPU-Zeit verwendet wird Diese Art des Testens verwendet eine Reihe von Bitmustern um den Speicher auf festsitzende Bits und wortinternes Übersprechen zu überprüfen Listing 2 pattern testing for each type of memory { turn off interrupts save memory byte contents for values 0x00 0xff 0xaa 0x55 { write value to byte under test verify value of byte } restore byte data turn on interrupts } Listing 2 Dieser Test erlaubt eine wortweise Prüfung des Speichers im normalen Betrieb die im Hintergrund läuft und mit Bitmustern den Speicher auf festsitzende Bits und wortinternes Übersprechen überprüft Quelle Walls SoftwareFehler Typischerweise ist der komplexeste Teil eines eingebetteten Systems die Software Diese Komplexität bedeutet unweigerlich eine hohe Fehlerwahrscheinlichkeit Obwohl ein sorgfältiges Entwickeln gefolgt von umfassendem Debugging und Testen Fehler minimieren kann ist es sehr unwahrscheinlich dass es alle Möglichkeiten für Fehler ausschließt Durch eine defensive Codierung und das Einbauen von Prüfungen können die Auswirkungen von verbleibenden Codierungsfehlern aber minimiert werden Es gibt zwei Hauptarten von Softwarefehlern Datenfehler und Codeschleifen Datenfehler Die häufigste Ursache für Datenfehler in C-Code ist die Verwendung von Zeigern Zeiger sind eine sehr mächtige Funktion der Sprache aber diese Macht kann auch gefährlich sein Es gibt drei häufige Arten wie Zeiger Probleme verursachen ➔ Die Verwendung eines abgelaufenen Zeigers Üblicherweise ist ein Zeiger nur für eine bestimmte Zeit gültig und die Verwendung nach dieser Zeit kann unvorhersehbare Folgen haben Es ist gute Praxis einen Zeiger auf NULL zu setzen sobald seine Verwendung abgelaufen ist Ein Trap-Handler würde dann eine ungültige Verwendung danach abfangen ➔ Mangelnde Kompetenz bei der Zeigerarithmetik Insbesondere in Embedded-Anwendungen versuchen Entwickler möglicherweise »clevere« Dinge mit Zeigern um ihre Ziele zu erreichen Dies kann zu Fehlern führen insbesondere wenn der Programmierer die Zeigerarithmetik nur unzureichend beherrscht ➔ Übermäßiger Einsatz von Indirektion Ein Zeiger kann auf einen Zeiger zeigen der wiederum auf einen anderen Zeiger zeigen kann und so weiter Einige Ebenen der Indirektion sind nützlich um komplexe Daten zu handhaben Eine übermäßige Komplexität führt jedoch unweigerlich zu Fehlern Es gibt keine festen Regeln aber eine strikte Begrenzung die Indirektion auf nicht tiefer als Zeiger auf Zeiger auf Zeiger kann sinnvoll sein Wenn eine Memory Management Unit MMU zur Verfügung steht kann sie verwendet werden um den Speicher vor Zugriffen zu schützen und damit jegliche Datenfehler einzudämmen Das Überlaufen von aggregierten Datenstrukturen insbesondere des Stacks und der Arrays ist eine häufige Ursache für Datenfehler Vor allem Stacks sind problematisch Das Festlegen der Stack-Größen in einer Multithread-Anwendung kann eine Herausforderung sein auch wenn es Tools gibt die dabei helfen Wenn ein Stack überläuft wird die Aufgabe vermutlich ohne Probleme fortgesetzt Allerdings beschädigt der Überlauf wahrscheinlich den Stack eines anderen Tasks der möglicherweise abstürzt Diese Art von Fehler ist sehr schwer zu lokalisieren Ein Ansatz zur Abschwächung von Stack-Überläufen ist die Verwendung von »Schutzwörtern« Guard Words Dies sind zusätzliche Wörter an beiden Enden des Stacks die mit einem bekannten Wert geladen werden Dieser Wert sollte eine eher zufällige ungerade Zahl sein Im Hintergrund laufender Code Bild Mit Schutzworten eine zufällige ungerade Zahl am Anfang und Ende eines Stacks lässt sich sehr einfach überwachen ob der Stack überläuft Bild Walls