Echtzeitsysteme 2 - SS 2006

Werkzeuge

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 eingebette Systeme

Für die Erzeugung eines ausführnaren 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.

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 Überstzungsvorgang 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 eingebetter 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, bestitzt 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.

Lauterbach Trace32