Startseite > Embedded > Entwicklungstools > Warum Standards gerade für Cross-Tools so wichtig sind

Interoperabilität ist Trumpf

Warum Standards gerade für Cross-Tools so wichtig sind

29. Oktober 2010, 14:42 Uhr | Von Heiko Rießland

Wer als Entwickler schnell und flexibel auf sich ständig ändernde Anforderungen reagieren muss, ist heutzutage auf Werkzeuge angewiesen, die sich ohne exorbitanten Aufwand zu einem eigenen Workflow kombinieren lassen. Wie viel Interoperabilität ein Werkzeug im Alltagseinsatz tatsächlich bietet, entscheidet sich allerdings bereits beim Design des Tools.

▶ Diesen Artikel anhören

Die Idee, Einzelergebnisse unterschiedlicher Programme zur Erzielung eines Gesamtergebnisses zu kombinieren, ist nicht neu. Schon zu der Zeit, als Computer nur über eine Kommandozeilen-Oberfläche (Unix-Shell, MS-DOS) bedient wurden, konnten mit dem „Pipe“-Mechanismus bereits mehrere Werkzeuge miteinander verkettet werden. Die Ausgabedaten des einen wurden so zu den Eingabedaten für das nächste Programm. Allerdings war die notwenige Standardisierung der zumeist textlichen Ausgaben damals noch ein Kinderspiel, da Betriebssystem, Shell und Programme von ein und demselben Hersteller stammten.

Die Einführung grafischer Bedienoberflächen und das nach wie vor ständig weiter wachsende Angebot an unterschiedlichsten Werkzeugen stellt die Hersteller von Entwicklungs-Tools allerdings seit geraumer Zeit vor völlig neue Herausforderungen, wie die nähere Betrachtung von Cross-Entwicklungswerkzeugen für Windows-Hosts beweist.

Cross-Tools – dazu zählen vor allem Compiler und Debugger, aber auch Werkzeuge für Modellierung, Kalibration, Test usw. – laufen per Definition auf einer anderen Hardware als die eigentliche Zielapplikation. Dabei lassen sich verschiedene Stufen der Interoperabilität unterscheiden. Gängig ist inzwischen die Verwendung standardisierter Dateiformate wie dem ELF/DWARF-Format, das sowohl den Maschinen-Code für die Zielapplikation als auch Informationen für das Debuggen enthält. Die Zusammenarbeit unterschiedlicher Compiler und Debugger/Emulatoren stellt hier meist kein Problem dar und wird von den Anwendern als selbstverständlich vorausgesetzt.

Für die strukturierte Ablage von Daten kommt immer häufiger auch XML zum Einsatz. Bei der Universal Debug Engine (UDE), einem Cross- Debugger für 16/32-bit-Mikrocontroller verschiedener Hersteller, werden alle bausteinspezifischen Beschreibungen bereits seit knapp zwei Jahren in diesem Format abgelegt, weil XML gegenüber proprietären Formaten ein einfaches Hinzufügen von applikationsspezifischen oder nicht dokumentierten Peripherie-Registern und gegebenenfalls sogar die Korrektur der Definitionen durch den Anwender erlaubt. Ebenso exportiert der Debugger Daten, z.B. über den zeitlichen Verlauf von Systemparametern, im XMLFormat. Dies gestattet eine einfache Weiterverarbeitung durch andere Werkzeuge wie z.B. MS Excel.

Von der passiven zur aktiven Zusammenarbeit

In beiden Fällen – sowohl bei der Verwendung standardisierter Dateiformate als auch von XML – handelt es sich um eine passive Form der Interoperabilität, bei der keine zeitgleiche Zusammenarbeit von Tools erforderlich ist. Für den Entwickler viel interessanter, weil wesentlich flexibler, sind aktive Lösungen, bei denen verschiedene Werkzeuge direkt zu einem kontinuierlichen Arbeitsablauf (Workflow) zusammengefügt werden. Dies kann entweder von den beteiligten Herstellern oder sogar durch den Anwender selbst erfolgen, wobei eine Kopplung durch den Anwender in der Regel ein höheres Maß an Standardisierung, Dokumentation und ggf. Training voraussetzt.

Ziel einer aktiven Lösung ist es, dass die verwendeten Werkzeuge entweder direkt interagieren können oder über ein den Gesamtablauf steuerndes Programm zusammenarbeiten. Grundvoraussetzung dafür sind allerdings definierte und im Idealfall standardisierte Schnittstellen zwischen den Tools. Eine einfache C-DLL-Schnittstelle scheint hier nicht mehr unbedingt zeitgemäß. Wesentlich interessanter als Schnittstellen-Basis ist das manchmal auch mit ActiveX bezeichnete Component Object Model (COM), nicht zu verwechseln mit den an modernen PCs aussterbenden seriellen Schnittstellen (COM1, ...). COM erlaubt nicht nur eine programmatische Nutzung von C/C++ und Programmiersprachen aus der .NET-Welt wie C#. Das Component Object Model erschließt Anwendern vor allem auch eine Vielzahl von Script-Sprachen wie Java Script, Phyton, Perl, Visual Basic Script oder Windows Power Shell, die die Ansteuerung von COM-Komponenten erlauben. Damit kann sich der Anwender mit geringem Einarbeitungsaufwand eigene Arbeitsabläufe schaffen, was wiederum zu spürbaren Einspareffekten zum Beispiel bei der Testautomatisierung führt.

Da die von Anfang an mit COMSchnittstellen ausgestattete UDE diese Technologie auch für interne Skripts und anwendungspezifische Fenster auf Basis von HTML verwendet, können Anwender die Funktionen der Universal Debug Engine nutzen, ohne vorher extra eine proprietäre Makrosprache lernen zu müssen. Das Beherrschen einer standardisierten Skriptsprache und die Kenntnis des Objektmodells reichen vollkommen aus. Als Objektmodell wird bei COM die Gesamtheit aller dokumentierten Objekte, Methoden, Eigenschaften und Datentypen bezeichnet. Damit lassen sich nahezu alle Aspekte der Universal Debug Engine inklusive Add-ins wie UDE/Mem- Tool zur Flash-Programmierung oder CAN-Recorder von intern oder extern durch Skripte steuern bzw. nutzen. Ein integrierter Skript-Debugger hilft bei der Erstellung korrekt ablaufender Automatisierungen.