Cross-Entwicklung mit Eclipse
Darüber hinaus bietet Eclipse mit den C/C++ Development Tools (Eclipse-CDT) eine gut gefüllte, aus mehreren Plug-ins der Eclipse Foundation bestehende Werkzeugkiste für die C/C++-Entwicklung an. Sie enthält unter anderem das Projekt- und Build-Management, einen leistungsfähigen Editor mit Syntax-Hervorhebung, Navigationsunterstützung und Refactoring-Fähigkeiten sowie zahlreiche, auf statischer Quelltextanalyse beruhende Funktionen wie die Darstellung der Typ-Hierarchie, Aufruf-Graphen, Browser für Include-Dateien und Makro-Definitionen. Außerdem ist ein um Fenster für Speicher, Register und Disassembler ergänztes Quelltext-Debugging vorgesehen. Die Implementierung beruht beispielhaft auf dem GNU-Compiler und dem GNU-Debugger (gdb).
Einziger Schwachpunkt für die Nutzung als Cross Development Platform ist die Debugger-Komponente der Eclipse-CDT. Ihr Modell legt die Betrachtung des Targets im angehaltenen Zustand zu Grunde, ein Ansatz, der sich mit den Anforderungen moderner Cross-Debugger nicht deckt. So bietet die Debugger-Komponente von Eclipse leider nach wie vor keinerlei Möglichkeiten, zur Laufzeit des Targets auf den Speicher zuzugreifen und Werte im Debugger zu aktualisieren. Trace-Daten für Code-Coverage und -Profiling, die ebenfalls ohne Anhalten des Targets ausgelesen und visualisiert werden müssen, lassen sich so nicht auswerten. Peripherie-Register - bei modernen Mikrocontrollern sind dies oft mehrere hundert - können nicht interaktiv zur Laufzeit dargestellt werden.
Das erklärt auch, warum sich die Unterstützung von Eclipse durch Emulator- und Debugger-Hersteller bislang zumeist auf sogenannte Call Plug-ins beschränkt. Mit ihrer Hilfe lassen sich herstellerspezifische Debugger-Bedienoberflächen von Eclipse aus starten, und das Setzen von Breakpoints in beiden Oberflächen oder z.B. das wechselseitige Öffnen von Dateien ermöglicht eine gewisse Synchronisation. Die volle Leistungsfähigkeit für den Test, das Debugging und eine Systemoptimierung stehen aber nur im separat ausgeführten Tool des Debugger-Herstellers zur Verfügung.
Ein anderer Ansatz zur Aufwertung des integrierten Eclipse-Debuggers ist das Nachrüsten von bestimmten Views für die Anzeige der Special Function Registers und der Echtzeit-Variablen. Die Funktionsweise bleibt aber auch hier ein meist unbefriedigender Kompromiss zwischen dem in CDT integrierten Debugger und der herstellerspezifischen Bedienoberfläche.
Live-Debugging bei laufendem Zielsystem
Einen Ausweg aus diesem Dilemma bietet also nur die Implementierung einer kompletten Debug-Perspektive innerhalb von Eclipse. Im nachfolgenden Beispiel stellt diese dem Entwickler den kompletten Funktionsumfang der Universal Debug Engine (UDE) von PLS zur Verfügung. Möglich ist dies nur durch den komponentenorientierten Aufbau der UDE mit strikter Trennung von Funktion und Bedienoberfläche (Bild 2).
Das UDE Eclipse Plug-in, ein relativ dünner, in Java geschriebener Wrapper, stellt die Verbindung zwischen Eclipse und den Funktionskomponenten der UDE her. Neben dem SWT-basierten Window- und Menü-Service der Eclipse-Workbench werden dafür auch das Debug-Interface eines installierten CDT sowie Schnittstellen des SWT zu Win32-Native-Funktionen genutzt. Das UDE Eclipse Plug-in ist somit wie die Universal Debug Engine auch nur auf Windows-Plattformen verfügbar.
Die Installation erfolgt mit den vom Framework zur Verfügung gestellten Standardmechanismen. Für die Anzeige der Debugger-spezifischen Fenster werden Eclipse-Views verwendet; außerdem erfolgt eine Synchronisierung mit den geöffneten C/C++-Editoren.
Die Darstellung aller UDE-Fenster in Eclipse-Views macht Cross-Debugger-Funktionen nutzbar, die weit über den Standard-CDT-Debugger hinausgehen. Dazu zählen beispielsweise ein konfigurierbarer periodischer Refresh aller Fenster, die Target-Speicher darstellen - auch zur Laufzeit der Applikation. Weiterhin gehören zu den Eigenschaften die grafische Darstellung von Anwendungsvariablen, Profiling und Coverage-Funktionen, RTOS-Support, die Darstellung von Peripherie-Registern (SFR) im Klartext sowie eine Trace-Daten-Analyse. Sogar die Verwaltung von mehreren Debugger-Instanzen für Multicore-Debugging wird ohne Einschränkungen unterstützt (Bild 3).
Eine Debug-Session kann einfach als Launch-Konfiguration definiert und vom C/C++-Editor aus in einer eigenen Cross-Debugger-Perspektive gestartet werden. Breakpoints lassen sich sowohl im C/C++-Editor als auch im Debugger selbst setzen. Ihre Anzeige erfolgt wie die des Befehlszählers in allen Perspektiven synchron. Darüber hinaus lassen sich in der UDE-Perspektive auch C/C++-Editoren nutzen. Die Pfade von Quelldateien werden vom UDE Plug-in direkt aus dem Workspace gelesen. Dies garantiert die für Eclipse typische Konsistenz im Entwicklungsablauf.
Ein Plug-in für viele Anwendungsbereiche
Der beschriebene Lösungsansatz einer kompletten Cross-Debugger-Perspektive verbindet erstmals die Vorteile des universellen, flexiblen Eclipse-Konzepts mit der vom Anwender geforderten Leistungsfähigkeit moderner Cross-Debugger. Das Eclipse Plug-in ist für alle von der UDE unterstützten Mikrocontroller-Architekturen und -Familien, darunter TriCore, Power-Architektur, Cortex, ARM und XC2000/XE166 verfügbar. Neben angepassten Eclipse-Plattformen 3.4 bis 3.7 (Ganymede, Galileo, Helios und Indigo) von verschiedenen Compiler-Herstellern werden auch selbst konfigurierte Eclipse-CDT-Plattformen dieser Versionen unterstützt; ein Support der Eclipse-Version 4.2 (Juno) mit einer komplett neu strukturierten Programmierschnittstelle für Plug-ins ist für 2013 in Vorbereitung.
Der Autor
Dipl.-Ing. Heiko Rießland |
---|
war nach erfolgreichem Abschluss des Infomationstechnik-Studiums an der Technischen Universität Dresden zwölf Jahre in der Entwicklung und dem Vertrieb von Software-Entwicklungswerkzeugen und Emulatoren für 16- und 32-bit-Mikrocontroller tätig. Seit acht Jahren leitet Rießland das Produktmarketing der PLS Programmierbare Logik & Systeme GmbH. |
heiko.riessland@pls-mc.com