Über das quadratische rote Icon verlassen Sie bei Bedarf den Einzelschrittmodus, das Programm läuft dann ungebremst weiter, allerdings nach wie vor im Debug-Modus. Zeitkritische Aktivitäten sind so nicht möglich.
Stoppschilder
Ein einfaches Weiterlaufen würde die Debug-Session praktisch beenden, denn der Prozessor arbeitet dann stur alle Befehle der Reihe nach in einer Endlosschleife ab. Das kann durchaus sinnvoll sein, aber in aller Regel möchten Sie noch irgendwo eingreifen. Deshalb stellen Sie vorher an geeigneter Stelle ein Stoppschild auf, im Englischen Breakpoint genannt. VSC bezeichnet die Breakpoints in der deutschen Oberfläche als Haltepunkte. Implizit existiert so ein Haltepunkt auch am Programmstart.
Neue Haltepunkte erstellen Sie durch einen Doppelklick auf die Zeilennummer der gewünschten Zeile, die VSC dann wie in Abbildung 6 mit einer roten Markierung verziert. Analog entfernen Sie den Breakpoint wieder. Alternativ nutzen Sie die Liste aller Haltepunkte in der linken Spalte, die Sie dazu eventuell erst aufklappen müssen. Dort können Sie die Breakpoints durch Entfernen des Hakens auch temporär deaktivieren.
Abbildung 6: Codezeilen mit Haltepunkten erkennen Sie an der roten Markierung vor der Zeilennummer.
Läuft Ihr Programm nicht wie gewünscht, haben Sie in aller Regel einen Verdacht, woran das liegt. Um den Debug-Prozess abzukürzen, setzen Sie dann am Anfang der kritischen Funktion einen Haltepunkt, starten den Debugger und lassen ihn bis zum Haltepunkt weiterlaufen. So sparen Sie sich viele Klicks.
Variablen
Die IDE führt während der Ausführung eines Programms im Debug-Modus Buch. Dazu zählt vor allem die Aufrufliste, die den Pfad zum aktuellen Programmteil samt Parameter enthält. Die Liste der Variablen gibt ergänzend dazu den aktuellen Wert der lokalen und globalen Variablen wieder (Abbildung 7). Das Schöne daran: Sie dürfen die Variablen jederzeit ändern.
Abbildung 7: Liste mit Variablen.
Möchten Sie zum Beispiel Temperaturwerte unter null in Blau ausgeben, müssen Sie nicht auf einen Wintertag warten und beobachten, ob Ihr Programm richtig tickt. Einfacher klappt das mit einem Breakpoint nach dem Auslesen des Sensors. Anschließend überschreiben Sie den Messwert und lassen dann das Programm weiterlaufen.
Was nicht geht
Mit den hier beschriebenen Abläufen lassen sich viele Probleme lösen, allerdings nicht alle. Der Debugger von VSC hat noch einige Asse im Ärmel, die eventuell weiterhelfen. Über die linke Spalte können Sie sich zum Beispiel die Register oder bestimmte Speicherbereiche anzeigen lassen. Im Alltag benötigen Sie diese Funktionen aber eher selten.
Trotz der Mächtigkeit versagt der Debugger aber bei einer ganzen Klasse von Problemen. Alles, was mit der zeitlichen Abfolge von Ereignissen zu tun hat, kann er nicht lösen, denn der Messvorgang beeinflusst das Programm durch die extrem verlangsamte Ausführung massiv. Initialisiert der Pico einen Sensor falsch, liegt das vielleicht daran, dass die MCU einfach zu schnell taktet und damit die Initialisierungsbefehle den Sensor in zu schneller Abfolge erreichen. Im Debug-Modus existiert dieses Problem jedoch faktisch nicht, der Fehler scheint einfach nicht vorhanden zu sein.
Da der Pico zwei CPU-Kerne hat, treten ähnliche Probleme auch bei Anwendungen auf, die beide Kerne nutzen. Die Koordination von zwei parallelen Programmteilen ist alles andere als trivial, und minimale Änderungen des zeitlichen Ablaufs führen oft zu einem ganz anderen Verhalten des Programms.
Fazit
Dieser Artikel konnte lediglich die Grundfunktionen des Debuggers von Visual Studio Code vorstellen. Möchten Sie tiefer in die Materie einsteigen, sollten Sie die gute Dokumentation lesen. Aber selbst mit den Basisfunktionen kommen Sie als Entwickler schon sehr weit.
Beim Autor hat sich inzwischen folgendes Vorgehen eingebürgert: Zuerst entsteht ein Prototyp auf dem Pico mit Python – das geht schnell und dank der vielen Bibliotheken mit sehr wenig Code. Danach folgt falls notwendig die Umsetzung in C, ebenfalls auf dem Pico, weil dort die Entwicklung und das Debuggen so leichtfällt. Kapseln Sie dabei alle Pico-spezifischen Funktionen, ist die anschließende Portierung auf einen anderen Prozessor kein Hexenwerk mehr; im Idealfall genügen dann schon ein paar C-Makro-Definitionen. Dieser dritte Schritt kommt immer dann ins Spiel, wenn der Pico (auch von seinen physischen Maßen her) für den geplanten Einsatzzweck überdimensioniert ist.
Der vorliegende Artikel schließt unseren kleinen Workshop zur Pico-Programmierung ab. Aber der Pico hat natürlich noch mehr zu bieten, wie etwa sein PIO-Framework oder seine zwei Prozessoren. Diese Funktionen werden sicher bei dem ein oder anderen Projekt in der Zukunft eine Rolle spielen und dann im Zusammenhang mit dem Anwendungsfall hier ein Thema sein.
