Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
elektronik_labor:tipps_fuer_die_fehlersuche [2019/08/10 15:25] tfischer |
elektronik_labor:tipps_fuer_die_fehlersuche [2023/09/19 23:30] (aktuell) mexleadmin |
||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== Tipps für die Fehlersuche | + | ====== |
===== Allgemein ===== | ===== Allgemein ===== | ||
Zeile 5: | Zeile 5: | ||
Um die Fehlerursachen zu finden, empfiehlt sich folgendes, generisches Vorgehen: | Um die Fehlerursachen zu finden, empfiehlt sich folgendes, generisches Vorgehen: | ||
- | --> 1. War die Teilfunktion schon jemals lauffähig?# | + | |
+ | --> 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. | Falls die Funktion an anderer Stelle bereits lauffähig war, dann Ja. | ||
- | --> Ja, Teilfunktion war schon lauffähig# | + | --> |
- | --> Teile# | + | Gehe zu 2. |
- | Breche das System (Hardware und Softwarekomponenten) und die Interaktionen (Schnittstellen, | + | <-- |
+ | |||
+ | --> | ||
+ | |||
+ | --> 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. | ||
<-- | <-- | ||
- | --> | + | --> |
Ersetze Systeme (Hardware und Softwarekomponenten) und die Interaktionen (Schnittstellen, | Ersetze Systeme (Hardware und Softwarekomponenten) und die Interaktionen (Schnittstellen, | ||
Zeile 24: | Zeile 82: | ||
- Nutze bereits getestete Komponenten. | - Nutze bereits getestete Komponenten. | ||
- Vereinfache die Interaktion | - 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(); | ||
| | ||
- | --> Nein, Teilfunktion war noch nie lauffähig# | + | while(1) |
- | Content | + | { |
+ | | ||
+ | if (something) | ||
+ | { | ||
+ | LCDprint(' | ||
+ | doThat(); | ||
+ | } | ||
+ | }; | ||
+ | }</ | ||
+ | | ||
+ | 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 52: | Zeile 203: | ||
* 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. | * 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. < | |
- | * Compiliert der Code? | + | * Gehe zu Menu: '' |
- | | + | * Füge F_CPU=8000000 (bzw. Passende Frequenz) ein |
- | * Sind bei den eingebundenen Bibliotheken die Randbedingungen der Zielhardware berücksichtigt? | + | * **Das Programm kompiliert nicht** **TWSR not found** : Falls Sie einen modernen AVR Chip nutzen |
- | * Wichtig ist, dass Sie zunächst | + | * **Beim Flashen der realen Hardware über '' |
- | * Wenn Sie zur Fehlersuche | + | * **Beim Flashen der realen Hardware erhalte ich " |
- | * 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, | + | * Steht bei Device Programming |
- | * Nutzen | + | * Hat das USB-Kabel/ |
- | * Prüfen | + | * ** Mein Chip hat keinen Speicherplatz mehr** bzw ** Ich erhalte ein ' |
- | * Falls Sie dann immer noch nichts finden: Schreiben Sie eine Frage an den Betreuer. Achten Sie dabei auf das richtige [[https://www.mikrocontroller.net/ | + | * **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 | ||
- | ====== Häufige Fehler ====== | + | === I2C === |
* **Auf den I2C Leitungen ändert sich nichts, obwohl der IC etwas ausgeben sollte: | * **Auf den I2C Leitungen ändert sich nichts, obwohl der IC etwas ausgeben sollte: | ||
- Überprüfen Sie die Pullup-Widerstände: | - Überprüfen Sie die Pullup-Widerstände: | ||
- Ist ein hochohmiger Widerstand $R_L$ entlang der Leitungen verbaut? Falls ja erzeugt dieser einen Spannungsteiler mit dem Pullup-Widerstand. Wenn $R_L$ groß ist, so liegt zwischen $R_L$ und Pull-up fast die Versorgungsspannung an. | - Ist ein hochohmiger Widerstand $R_L$ entlang der Leitungen verbaut? Falls ja erzeugt dieser einen Spannungsteiler mit dem Pullup-Widerstand. Wenn $R_L$ groß ist, so liegt zwischen $R_L$ und Pull-up fast die Versorgungsspannung an. | ||
+ | * **Der Master soll Daten vom Slave empfangen, aber hängt sich manchmal auf** Im " | ||
- | ====== 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:// | ||