Schwerpunkte

Praxistest Debug&Trace

Auf Spurensuche

28. September 2018, 11:02 Uhr   |  Dr. Constantin Tomaras, Ressortredakteur für Systemdesign, DESIGN&ELEKTRONIK


Fortsetzung des Artikels von Teil 1 .

Nutzerschnittstelle

Für jedes der Produkte finden wir eine graphische Nutzeroberfläche (Bild 2a, 2b, 2c, 2d): bei ULink plus das Keil uVision (Bild 2a), für µTrace das PowerView (Bild 2b), J-Trace Pro hat das Ozone-GUI (Bild 2d) und UAD2next ist Teil der Universal Debug Engine (Bild 2c).

Bild 2a: Der elementare Debugbildschirm im uVision.
© DESIGN&ELEKTRONIK

Bild 2a: Der elementare Debugbildschirm im uVision.

Bild 2b: Der elementare Debugbildschirm im PowerView.
© DESIGN&ELEKTRONIK

Bild 2b: Der elementare Debugbildschirm im PowerView.

Bild 2c: Der elementare Debugbildschirm in der Universal Debug Engine am STM32F103.
© PLS Programmierbare Logik & Systeme

Bild 2c: Der elementare Debugbildschirm in der Universal Debug Engine am STM32F103.

Bild 2d: Der elementare Debugbildschirm im Ozone.
© DESIGN&ELEKTRONIK

Bild 2d: Der elementare Debugbildschirm im Ozone.

PowerView und Ozone haben einen starken Skripthintergrund. Beide GUIs zeigen und schreiben im Hintergrund eine Skriptdatei, die einer Konsolenära entstammt. Das Ozoneskript liest sich wie ein C-Code, das Handbuch zeigt dazu eine vollständige Wortliste. Im Ozone-GUI ist eine reduzierte Kommandoliste als Übersicht hinterlegt. 

Bei PowerView ist man von der lua-artigen Skriptsprache wohl nie los gekommen: dem GUI ist die Befehlszeile B:: zentral, manche elementaren Funktionen erreicht man nur von dort aus. Ein Pushbutton-Menue unter der Befehlszeile unterstützt den Nutzer im Erstellen der richtigen Befehle - so etwas kennt man eigentlich sonst nur von Mobiltelefonen, ist aber ähnlich effektiv!

UDE und uVision sind vollständig graphische Produkte, die über eine Skriptsprache im Windows-Framework automatisiert werden können.

Betriebssysteme und Installation

Der Installationsaufwand hält sich bei allen Systemen zunächst in Grenzen und bedeutet unabhängig von den getesteten Betriebssystemen nur das Ausführen einer Datei oder eines Shell-Skriptes. uVision und UDE sind windowszentrisch, Ozone arbeitet auch unter MAC und Linux, PowerView hat darüber hinaus sogar Betriebssystem-Support bis hin zu Servervarianten wie (Solaris/Citrix/Hp). Das ist dahingehend spannend, als dass so ein Blocksatz aus einer Spur gerne mal ein paar Gigabyte groß wachsen kann. Einen Blocksatz dieser Größe sollte man aus Performanzgründen eher auf den in der Numerik etablierten Plattformen analysieren.

Einbindung in Workflow

ULink plus wurde von arm in die zugehörige IDE zur μC-Programmierung integriert. Segger bietet mit dem Embedded Studio ebenfalls eine geschlossene Werkzeugkette. Debug-&-Trace-Software wie Ozone für J-Trace pro setzt nach dem Kompilierschritt an. Für kleine Modifikationen hilft ein Weg den ursprünglichen C-Code innerhalb des Debuggers editieren und speichern zu können enorm***). Im PowerView geht das unmittelbar, in dem der C-Code einfach als Skript geöffnet, editiert und gespeichert wird. Der Compiler lässt sich über den Terminalbefehl Os.Window<Compiler> auslösen. Bei J-Trace Pro ist die Open-Source-Unterstützung erwähnenswert: damit wird die Integration in viele weitere IDEs möglich (Tabelle 5). Tutorials, zur Einbindung der Segger-Hardware in eine offene Werkzeugkette für die arm-Programmierung, sind ebenso zahlreich wie populär [5].

ULink plusMDKUDE/UADGCC, Dwarf-Standard Version2J-Trace ProGCC, clang/LLVM, IAR ICCARM, Arm/Keil armcc, Arm/Keil compilerµTraceARMCC, GCCARM, ICCARM, HIGH-C, TI-C, D-CC

Tabelle 4: Einige unterstützte Kompiler

ULink plusuVisionJ-Trace ProIAR Embedded Workbench, Keil uVision, VisualGDB, Embedded StudioµTraceCodewright, Easycode, Eclipse, Simulink, Labview, VivadoUDE/UADEclipse-basiert, oder COM-basierte Object Model Schnittstellen

Tabelle 5: Einige unterstützte Toolchains

Software

Framing

uVision, UDE und Ozone integrieren eine automatische Platzierung der Fenster im Standardrahmen: der Nutzer steuert die Platzierung über Drag & Drop. Richtig flüssig gelingt das allerdings nur in der UDE.

In allen Umgebungen ist die Übersichtsgrenze bei maximal vier Fenstern in einem Standardrahmen auf dem 14-Zoll-Bildschirm erreicht. Obige drei Produkte integrieren die Fähigkeit, Unterfenster aus dem Standardrahmen herauszulösen. Auf einem 16:9-Bildschirm kommen so noch einige weitere Anzeigen außerhalb unter. PowerView löst Analysefenster nur per Konsolenbefehl aus dem Standardrahmen.

uVision startet mit Programmerstellung, dem Kompilieren und Flashen. Danach wird die Umbegung händisch in den Debugmodus umgeschaltet, der ganz andere Fenster und Menüs zeigt.

Implementierung der Grundfähigkeiten

Die Grundfähigkeiten für das Debugging sind letztendlich an die Struktur des Programmiermodells gekoppelt. Ein Werkzeugmacher sollte die kleinste Menge an Elementarwerkzeugen bereit stellen, die eine vollständige Analyse in Funktion und Performanz erlaubt.

Tatsächlich finden wir in allen Debugtools die selben Grundfunktionen (Tabelle 8). Aber nicht, weil diese uns zum mächtigen Mikrorechnerverifikator rüsten. - Es sind vielmehr rudimentäre Einzeltestverfahren um die Implementierungsperformanz durch den Kompilierschritt und letztendlich auf der Zielplattform in der Ausführung zu messen. Dinge wie ein effizientes Suchverfahren zur Identifizierung seltener Ereignisse in dem großen Blockdatensatz oder eine Testautomatisierung im Sinne von HIL-Verfahren, kommen nicht vor: Das müsste der Anwender selbst durch externes Coden/Skripten leisten.

Obwohl alle Werkzeuge die gleichen grundlegenden Funktionen und Darstellungen besitzen, unterscheiden Bezeichnung und Sortierung sich von Tool zu Tool. Bei uVision, UDE und Ozone finden wir für dieselbe Funktion ähnliche Bezeichnungen, aber mit anderer Menü-Priorisierung. Die Bezeichnungen im PowerView weichen deutlich ab und sind sehr technisch, eher als man sie in einem Kontrollraum erwartet.

Tabelle 8 listet die Menüs und ihre jeweiligen Einträge in struct-Schreibweise, das verrät schon vieles über den Funktionsumfang und die zugrundeliegende Bedienphilosophie. Im Folgenden werden Grundfähigkeiten und ihre jeweilige Umsetzung diskutiert.

Seite 2 von 7

1. Auf Spurensuche
2. Nutzerschnittstelle
3. Debug- & Tracefunktionen
4. Manipulation des Zielzustandes
5. Darstellung der Zieldynamik
6. Alleinstellungsmerkmale
7. Fazit

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Das könnte Sie auch interessieren

ARM kauft Treasure Data
Automatisch Testen mit ARMs DS-5
Bluetooth 5 und Bluetooth-Mesh
arm unveiled Cortex-A roadmap by 2020
Universalwerkbank für Mikrocontroller
ARM Approved Design Partner

Verwandte Artikel

ARM Germany GmbH, Lauterbach GmbH, pls Programmierbare Logik & Systeme GmbH, SEGGER Microcontroller GmbH & Co. KG