Interoperabilität ist Trumpf
Warum Standards gerade für Cross-Tools so wichtig sind
Fortsetzung des Artikels von Teil 2
Eclipse als Framework für Tools
Eine weitere enge Verknüpfung zwischen Werkzeugen entsteht, wenn ein Hersteller seine Tools in ein größeres Framework wie beispielsweise Eclipse einbettet. Während das ursprüngliche Eclipse als IDE konzipiert war, existiert seit der Version 3.0 nur noch ein Rahmen für so genannte Plug-ins, welche die eigentlichen Funktionen zur Verfügung stellen. Sowohl Eclipse selbst als auch die Plug-ins sind in Java implementiert. Das heißt aber nicht, dass Plug-ins keine Funktionalität aus nativen Code-Komponenten ausführen können. Auch die grafische Oberfläche von Eclipse, die auf dem Standard Widget Toolkit (SWT) basiert, setzt auf native GUI-Komponenten des jeweiligen Betriebssystems auf, auf dem die Java-Umgebung läuft. Eclipse und unter Umständen auch die Plug-ins sind damit nicht zwingend plattformunabhängig.
Die eigentliche Schwachstelle für eine erfolgreiche Cross-Entwicklung unter Eclipse ist nach wie vor die um Fenster für Speicher, Register und Disassembler ergänzte und als eigene Perspektive implementierte erweitere Debugger- Komponente von CDT. Die Eclipse Foundation propagiert zwar den Einsatz von Eclipse auch für Embedded Development, aber eine Java- Applikation auf einem Smartphone unterscheidet sich in den Debug- und Testanforderungen nun einmal erheblich von einer C-Anwendung auf einem industriellen oder automotiven Steuergerät.
Für die beiden letzteren Anwendungsfälle fehlt dem Standard-CDTDebugger u.a. die Möglichkeit, während der Laufzeit des Targets auf den Speicher zuzugreifen und Werte im Debugger zu aktualisieren. Außerdem sind weder eine Darstellung von Peripherie- Registern – bei modernen Mikrocontrollern sind dies oft mehrere Hundert – noch eine Auswertung von Trace-Daten für Code-Coverage und -Profiling möglich. Beide müssen ohne einen Stopp des Target ausgelesen und visualisiert werden. Das Debugging- Modell beruht allein auf der Betrachtung des Targets im angehaltenen Zustand, was für moderne Cross-Debugger- Lösungen nicht ausreicht.
Jobangebote+ passend zum Thema
Um dieses Dilemma zu eliminieren, stellen moderne Tools wie die Universal Debug Engine inzwischen ihre komplette Funktionalität ohne Abstriche in einer eigenen Debug-Perspektive zur Verfügung. Möglich wird dies durch den komponentenorientierten Tool-Aufbau mit strikter Trennung von Funktion und Bedienoberfläche. Ein relativ kleiner, in Java geschriebener Wrapper, das UDE Eclipse Plugin, verbindet Eclipse mit den Funktionskomponenten der UDE. Hierfür werden neben dem SWT-basierten Window- und Menü-Service der Eclipse-Workbench auch das Debug- Interface eines installierten CDT sowie Schnittstellen des SWT zu Win32-Native-Funktionen genutzt (Bild 3).
Das UDE Eclipse Plug-in ist – wie die Universal Debug Engine selbst – nur auf Windows-Plattformen verfügbar. Die Installation erfolgt mit den von der Plattform zur Verfügung gestellten Standardmechanismen. Zur Anzeige der debuggerspezifischen Fenster werden Eclipse-Views verwendet, des weiteren wird eine Synchronisierung mit den geöffneten C/C++-Editoren vorgenommen. Die Darstellung der UDE-Fenster in Eclipse-Views ermöglicht dem Anwender eine Nutzung aller Cross-Debugger-Features, die weit über den Standard-CDT-Debugger hinausgehen. Die verfügbaren Funktionen reichen vom konfigurierbaren periodischen Refresh aller Target-Speicher darstellenden Fenster während der Laufzeit der Applikation und der grafischen Darstellung von Anwendungsvariablen, Profiling und Coverage-Funktionen über RTOS-Support und die Darstellung von Peripherie-Registern (SFR) im Klartext bis hin zur Trace-Daten-Analyse. Sogar die Verwaltung von mehreren Debugger-Instanzen für Multicore-Debugging wird ohne Einschränkungen unterstützt.
Der Wunsch der Anwender, Werkzeuge nahezu beliebig zu eigenen Arbeitsabläufen (Workflows) kombinieren zu können, stellt die Tool- Hersteller vor neue Herausforderungen. Um den Aufwand sowohl für die Anwender als auch die Tool- Anbieter in vernünftigen Grenzen zu halten, ist die Verwendung von Standards unerlässlich. Der Beitrag zeigt: Werden geeignete Basistechnologien wie das Component Object Model (COM) und .NETFramework bereits beim Design eines Werkzeugs berücksichtig und entsprechende Schnittstellen wie im Fall der UDE von PLS gleich von Anfang an mit implementiert, ist es letztlich aber gar nicht so schwer, unterschiedliche Werkzeuge mit vertretbarem Aufwand zu eigenen Workflows zu kombinieren.
Der Autor:
| Dipl.-Ing. Heiko Rießland |
|---|
| war nach Abschluss des Infomationstechnik- Studiums an der Technischen Universität Dresden zehn Jahre in der Entwicklung und im Vertrieb von Software-Entwicklungswerkzeugen und Emulatoren für 16- und 32-bit-Mikrocontroller tätig. Seit sieben Jahren leitet er das Produktmarketing der pls Programmierbare Logik & Systeme GmbH. |
heiko.riessland@pls-mc.com
- Warum Standards gerade für Cross-Tools so wichtig sind
- Kopplung von Werkzeugen verschiedener Hersteller
- Eclipse als Framework für Tools
Lesen Sie mehr zum Thema
