Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
elektronik_labor:tipps_fuer_die_fehlersuche [2019/05/02 03:10] tfischer - Imported by DokuWiki Advanced Plugin |
elektronik_labor:tipps_fuer_die_fehlersuche [2023/09/19 23:30] (aktuell) mexleadmin |
||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== Tipps für die Fehlersuche (= Debugging) ====== | + | ====== |
+ | |||
+ | ===== Allgemein ===== | ||
+ | |||
+ | Um die Fehlerursachen zu finden, empfiehlt sich folgendes, generisches Vorgehen: | ||
+ | |||
+ | |||
+ | --> 1. Verstehen# | ||
+ | |||
+ | 1.1 Definieren des “Gut-Falls”: | ||
+ | |||
+ | 1.2 Versuchen Sie genau zu verstehen, unter welchen Umständen der fehlerhafte Zustand auftritt. \\ Wie ist dieser zu reproduzieren? | ||
+ | * Welche Eingaben, Spannungen waren vorhanden? | ||
+ | * Gleicher Fehler bei geänderten Eingaben? | ||
+ | * Prüfen Sie auch vermeintlich klare Dinge | ||
+ | |||
+ | Beim Verständnisaufbau hilft manchmal weniger Theorie und mehr ausprobieren. | ||
+ | |||
+ | **Wichtig**: | ||
+ | |||
+ | Und: Ein Fehler der auf mysteriöse Weise wieder verschwindet, | ||
+ | |||
+ | --> 1.3 War die Teilfunktion schon jemals lauffähig?# | ||
+ | Falls die Funktion an anderer Stelle bereits lauffähig war, dann Ja. | ||
+ | --> 1.3.1 Ja, Teilfunktion war schon lauffähig# | ||
+ | Gehe zu 2. | ||
+ | <-- | ||
+ | |||
+ | --> 1.3.2 Nein, Teilfunktion war noch nie lauffähig# | ||
+ | |||
+ | --> 1.3.2.1 Suchen# | ||
+ | |||
+ | Gab es weltweit noch keinen, der diese Teilfunktion implementiert hat? Um das zu beantworten hilft ein Blick in Google. | ||
+ | |||
+ | Lernen Sie [[: | ||
+ | |||
+ | Falls es jemanden gab, so war die Funktion an anderer Stelle bereits lauffähig --> Gehe zu 2. . | ||
+ | |||
+ | |||
+ | <-- | ||
+ | |||
+ | --> 1.3.2.2 Reduzieren# | ||
+ | |||
+ | Ähnlich Punkt 2. und 3. ist es zielführend Das System soweit zu vereinfachen, | ||
+ | |||
+ | D.h. im Extremfall das Flashen mit einer leeren main Funktion (Geht das Flashen?) oder mit einer, welche nur einen PIN / LED aktiviert. | ||
+ | |||
+ | <-- | ||
+ | |||
+ | --> 1.3.2.3 Kreativ sein# | ||
+ | |||
+ | Falls die Teilfunktion noch nirgends implementiert wurde (wirklich? | ||
+ | |||
+ | <-- | ||
+ | |||
+ | <-- | ||
+ | |||
+ | <-- | ||
+ | |||
+ | |||
+ | <-- | ||
+ | |||
+ | --> 2. Vermuten# | ||
+ | Erstelle eine Hypothese an was der Fehler liegen kann. Dann ist das (fehlerhafte) System leichter über "Teile und Herrsche" | ||
+ | <-- | ||
+ | |||
+ | --> 3. Aufteilen# | ||
+ | Breche das System (Hardware und Softwarekomponenten) und die Interaktionen (Schnittstellen, | ||
+ | |||
+ | Falls es schon einen Teil des Programms gab, so sollte dieser wieder hergestellt werden. Die Änderungen sollten dann im folgenden Schritt Zeile für Zeile (bzw. Funktionsblock für Funktionsblock) eingefügt und auf der Hardware auf getestet werden. | ||
+ | <-- | ||
+ | |||
+ | --> 4. Ersetzen# | ||
+ | Ersetze Systeme (Hardware und Softwarekomponenten) und die Interaktionen (Schnittstellen, | ||
+ | |||
+ | - Vereinfache die Software | ||
+ | - Kompiliert der Beispiel-Code aus der Vorlesung? \\ Kompiliert das gewünschte C-File, wenn alles (includes, variablen, functions), außer main() ausgeblendet wird? | ||
+ | - Kompiliert eine **einfache Software**, welche eine (wechselnde) Ausgabe beinhaltet (z.B. LED, Port)? \\ Besser einfach beginnen, also nicht mit einem über SPI angeschlossendem Display. | ||
+ | - Vereinfache die Hardware | ||
+ | - Nutze Oszilloskop und Logic Analyzer statt ausgebende Komponenten. | ||
+ | - Nutze Funktionsgenerator statt eingebende Komponenten. | ||
+ | - Nutze bereits getestete Komponenten. | ||
+ | - Vereinfache die Interaktion | ||
+ | |||
+ | |||
+ | <-- | ||
+ | |||
+ | --> 5. Beobachten und zurück zu Start# | ||
+ | Tritt der Fehler exakt gleich auf? \\ | ||
+ | Welche neuen Hypothesen lassen sich aufstellen? \\ \\ | ||
+ | |||
+ | |||
+ | Häufig ist es von Vorteil eine Ausgabemöglichkeit zu schaffen.Zur Ausgabe bietet sich z.B. ein unbenutzter PIN oder - falls schon vorhanden und in Software ansprechbar - ein Display an. | ||
+ | - Die Ausgabemöglichkeit kann als genutzt werden, um den Programmablauf zu überprüfen. z.B. kann die Ausgabe eines Buchstabens auf dem Display als Zeile eingefügt und so das Erreichen dieser Zeile überprüft werden. ++Beispiel|< | ||
+ | void main() | ||
+ | { | ||
+ | initLCD(); | ||
+ | initADC(); | ||
+ | |||
+ | while(1) | ||
+ | { | ||
+ | | ||
+ | if (something) | ||
+ | { | ||
+ | LCDprint(' | ||
+ | doThat(); | ||
+ | } | ||
+ | }; | ||
+ | }</ | ||
+ | - Ähnliches geht auch beim Sprung in ein Unterprogramm. Wird dieses aber mehrmals in der Hauptschleife aufgerufen, kann es sich anbieten eine Hilfsvariable einzufügen. Damit ist es möglich nur den Sprung beim vermuteten Fehlverhalten zu betrachten: ++Beispiel|< | ||
+ | void main() | ||
+ | { | ||
+ | int dummy=0; | ||
+ | ... | ||
+ | while(1) | ||
+ | { | ||
+ | | ||
+ | if (something) | ||
+ | { | ||
+ | dummy=1; | ||
+ | doThis(); | ||
+ | dummy=0; | ||
+ | } | ||
+ | }; | ||
+ | } | ||
+ | |||
+ | void doThis() | ||
+ | { | ||
+ | ... | ||
+ | | ||
+ | | ||
+ | ... | ||
+ | } | ||
+ | </ | ||
+ | - Falls sich das Unterprogramm in einer weiteren Datei (z.B. eingebundene Library) befindet, so muss die Hilfsvariable übergeben werden. Temporär ist dafür die Definition/ | ||
+ | #include ADC.h | ||
+ | |||
+ | int dummy=0; | ||
+ | void main() | ||
+ | { | ||
+ | ... | ||
+ | while(1) | ||
+ | { | ||
+ | | ||
+ | ... | ||
+ | if (something) | ||
+ | { | ||
+ | dummy=1; | ||
+ | setADCgain(); | ||
+ | dummy=0; | ||
+ | } | ||
+ | }; | ||
+ | } | ||
+ | |||
+ | </ | ||
+ | extern int dummy; | ||
+ | </ | ||
+ | void setADCgain() | ||
+ | { | ||
+ | ... | ||
+ | | ||
+ | | ||
+ | ... | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | <-- | ||
+ | |||
+ | --> 6. Bugfixen# | ||
+ | Sobald der Bug eingekreist wurde, geht es ans korrigieren. Hier hilft meist die Theorie weiter. | ||
+ | |||
+ | **Wichtig: | ||
+ | |||
+ | <-- | ||
+ | |||
+ | ===== Software ===== | ||
+ | |||
+ | * Compiliert der Code? | ||
+ | * Ist die richtige Zielhardware (z.B. ATmega328PB) gewählt? | ||
+ | * Sind bei den eingebundenen Bibliotheken die Randbedingungen der Zielhardware berücksichtigt? | ||
+ | * Wichtig ist, dass Sie zunächst eine Ausgabemöglichkeit schaffen. Die kann ein digitaler (oder analoger) Output Pin oder eine LCD-Anzeige sein. Ohne diese ist eine strukturierte Fehlersuche schwer möglich. Versuchen Sie die Ausgabemöglichkeit als erstes zu programmieren und zu testen. | ||
+ | * Wenn Sie zur Fehlersuche Ihr Programm ändern, machen Sie eine Sicherungskopie des Programms. Weiterhin sollten Sie die zur Fehlersuche geänderten Zeilen markieren (z.B. mit dem Kommentar DEBUGGING!) | ||
+ | * Falls das Programm nicht die von Ihnen gewünschte Ergebnisse liefert, dann versuchen Sie zunächst möglichst weiträumig Code auszukommentieren. Falls dann das Programm noch einen sinnvollen Ablauf zeigt, kann Schritt für Schritt die Auskommentierung aufgehoben werden. | ||
+ | * Nutzen Sie die Möglichkeit nach Zwischenschritten eine Wertänderung auszugeben (z.B. Ausgabe am LCD). Damit kann ermittelt werden ab welcher Zeile der tatsächliche Ablauf vom gewünschten abweicht. | ||
+ | * Prüfen Sie mit Hilfe der [[https:// | ||
+ | * Versuchen Sie den Code so umzuschreiben, | ||
+ | * Falls Sie dann immer noch nichts finden: Schreiben Sie eine Frage an den Betreuer. Achten Sie dabei auf das richtige [[https:// | ||
===== Hardware ===== | ===== Hardware ===== | ||
Zeile 6: | Zeile 192: | ||
* Ist die Stromversorgung an und richtig eingestellt? | * Ist die Stromversorgung an und richtig eingestellt? | ||
* Falls die Spannung zusammenbricht oder das " | * Falls die Spannung zusammenbricht oder das " | ||
- | * Sind Messgeräte und Stromversorgung an und richtig eingestellt (z.B. Abschlusswiderstand) | + | * Sind Messgeräte und Stromversorgung an und richtig eingestellt (z.B. Abschlusswiderstand)? |
* Passt die Verkabelung? | * Passt die Verkabelung? | ||
* Sind die passenden Widerstände an der richtigen Position? Und sind die Dioden in richtiger Richtung bestückt? | * Sind die passenden Widerstände an der richtigen Position? Und sind die Dioden in richtiger Richtung bestückt? | ||
* Können Spannungen als Zwischenwerte gemessen werden? | * Können Spannungen als Zwischenwerte gemessen werden? | ||
* Sind die Pins richtig angeschlossen? | * Sind die Pins richtig angeschlossen? | ||
- | * Fall Sie einen Fehler in der Kommunikation vermuten: verbinden Sie RX mit TX und überprüfen Sie, ob am gleichen Bauteil das korrekte Signal ankommt. | + | * Funktioniert das Flashen über das Proggi? Falls nicht: |
+ | * Ist der korrekte USB-Anschluss gewählt? | ||
+ | * Ist der Fehler auch mit einem anderen Proggi + anderen Kabeln vorhanden? | ||
+ | * Ist in der Schaltung die SPI-Schnittstelle in Verwendung? Sind weitere Bauteile zwischen Programmierbuchse und Controllerpin, | ||
+ | * Falls Sie einen Fehler in der Kommunikation vermuten: verbinden Sie RX mit TX und überprüfen Sie, ob am gleichen Bauteil das korrekte Signal ankommt. | ||
- | ===== Software | + | ===== Häufige Fehler |
+ | * **F_CPU not defined for** (z.B. < | ||
+ | * Gehe zu Menu: '' | ||
+ | * Füge F_CPU=8000000 (bzw. Passende Frequenz) ein | ||
+ | * **Das Programm kompiliert nicht** **TWSR not found** : Falls Sie einen modernen AVR Chip nutzen (z.B. 328PB) so kann dieser mehrere SPI und I2C Schnittstellen haben. Damit haben sich bei diesem Target auch die Register- und Interruptvektornamen geändert. Statt TWSR ist dann TWSR0 oder TSWR1 zu verwenden - je nach gewünschtem Pin. Dies ist am einfachsten über defines der fehlerhaften Namen, also '' | ||
+ | * **Beim Flashen der realen Hardware über '' | ||
+ | * **Beim Flashen der realen Hardware erhalte ich " | ||
+ | * Steht bei Device Programming das Interface auf ISP? Falls nicht kann dies die Ursache sein. Das Programming geschieht immer mittels ISP. | ||
+ | * Hat das USB-Kabel/ | ||
+ | * ** Mein Chip hat keinen Speicherplatz mehr** bzw ** Ich erhalte ein ' | ||
+ | * **Mein Programm scheint irgendwo nicht weiter zu kommen**. Dies kann verschiedene Gründe haben: | ||
+ | * Endlosschleife | ||
+ | * Speicherüberlauf im RAM: sobald die Speicherauslastung des RAM über ca 75% steigt, sind Probleme wie spontane Resets bei Bearbeiten von Pointern, Arrays, Strings oder Structs wahrscheinlich. Die kann über Debugging herausgefunden werden (entweder mit Steppen mit Debugger oder Ausgabe von Werten nach jeder Zeile). | ||
- | | + | === I2C === |
- | * Wenn Sie zur Fehlersuche Ihr Programm ändern, machen Sie eine Sicherungskopie des Programms. Weiterhin sollten Sie die zur Fehlersuche geänderten Zeilen markieren (z.B. mit dem Kommentar DEBUGGING!) | + | |
- | * Falls das Programm nicht die von Ihnen gewünschte Ergebnisse liefert, dann versuchen Sie zunächst möglichst weiträumig Code auszukommentieren. Falls dann das Programm noch einen sinnvollen Ablauf zeigt, kann Schritt für Schritt | + | - Überprüfen |
- | * Nutzen Sie die Möglichkeit nach Zwischenschritten eine Wertänderung auszugeben (z.B. Ausgabe am LCD). Damit kann ermittelt werden ab welcher Zeile der tatsächliche Ablauf | + | - Ist ein hochohmiger Widerstand $R_L$ entlang der Leitungen verbaut? Falls ja erzeugt dieser einen Spannungsteiler |
- | | + | * **Der Master soll Daten vom Slave empfangen, aber hängt sich manchmal auf** Im " |
- | * Falls Sie dann immer noch nichts finden: Schreiben Sie eine Frage an den Betreuer. Achten Sie dabei auf das richtige [[https:// | + | |
- | ====== Tipps für die Fehlerkorrektur (Bugfixing) | + | ===== Tipps für die Fehlerkorrektur (Bugfixing) ===== |
* Bei größeren (Serien)Projekten steht einer einfachen Elektronik-Fehlerkorrektur häufig die komplexe Validierung und Tests der Hardware im Weg. Entsprechend kann es sich anbieten die Fehler über ein Mod-Board - also einem kleinen Zusatzboard - zu korrigieren. Dafür bietet sich beispielsweise ein kompakter Chip, wie der [[https:// | * Bei größeren (Serien)Projekten steht einer einfachen Elektronik-Fehlerkorrektur häufig die komplexe Validierung und Tests der Hardware im Weg. Entsprechend kann es sich anbieten die Fehler über ein Mod-Board - also einem kleinen Zusatzboard - zu korrigieren. Dafür bietet sich beispielsweise ein kompakter Chip, wie der [[https:// | ||