Interoperabilität ist Trumpf
Warum Standards gerade für Cross-Tools so wichtig sind
Fortsetzung des Artikels von Teil 1
Kopplung von Werkzeugen verschiedener Hersteller
Wie einfach eine Kopplung verschiedener Tools auf Basis von COM-Schnittstellen funktionieren kann, zeigt die Zusammenführung einer Entwicklungsumgebung mit Struktogramm- und Zustandsdiagramm-Editor von EasyCODE und der Universal Debug Engine von PLS. Der Anwender kann auf Struktogramm-Ebene debuggen, das heißt Einzelschritte ausführen, Unterbrechungspunkte setzen, das Target-Programm starten und stoppen und Variablen ansehen.
Zur Suche von Fehlern auf Struktogramm- und Hochsprachen-Ebene muss er den EasyCODE-Editor nicht verlassen. Die Steuerung des Targets wird von der UDE zeitgleich im Hintergrund ausgeführt. Da beide Tools synchron laufen, ist jederzeit ein Wechsel in den Debugger möglich, um zum Beispiel hardwarespezifische Probleme zu untersuchen (Bild 1).
Aber der Anwender kann die Tools auch selbst koppeln. Dazu nachfolgend ein praktisches Beispiel, das folgende Schritte umfasst: Starten eines Debuggers durch ein externes Skript, Übertragen einer Applikation in den Flash-Speicher des Target-Mikrocontrollers, Ausführung der Applikation für eine bestimmte Zeit, Starten von MS Excel und Anlegen einer Tabelle mit Daten aus dem Target.
Jobangebote+ passend zum Thema
Als Skriptumgebung dient die PowerShell 2.0, die ab Windows 7 Bestandteil jeder Windows-Installation ist. Für Windows XP und Vista gibt es Download-Pakete zur Nachinstallation. Die Powershell 2.0 ersetzt die frühere Windows-Kommandozeile und den Windows-Scripting-Host. Sie baut stark auf das .NET-Framework 2.0 auf und erweitert die Konzepte von herkömmlichen Shells, die Text mit Pipes und Filtern verarbeiten. Für den Umgang mit Objekten des .NET-Frameworks und COM-Objekten stellt Powershell mit der „PowerShell Scripting Language“ eine einfache Skript- Sprache zur Verfügung. Außerdem erleichtert eine kostenfreie Entwicklungsumgebung namens „Integrated Scripting Environment“ das Erstellen, interaktive Ausführen und Debuggen von PowerShell-Skripts.
Bild 2 zeigt die Zusammenarbeit der Werkzeuge als Blockschaltbild, das PowerShell-Skript sowie die Anzeige in MS Excel. Im ersten Abschnitt des Skripts (siehe Listing) wird eine Debugger-Instanz als COM-Objekt angelegt und damit das Debugger-Fenster minimiert gestartet. Als nächstes wird einem neu angelegten Workspace eine Target-Konfiguration übergeben. Anschließend wird die in Folge verwendete Schnittstelle mit den benötigten Debugger-Funktionen in der Variable $Debugger gespeichert und eine erfolgreiche Verbindung mit dem Target abgewartet.
Im Block 2 des Skripts wird zuerst ein Add-in des Debuggers zur Flash- Programmierung aktiviert, dann ein Applikations-File in den Debugger geladen und dieser anschließend in den Flash-Speicher des Mikrocontrollers geladen. Im Abschnitt 3 wird das Target nach der Flash-Programmierung zurückgesetzt und die Programmausführung im internen Flash gestartet. Nach zehn Sekunden wird die Applikation auf dem Target gestoppt.
Im vierten Skriptblock werden nach dem Start von MS Excel einige Daten aus dem Target gelesen, in eine Excel-Tabelle übertragen und als Datei abgespeichert. Bei entsprechender Gestaltung des Debugger-Objektmodells z.B. durch Aufzählungstypen und geeignete Variablennamen lässt sich auf diesem Weg gut lesbarer Skriptcode realisieren.
Das Ergebnis ist im Listing zu sehen. Das Skript ist bis auf die Definition einiger rechnerspezifischer Zeichenkettenvariablen ($WorkspaceFile, $TargetConfigFile, $ProgramFile, $ExcelFile) vollständig und so lauffähig.
- 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
