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 [2020/10/01 17:29] – [Häufige Fehler] 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 205: | Zeile 205: | ||
===== Häufige Fehler ===== | ===== Häufige Fehler ===== | ||
* **F_CPU not defined for** (z.B. < | * **F_CPU not defined for** (z.B. < | ||
- | * Gehe zu Menu: Projekt > (ProjektName) Eigenschaften > Toolchain > AVR/GNU C Compiler > Symbols | + | * Gehe zu Menu: '' |
* Füge F_CPU=8000000 (bzw. Passende Frequenz) ein | * 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 '' | * **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 '' | ||
Zeile 213: | Zeile 213: | ||
* Hat das USB-Kabel/ | * Hat das USB-Kabel/ | ||
* ** Mein Chip hat keinen Speicherplatz mehr** bzw ** Ich erhalte ein ' | * ** 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 === | ||
* **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:// | ||