Die Programmentwicklung für eingebettete Systeme unterscheidet
sich doch etwas von der Entwicklung normaler Programme auf
einem PC. Wo normale Programme meistens auf der Plattform
entstehen unter der sie später auch ausgeführt werden
sollen, existieren in eingebetteten Systemen meistens nicht
genügen Ressourcen um die benötigte Entwicklungsumgebung zu
beherbergen. Die eigentliche Entwicklung findet daher auf einem
anderen Rechner statt (Host), erst das fertige,
ausführbare Programm wird in das eingebettete System
(Target) übertragen.
Konventionelle Programmentwicklung
Programmentwicklung für eingebetteter Systeme
Compiler
Für die Erzeugung eines ausführbaren Programms auf einer
anderen Zielarchitektur benötigt man einen Compiler, der Code
für diese Architektur generiert, einen sogenannten
Cross-Compiler. Im Rahmen dieser Veranstaltung wird hierzu
die GNU Compiler Collection mit Backends für die TriCore-, die
PowerPC- und die x86-Architektur verwendet.
Debugger
Während das erzeugen eines ausführbaren Programms für eine andere
Zielarchitektur noch relativ einfach ist, sieht es mit dem Debuggen
solcher Programme schon etwas komplizierter aus. Auch hier steht man
wieder vor dem Problem, dass der Debugger mangels Ressourcen meistens
nicht auf dem Target ausgeführt werden kann, sondern auf dem Host
läuft. Während beim Übersetzungsvorgang aber noch keine Interaktion mit
dem Target notwendig ist, ist sie beim Debuggen für das setzen von
Breakpoints oder das Auslesen von Variablen bzw. Registern
unumgänglich.
Debuggen eingebetteter Systeme
Zu diesem Zweck ist ein Verbindung zwischen Host und Target notwendig
und eine Art Protokollumsetzer, die zwischen dem eigentlich Debugger
auf dem Host und dem Target vermittelt. Hierzu gibt es zwei
Ansätze. Der erste ist eine eher Software-basierte Lösung, auf dem
Target existiert ein kleines Programm, ein sogenannter
ROM-Monitor (beim GDB spricht man von einem
GDB-Stub) der diese Funktion übernimmt und z.B. über eine
serielle Schnittstelle oder eine Ethernet-Schnittstelle mit dem Host
kommuniziert. Besonders neuere Mikrocontroller bieten für das Debuggen
eine Hardware-basierte Lösung über ein sogenanntes On-Chip Debug
System (davon existieren je nach Prozessorhersteller diverse
Spielarten: BDM, OCDS, OCD, JTAG, ...). Auf dem Host läuft dann ein
kleines Programm, das in die eine Richtung mit dem Debugger und in die
andere Richtung mit dem On-Chip Debug System.
Der TriCore, der im Rahmen dieser Veranstaltung verwendet werden soll
bietet z.B. ein solches OCDS, über das man das Programm mit dem GDB
auf dem Prozessor debuggen kann, in eingebettete Systemen basierend
auf x86-Prozessoren, geht man eher mit Hilfe eines ROM-Monitors auf
Fehlersuche, weil es hier keine entsprechende Hardwareunterstützung
gibt. Für dem PowerPC MPC565 existieren beide Varianten, der Prozessor
biete eine BDM-Schnittstelle an, es sind aber auch ROM-Monitore
verfügbar.
Als besonderen Leckerbissen, besitzt der Lehrstuhl für
TriCore-Prozessoren noch einen Trace32-Debugger von Lauterbach. Dieser
Debugger setzt auf das OCDS des TriCore-Prozessors auf und erlaubt
z.B. das bequeme Inspizieren und Modifizieren aller I/O-Register, das
Aufzeichnen (Tracing) von Maschinenbefehlen mit
dazugehörenden Zeitstempeln oder mit Hilfe dieser Aufzeichnung ein das
Programm schrittweise rückwärts auszuführen.