Suchen

Moderne Debugger Konkurrenz für Oszilloskop und Logikanalysator?

Autor / Redakteur: Jens Braunes * / Holger Heller

Manche Debugger bieten inzwischen umfangreiche und komfortable Funktionen für die schnelle grafische Aufbereitung riesiger Datenmengen. Aber können sie auch Oszilloskop und Logikanalysator ersetzen?

Firmen zum Thema

UAD2 von PLS: ermöglicht den Zugang zum Target über die Debug-Schnittstelle
UAD2 von PLS: ermöglicht den Zugang zum Target über die Debug-Schnittstelle
(Bild: PLS)

Debugger sind aus dem Alltag eines Softwareentwicklers nicht mehr weg zu denken, allerdings wird oft nur ein Bruchteil der verfügbaren Funktionen genutzt. Viele Entwickler bringen nach wie vor ausschließlich Breakpoints, Single-Stepping durch den Code und das Betrachten von Speicherinhalten und Variablen mit dem Debugger in Verbindung.

Speziell im Embedded-Bereich, wo Applikationen eng mit der Außenwelt verwoben sind, auf Eingangswerte der Peripherie reagieren müssen und Steuersignale generieren, bieten Highend-Debugger heute umfangreiche Visualisierung. Die erweiterten Debug-Möglichkeiten vieler aktueller Mikrocontroller greifen selbst aus Registern der Peripherie und Port-Pin-Registern umfangreiche Daten ab. Warum also den Debugger nicht auch als Oszilloskop oder Logikanalysator einsetzen?

Bildergalerie

Oszilloskope und Logikanalysatoren greifen die Daten und Signale über ihre Tastköpfe, also durch physikalische Verbindungen zu offenen Leitungen oder Pins, ab. Ein Debugger kann das nicht. Er benötigt dafür eine Debug-Schnittstelle, die vom jeweiligen Chip-Hersteller bereitgestellt werden muss. Hier liegt aber auch ein klarer Vorteil. Während mit den Tastköpfen nur auf nach außen geführte Signal- und Datenpfade zugegriffen werden kann, erlaubt ein Debugger auch einen Blick ins Innere des Controllers – zumindest soweit, wie die On-Chip-Debug-Hardware dies erlaubt.

Als weit verbreitete Debug-Schnittstelle gilt bislang JTAG. Die darzustellenden Daten werden hierbei seriell aus dem Chip geholt, was zwangsläufig nur mit begrenzter Geschwindigkeit funktioniert. Nicht nur allein die JTAG-Taktfrequenz, die bei einigen MCUs durchaus 50 MHz und mehr betragen kann, spielt hier eine Rolle. Auch der Overhead des Debug-Protokolls, welches sich um die Beschaffung der gewünschten Daten vom Target kümmert, beschränkt die Datenrate. Die nun tatsächlich mit JTAG erreichbaren Abtastfrequenzen bewegen sich im einstelligen KHz-Bereich.

Datenabgriff und Geschwindigkeit

Auf Seite des Debuggers stellen Debug-Probes wie das Universal Access Device 2 (UAD2) das Erreichen der erforderlichen Datenraten und einen periodischen Datentransfers zwischen Target und Debugger sicher. Low-End-Lösungen wie das Debugging über USB auf den Evaluierungsboards sind hierfür ungeeignet. Parallel zu JTAG haben sich in den letzten Jahren weitere Debug-Schnittstellen etabliert, die teilweise auch höhere Taktfrequenzen und damit auch höhere Abtastraten ermöglichen.

Eine weitere Möglichkeit zur effizienten Gewinnung der benötigten Daten ist Trace. Hier kümmert sich ausschließlich der Controller bzw. die Trace-Einheit des Controllers um die Erfassung. Eine Abtastung im eigentlichen Sinne gibt es hierbei nicht, vielmehr wird immer dann aufgezeichnet, wenn aktuelle Daten vorliegen. Grundsätzlich lassen sich mittels Trace viel höhere Raten als von klassischen Debug-Schnittstellen gewohnt generieren, theoretisch sogar bis hin zum Prozessortakt.

Ein begrenzender Faktor ist hier allerdings die Übertragung der Trace-Daten zum Debugger. Bei hohem Datenaufkommen, also gerade bei sehr hochfrequenten Signalen, kann es zudem zu Überläufen in internen Puffern kommen. In diesem Fall müssen Datenpakete verworfen werden, die resultierende Darstellung im Debugger ist dadurch fehlerbehaftet.

Visualisierung der gewonnenen Daten

Werfen wir nun einen Blick auf die unterschiedlichen Präsentationsmöglichkeiten. Wie erwähnt, bieten moderne Debugger neben den gewohnten textbasierten Darstellungen von Speicherdumps, Watch-Variablen oder Registerinhalten auch unterschiedliche Funktionen zur schnellen Visualisierung der gewonnen Daten.

Die einfachste Möglichkeit stellt dabei ein Wert-Zeit-Diagramm dar. Erfasste Werte werden auf der y-Achse, die Zeit auf der x-Achse auf getragen. Bei näherer Betrachtung ist die Herkunft der Zeit entscheidend. Im einfachsten Falle könnte die Systemzeit des PCs benutzt werden, auf dem der Debugger läuft. Allerdings lässt die Latenz des Übertragungsweges der Daten vom Target über die Debug-Probe bis zum Debugger auf dem PC kaum noch eine nutzbare Wert-zu-Zeit-Relation zu.

Artikelfiles und Artikellinks

(ID:42474187)