Lubarsky’s Law of Cybernetic Entomology: There’s always one more bug
(Und wer zum Teufel ist Lubarsky?)
Kategorie: Debuggen
Alles übers Debuggen
Logisch!
Wenn Dinge schiefgehen, obwohl die Programmlogik korrekt zu sein scheint, ist es an der Zeit, die Signale zu untersuchen, die in die MCU reingehen und aus der MCU herauskommen. Das beste Werkzeug dafür ist ein Logikanalysator.
Weiter lesenTesting is not responsible for the bugs inserted into software any more than the sun is responsible for creating dust in the air.
(Dorothy Graham)
Während ich jetzt viel über Bugs und Debuggen geschrieben habe, habe ich ich bisher nichts dazu geschrieben, wann man denn mit dem Debuggen beginnen sollte und warum Testen eine mindestens so wichtige Aufgabe wie das Debuggen ist.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Diese Zitat vom Vater der Programmiersprache C trifft den Nagel auf den Kopf und sollte speziell dann beachtet werden, wenn man mal wieder dabei ist, eine komplexe Implementation zu kreieren: Mach’s so einfach wie möglich!
Premature optimization is the root of all evil
Dieses Zitat, das Knuth, Hoare oder Disjkstra zugeschrieben wird und das erstmals in einem Aufsatz von Knuth 1974 erschien, gilt nicht nur für Code-Optimierungen, wie ich auf die harte Tour gelernt habe. Es gilt auch für funktionale Optimierungen, wenn man es mit einem Kommunikationsprotokoll wie debugWIRE zu tun hat, für das es keine offizielle Spezifikation gibt. Zu viele tolle neue Features einbauen bevor das Grundgerüst funktioniert ist eine bescheuerte Idee.
Debuggen(4): Einen Debug-Stub benutzen
Das Titelbild ist von Hebi B. auf Pixabay
Dieser Blogbeitrag zeigt, wie man in 7 einfachen Schritten zu einer funktionierenden Debugging-Lösung mit einem gdb-Stub für einige 8-Bit-AVR-MCUs gelangt. Die einzige zusätzliche Hardware, die man benötigt, ist ein ISP-Programmiergerät, um einen neuen Bootloader zu brennen (wenn man mit einem sehr langsam laufenden Programm zufrieden ist, braucht man nicht einmal das).
Debuggen(3): Debuggen ist, als ob man ein Detektiv in einem Krimi ist, in dem man auch der Mörder ist
Titelbild: OpenClipart-Vectors auf Pixabay.
Man muss dem Titel (zitiert aus einem Tweet von Filipe Fortes) hinzufügen, dass der Detektiv an einem Gedächtnisverlust leidet. Andernfalls könnte der Fall leicht gelöst werden. Ähnlich beim Debugging: Wenn ich nur wüsste, welche fiesen Dinge ich im Quellcode versteckt habe, könnte ich sie einfach entfernen – aber ich weiß es einfach nicht. In diesem Blogbeitrag werden wir einen Blick darauf werfen, welche Art von Werkzeugen man verwenden kann, um die im Keller versteckten Leichen zu finden (speziell für eingebettete Systeme).
Debuggen(2): Es ist die Hardware, Dummkopf!
Wenn etwas schiefgeht, ist es nicht immer die Schuld des Programmierers. Es könnte auch an der Hardware liegen (bzw. dem Elektroingenieur, der diese entworfen hat). Wenn man ein System als Bastler entwickelt, ist man aber meist beides: Der Elektroingenieur und der Programmierer (sodass man sich immer selbst die Schuld geben darf). In diesem Blogbeitrag werfen wir einen Blick auf einige der Dinge, die auf der Hardware-Seite schiefgehen können, speziell bei Projekten mit AVR-MCUs.
Debuggen(1): Was für ein Bug ist das?
Titelbild: Mit freundlicher Genehmigung des Naval Surface Warfare Center, Dahlgren, VA., 1988. – U.S. Naval Historical Center Online Library Foto NH 96566-KN
Wenn man darüber nachdenkt, wann man das letzte Mal ein System entworfen hat, das von Anfang an funktionierte und keine Korrekturen benötigte, wird man vermutlich feststellen, dass das schon ziemlich lange her ist. Tatsächlich verbringt man normalerweise sehr viel Zeit damit, Fehler zu identifizieren und zu korrigieren, die umgangssprachlich als Bugs bezeichnet werden. In diesem Blogbeitrag gebe ich einen Überblick über verschiedene Formen von Bugs und gehe darauf ein, wie man sie loswerden kann.
Es tut mir leid, Dave. Ich fürchte, das kann ich nicht.
Das Titelbild wurde erstellt von Cryteria, CC BY 3.0, Link
Gdb, der GNU-Debugger, ist wahrscheinlich der am häufigsten verwendete Open-Source-Debugger für eingebettete Systeme. Die AVR-Version von GDB auf dem Mac ist leider nicht sehr kooperativ. Wenn man versucht, eine ELF-Datei zu lesen, erhält man die folgende lustige Mitteilung (die an HAL9000 erinnert):
I’m sorry, Dave, I can’t do that. Symbol format `elf32-avr’ unknown.
Aber mit der richtigen Homebrew-Formel kann man avr-gdb einige neue Tricks beibringen …
EDIT: Das Problem wurde von den homebrew-Entwicklern gelöst.