Hallo, ich habe eine grundsätzliche Frage: Was ist der Unterschied ob ich ein Programm durch Einschalten der Spannung oder durch Programmierung des Flash starte? Vorausgesetzt natürlich, ich sorge durch eine längere Wartezeit am Anfang des Programms dafür, daß die Spannung stabil ist. Welche Gründe kann es dann noch geben, daß sich eine angeschlossene Hardware anders verhält?
Bruno M. schrieb: > Hallo, > ich habe eine grundsätzliche Frage: > Was ist der Unterschied ob ich ein Programm durch Einschalten der > Spannung oder durch Programmierung des Flash starte? Keiner. Ausser die Bits im Statusregister welche die Resetquelle anzeigen. Sonst löst sowohl ein POR als auch ein Externer Reset den gleichen Resetvorgang aus. > Vorausgesetzt natürlich, ich sorge durch eine längere Wartezeit am > Anfang des Programms dafür, daß die Spannung stabil ist. > Welche Gründe kann es dann noch geben, daß sich eine angeschlossene > Hardware anders verhält? Der größte Unterschied wird der angeschlossene Programmer machen. Fehlende Masseverbindungen sind hier der heiße Kandidat.
Bruno M. schrieb: > Welche Gründe kann es dann noch geben, daß sich eine angeschlossene > Hardware anders verhält? Floatende Pins, falsche Initreihenfolge (SPI).
Ganz konkret geht es um ein angeschlossenes LCD. Die Problemschilderung findet sich hier: Beitrag "avr asm LCD Problem"
Gast
#6677820
Ein Bootloader bzw. die dazu gehörigen Fuses spielen eine Rolle. Wenn die Fuses falsch gesetzt sind, können ganz lustige Effekte auftreten. Wenn der µC beim Reset z.B. an Adresse 0 startet aber da nichts ist, dann wird der leere Flash (der lauter 0xFF enthält) schnell durchlaufen bis irgendwann der Bootloader erreicht wurde. Das heißt, du bemerkst den Fehler erstmal nicht. Wenn du dann ein Programm in den Flash überträgt, läuft das zwar, aber der Bootloader wird von da an nicht mehr ausgeführt.
Bruno M. schrieb: > Ganz konkret geht es um ein angeschlossenes LCD. Wir sind ja hier nicht bei Hellsehers. Diese Dinger haben doch eine genaue Bezeichnung. Es liegt ziemlich sicher ein Fehler im Quelltext vor.
Gast
#6677827
Bitte diesen Thread hier schließen. Zwei Diskussionen zu einem Thema wo dann auch noch hin und her quer verwiesen wird sind Kacke.
Bruno M. schrieb: > Ganz konkret geht es um ein angeschlossenes LCD. Die Problemschilderung > findet sich hier: Dann ist es sicher ein typisches Problem mit Initialisierung. Du gehst wohl immer davon aus das Display wäre gerade neu gestartet. Bei einem externen Reset (z.B. durch den Programmer) hat sich nur der Controller, nicht aber das Display zurückgesetzt. Folglich funktioniert die Initialisierung nicht wie gedacht?
Verwendet er das Display im 4-Bit-Modus und hat Probleme damit? Wenn ja wird der Controller durch das Programmieren zurückgesetzt, das Display aber nicht. Das bleibt weiter im 4-Bit-Modus und hängt evtl. noch in einer halben Übertragung. In so einer Situation schaltet man das Display beim Controller-Reset zuerst in den 8-Bit-Modus, sendet das Kommando am besten dreimal falls der Display-Controller noch in einer nicht abgeschlossenen Übertragung hängt, schaltet dann zurück in den 4-Bit-Modus und löscht das Display einmal. Dann hat man es in einem definierten Zustand wie nach dem Einschalten.
Gast
#6677974
Ben B. schrieb: > Wenn ja wird der Controller durch das Programmieren zurückgesetzt, > das Display aber nicht. Das bleibt weiter im 4-Bit-Modus und hängt > evtl. noch in einer halben Übertragung. Die Initialisierungssequenz im Datenblatt des Controllers ab Seite 46 berücksichtigt diesen Fall https://www.sparkfun.com/datasheets/LCD/HD44780.pdf
Gast
#6678030
Hi >Die Initialisierungssequenz im Datenblatt des Controllers ab Seite 46 >berücksichtigt diesen Fall Der TO verwendet kein HD44780-Display, sondern ein Grafik-Display. Welcher Controller verwendet ist ein Geheimnis. MfG spess