Linux-Magazin Clean Linux (Vorschau)

Know-how
www.linux-magazin.de Embedded Debugging 09/2013
84
Fehlersuche auf Embedded-Systemen
Auf der Jagd
Auf der Pirsch nach Fehlern verlangen eingebettete Systeme dem Entwickler etwas mehr Einsatz ab als gewöhnliche
PCs. Gut also, wenn der Bug-Jäger die verschiedenen Techniken kennt. Anselm Busse, Jan Richling
ausführung zu gewährleisten, erhöhen
allerdings aufgrund eines erweiterten
Hardware-Aufbaus den Aufwand.
Eine dritte Variante von Debugging-Ansätzen
basiert auf Emulation. Diese bietet
einem Entwickler zwar große Flexibilität
bei der Arbeit, jedoch zu dem Preis,
dass die Emulation häufig nicht zu 100
Prozent mit der real existierenden Hardware
übereinstimmt. Potenziell kann es
daher zu nicht vorhersehbaren Fehlern
kommen.
© Barbara Reddoch, 123RF.com
Smartphones, Waschmaschinen, LCD-
TVs, Router, Industriesteuerungen, Digitaluhren
und Raspberry Pi haben gemeinsam,
dass sie statt eines x86-Prozessors
ein System-on-Chip mit einem oder mehreren
ARM-Kernen in sich tragen. Ihre
Bedien- und Kommunikations-Schnittstellen
sind deutlich eingeschränkt, was
sich nicht nur auf die Handhabung auswirkt,
sondern auch auf die Software-Entwicklung
und die damit einhergehende
Fehlersuche, die dieser Artikel besonders
beleuchtet. Zwar stehen ARM-Systeme
im Fokus, doch ist das Vorgehen prozessorunabhängig
und gilt für die meisten
eingebetteten Geräte.
Generell fallen Software und Hardware,
die der Embedded-Entwickler üblicherweise
ins Visier nimmt, höchst unterschiedlich
aus: Während Tablets in ihrer
Ausstattung herkömmlichen PCs ähneln,
besitzt die Steuerungshardware einer
Waschmaschine weder die für das gewohnte
Debugging notwendigen Schnittstellen
noch eine ausreichende Rechenleistung
oder Software-Unterstützung.
Kein Wunder also, dass sich die Ansätze
beim Debuggen unterscheiden und von
der Beschaffenheit der eingebetteten Geräte
abhängen.
Debug im Dreierpack
Grundsätzlich fallen die Debugging-
Ansätze im eingebetteten Bereich unter
drei Kategorien, die alle ihre Vor- und
Nachteile besitzen. In die erste Kategorie
gehören jene Methoden, die bestehende
Debugging-Techniken einfach auf
die eingebetteten Systeme ausdehnen.
Diese können auch Entwickler mit wenig
Erfahrung im eingebetteten Bereich
nutzen. Der Nachteil: Sie sind sehr restriktiv
hinsichtlich der Software auf dem
Zielsystem.
Die zweite Kategorie von Techniken setzt
zusätzliche Hardwareschnittstellen voraus,
die vornehmlich dem Debugging dienen.
Sie besitzen den Vorteil, die größtmögliche
Kontrolle bei der Programm-
Native Entwicklung
Die Fehlersuche lehnt sich in der Regel
eng an die eigentliche Entwicklung von
Software an. Diese unterscheidet sich
bei eingebetteten Systemen erheblich
von dem, was bei Desktop- oder Serversystemen
sonst üblich ist. Wer Software
für solche klassischen Systeme entwickelt,
greift heute in den meisten Fällen
auf einen Entwicklungsrechner zurück,
der häufig besser ausgestattet ist als die
Systeme, auf denen die Software später
laufen soll.
Theoretisch ließe sich die Entwicklung
auch auf dem Produktionssystem selbst
vornehmen, weil die Hardware in der
Lage ist, die Entwicklungsumgebung mitsamt
Benutzeroberfläche auszuführen. In
beiden Fällen ist das Testen der Software
sehr einfach, weil der Entwickler die Fehlersuche
auf demselben System erledigt.
Cross-Entwicklung
Bei eingebetteten Systemen funktioniert
dieser Ansatz nur selten. Zum einen verfügen
die Zielsysteme oft über andere
Prozessoren, zum Beispiel ARM, während
als Entwicklungsmaschinen üblicherweise
PCs mit x86-Prozessor dienen,