Debugging 2.0

Das Bild in diesem Blogbeitrag basiert auf einer Vektorgrafik von captainvector bei 123RF.

Was hält die Leute davon ab, einen Debugger zu benutzen? Nun, meistens sind es die anfänglichen Kosten für die Einrichtung der Debugging-Umgebung und das Erlernen des Umgangs mit dem Debugging-Tool. Ich hoffe, dass die nächste Version meines Hardware-Debugging-Tools dw-link, mit dem man klassische ATtinys und ATmegaX8s debuggen kann, diese Belastung etwas verringert, vor allem, weil man die dazugehörige Hardware jetzt bei Tindie kaufen kann.

Ausgangssituation

Die Arduino-IDEs bieten keine Unterstützung, wenn es um das Debuggen von klassischen ATtinys oder ATmegaX8s geht. Deswegen habe ich dw-link entwickelt, das deinen Arduino UNO in eine debugWIRE Hardware-Debugging-Sonde verwandelt, die eine gdbserver-Schnittstelle bietet. Außerdem habe ich zwei Möglichkeiten beschrieben, eine Debugging-Umgebung einzurichten. Leider ist eine davon etwas kompliziert und die Endergebnisse beider sind nicht ganz zufriedenstellend.

Inzwischen habe ich die Einrichtung vereinfacht und das Endergebnis ist zufriedenstellender. Zusätzlich erfolgt das Starten und Beenden des debugWIRE-Modus jetzt völlig automatisch. Der Debugger ist nützlicher geworden, weil er jetzt auch als ISP-Programmierer fungiert. Und schließlich ist der Hardwareteil einfacher zu bauen. Du kannst bei Tindie eine Platine, einen Bausatz oder ein komplett montiertes Board kaufen.

Debugging-Umgebungen

Beginnen wir mit den Debugging-Umgebungen. Ein Setup ist die Integration in die PlatformIO IDE. Das funktioniert reibungslos und das Einrichten der entsprechenden INI-Datei ist sehr einfach. Allerdings ändert die IDE die Art und Weise, wie du deinen Code schreiben und pflegen musst, komplett. Vor allem kannst du dich nicht mehr auf die Arduino-Magie verlassen und musst reinen C++-Code schreiben. Außerdem ist der Umgang mit den Bibliotheken ganz anders und die Auswahl der Ziel-MCUs erfordert mehr Überlegung. Obwohl die Änderungen nicht dramatisch waren, konnte ich mich nicht dazu durchringen, sie zu akzeptieren. Wenn du jedoch mit PlatformIO zufrieden bist, ist der Einrichtungsprozess selbst einfach und die GUI (im Grunde Visual Studio Code) ist angenehm. Der einzige Nachteil ist, dass PlatformIO eine Menge Schnickschnack hat, was die Arbeit mit der IDE manchmal etwas verwirrend macht. Für mich persönlich ist das nicht die Lieblingslösung.

Die alternative Einrichtung führt zur konsolenbasierten Oberfläche von GDB, was bedeutet, dass du dir eine große Anzahl von Befehlen merken musst, viel tippen musst und den Programmtext immer wieder auflisten musst. Die meisten Leute mögen das heutzutage nicht mehr. Und wenn du nur gelegentlich debuggst, ist es eine Herausforderung, sich alle GDB-Befehle zu merken. Im Gegensatz zur PlatformIO-Lösung kannst du jedoch das Arduino-IDE-Universum nicht verlassen und brauchst deine Arbeitsweise nicht ändern.

Was man wirklich gerne hätte, ist eine leichtgewichtige GDB-GUI. Und ich habe endlich eine gefunden, nämlich Gede. Sie ist leicht zu erstellen und die Oberfläche ist einfach und intuitiv. Leider funktioniert diese Lösung nur unter Linux und macOS.

Prozesse einrichten

Wie gesagt, ist das Einrichten des Debugging für PlatformIO so einfach wie das Kopieren einer INI-Datei in den Projektordner. Bei der GDB-Lösung war es etwas komplizierter. Du musstest einige der internen Parameterdateien bearbeiten, um debuggingfreundliche Binärdateien im Sketch-Ordner erzeugen zu können. Das habe ich stark vereinfacht, indem ich Board-Definitionsdateien zur Verfügung gestellt habe, die von den MiniCore- und ATTinyCore-Kernen abgeleitet sind. Außerdem habe ich eine Schnellstartanleitung erstellt, die es dir leicht machen sollte, ein erstes Debugging-Experiment zu starten.

Ein- und Ausstieg aus dem debugWIRE-Modus

Es gibt eine sehr lästiges Feature im Umgang mit debugWIRE, dem Protokoll, das für das Hardware-Debugging der klassischen AVR MCUs verwendet wird. Man gelangt in diesen Modus, indem man die DWEN-Fuse setzt und dann das Target aus- und wieder einschaltet. Das bedeutet, dass man bei „professionellen“ Debuggern (z.B. SNAP oder ICE) die Stromversorgung des Targets manuell aus- und wieder einschalten muss.

Man verlässt den Modus, indem man einen bestimmten debugWIRE-Befehl sendet und dann die DWEN-Fuse unprogrammiert. Wenn du das vergisst, bevor du den Debugger verlässt, kann die MCU nicht mehr mit einem ISP-Programmierer programmiert werden. Du musst den Debugger erneut aufrufen und den Modus verlassen.

Der dw-link-Debugger stellt in der Regel die Versorgung des Targets sicher und kann daher einen Power-Cycle durchführen, so dass ein Benutzer nicht darauf auchten muss, den Power-Cycle selbst durchzuführen. Außerdem verlässt der Hardware-Debugger beim regulären Verlassen des Debuggers den debugWIRE-Modus nun von selbst. Alles in allem muss man sich also nicht mehr um diesen Vorgang kümmern. Falls du die Zielplatine mit einer separaten Stromversorgung versorgen möchtest, kann dieser automatische Prozess mit einem Jumper deaktiviert werden.

Der Hardware-Teil des Hardware-Debuggers

Ein Hardware-Debugger wird nur dann zu einem festen Bestandteil meines Arbeitsablaufs, wenn er

• er mit 3,3-V-Systemen umgehen kann, d. h., er kann bedingte Pegelverschiebungen vornehmen,
• er genug Saft hat, um stromhungrige Boards mit bis zu 300 mA zu versorgen (um das automatische Power-Cycling zu ermöglichen),
• er die ISP-Leitungen deaktiviert, wenn sie nicht aktiv sind, und
• er als ISP-Programmierer fungieren kann.

Das neue Design erfüllt alle oben genannten Anforderungen. Außerdem ist es einfach zu bauen und die benötigten Teile sind sehr verbreitet. Abgesehen von 3 SMD-MOS-FETs kann man die Platine mit THT-Bauteilen bestücken. Die Platine, ein Bausatz und eine komplett montierte Platine werden im Tindie Store angeboten.

Das elektronische Design ist minimalistisch. Es verwendet nur drei MOS-FETs, eine LED, einen Spannungsregler und einige passive Bauteile. Die RESET-Leitung erfordert eine bidirektionale und die SPI-Leitungen benötigen eine unidirektionale Pegelwandlung. Die MISO-Leitung muss von 3,3-5 V auf 5 V angehoben werden und die MOSI- und SCK-Leitungen von 5 V auf 3,3-5 V abgesenkt werden. In den ersten beiden Fällen wird überhaupt keine Pegelverschiebung vorgenommen, da die Eingangspins des Hardware-Debuggers bereits bei 3,0 V einen logischen Wert erkennen. Das bedeutet allerdings, dass dieser Hardware-Debugger nicht mit Systemen umgehen kann, die eine Versorgungsspannung von weniger als 3 V verwenden.

Zum Herunterwandeln verwenden wir die Ausgangspins des Hardware-Debuggers in einer Open-Drain-Konfiguration und benutzen Pull-up-Widerstände. Diese Widerstände müssen einen relativen niedrigen Wert haben, weil eine Reihe möglicher Zielplatinen, z. B. der Arduino UNO, die SCK-Leitung zur Ansteuerung einer LED mit einem Vorwiderstand von 1 kΩ verwenden. Deswegen verwenden wir 680 Ω Pull-up-Widerstände, die garantieren, dass der Signalpegel auf der SCK-Leitung über 3 V liegt, wenn wir das Board mit 5 V versorgen. Diese Pull-ups werden deaktiviert, wenn keine ISP-Programmierung aktiv ist, sodass das Zielsystem die volle Kontrolle über die beiden Leitungen hat. Der Schaltplan sieht wie folgt aus.

Wie bereits erwähnt, habe ich auch einen ISP-Programmierer (es ist nur der Arduino als ISP-Code ) in die Firmware integriert. Das Tolle daran ist, dass der Hardware-Debugger anhand der verwendeten Kommunikationsgeschwindigkeit und des ersten gesendeten Befehls erkennt, ob er als Debugger oder als ISP-Programmierer angesprochen wird.

Zusammenfassung

Mit dem neuen Design sollte es einfacher sein, eine debugWIRE Debugger-Sonde zu bauen (oder zu kaufen) und eine zufriedenstellende Debugging-Umgebung einzurichten.