|
Anzeige
|
Display init erst nach MCU Reset
Gast
#3899085
Guten Abend, glaube vor kurzen gab es hier schon einmal einen ähnlichen Thread. Ich habe folgendes Problem: Ich initialisiere ein Display bzw. flashe den MCU und muss dann jedes Mal den Controller resetten, um das Display korrekt zu initialisieren. Das ist nicht nur nervig, sondern sollte auch nicht Sinn der Sache sein. Mit längeren Warteroutinen vor der Displayinitialisierung habe ich bereits rumexperimentiert, leider ohne Erfolg. Danke im Voraus.
Gast
#3899091
... und mit diesen vagen Aussagen (kein Code, kein Schaltplan) meinst du eine vernünftige Aussage und einen Lösungshinweis auf dein Problem zu bekommen? Ein paar mehr Hinweise zu Controller und Display wären hier schon hilfreich. Tritt das Problem auch auf wenn du die Spannungsversorgung einschaltest (Programmer/Flashtool nich angeschlossen)? Falls ja sollten vermutlich die Delays NACH dem Display-Init kommen und nicht davor. Gruß Rainer Hallo Michael, da muss ich isidor recht geben. Was für ein µC benutzt du? Mit was programmierst du? Wie sieht dein Code aus?
Gast
#3899618
Es handelt sich um einen ATmega328 und das Display ist ein einfaches 16/2 Display (4 Bit Ansteuerung). Wenn ich die Spannungsversorung aus- und wieder einschalte wird das Display wie erwähnt erfolgreich initialisiert und alles funktioniert wunderbar, nur eben nicht direkt nach dem Flashvorgang. Michael schrieb: > Wenn ich die Spannungsversorung aus- und wieder einschalte wird das > Display wie erwähnt erfolgreich initialisiert und alles funktioniert > wunderbar, nur eben nicht direkt nach dem Flashvorgang. Es geistern leider viele unvollständige oder falsche LCD-Inits durchs Web. Wenn man das LCD aus beliebigem Zustand resetten will, ist eine vollständige Initialisierung Pflicht. Insbesondere das 3-malige Setzen in den 8Bit-Modus und das Warten nach jedem Schritt! Peter Dannegger schrieb: > Es geistern leider viele unvollständige oder falsche LCD-Inits durchs > Web. Die Lage verschlimmert sich noch dadurch, dass diese Inits oft funktionieren, nur leider nicht immer. Außerdem sollte man anmerken, dass Displays teilweise sehr empfindlich auf längere (> 10cm) Kabel reagieren. Der schlimmste Fall, der mir bisher begegnete, war ein Markenartikel von Conrad. Das Display wollte laute Datenblatt Anstiegszeiten von < 50ns im E-Signal und lief tatsächlich auch mit 80ns schon nicht mehr zuverlässig. Also ein HD44780-Kompatibles Display. An welchen Port-Pins hast du es denn angeschlossen, Schaltplan bitte? Wie Programmierst du deinen AVR, ISP oder anderweitig mit Bootloader? Ich halte mich immer daran und hatte bisher bei diversen Displays dieser Art noch keine Probleme: //1)Wait for more than 15ms after VDD rises to 4.5V //2)Write DB:0x30 RS:0 R/W:0 //3)Wait for more than 4,1ms //4)Write DB:0x30 RS:0 R/W:0 //5)Wait for more than 100µs //6)Write DB:0x30 RS:0 R/W:0 //7)Configure ... Christian K. schrieb: > //1)Wait for more than 15ms after VDD rises to 4.5V > //2)Write DB:0x30 RS:0 R/W:0 > //3)Wait for more than 4,1ms > //4)Write DB:0x30 RS:0 R/W:0 > //5)Wait for more than 100µs > //6)Write DB:0x30 RS:0 R/W:0 > //7)Configure ... Ja, genau so ist es falsch. Nach jedem Kommando muß mindestens 50µs gewartet werden. Erst nach dem Erreichen des 4Bit-Mode darf Busy abgefragt werden. //1)Wait for more than 15ms after VDD rises to 4.5V //2)Write DB:0x30 RS:0 R/W:0 //3)Wait for more than 4,1ms //4)Write DB:0x30 RS:0 R/W:0 //5)Wait for more than 100µs //6)Write DB:0x30 RS:0 R/W:0 //7)Wait for more than 100µs <- warte, bis 8Bit-Mode erreicht //8)Write DB:0x20 RS:0 R/W:0 <- 4bit Mode //9)Wait for more than 100µs <- warte, bis 4Bit-Mode erreicht //10)Configure ... <- erst ab hier ist Busy Abfrage möglich Peter Dannegger schrieb: > Ja, genau so ist es falsch. Na, dann kommt hier mal eine Seite aus dem Datenblatt von Displaytech, einer der bekannteren Hersteller (u.a. liefert Conrad diese Displays). Die Moral von der Geschichte: Das Datenblatt des aktuell verwendeten Bauteils ist meist wichtig.
Gast
#3900018
Hi >Na, dann kommt hier mal eine Seite aus dem Datenblatt von Displaytech, >einer der bekannteren Hersteller (u.a. liefert Conrad diese Displays). Im Datenblatt des KS0070B steht das anders. Und nur das ist wichtig, nicht die Sekundärliteratur des Displayherstellers. MfG Spess Wobei diese Aussage
meiner Meinung nach keine klare Aussage darüber macht, ob die Abarbeitung dieser 4 Bit Umschaltung bereits mit dem Busy Flag überwacht werden kann. Wenn die Umschaltung erst mal durch ist: kein Thema. Aber die Umschaltung selber? Im besten Fall würde ich die zweite Aussage
nämlich genau so interpretieren, dass mit 'following instruction' das erste Kommando nach der Umschaltung gemeint ist (Function Set). D.h. für das Umschaltkommando selbst steht das Busy Flag noch nicht zur Verfügung. Womit der Datenblattschreiber einen Fehler im DB hat, denn die Umschaltung wird ja nicht in 0 Zeit passieren. Georg G. schrieb: > Na, dann kommt hier mal eine Seite aus dem Datenblatt von Displaytech Ja, das Ablaufdiagramm im 44780 Datenblatt (S.46: Figure 24 4-Bit Interface) ist mißverständlich formuliert. Und daher wohl auch in vielen anderen. Bindend ist aber die Angabe der Ausführungszeit (siehe oben) in "S.24: Table 6 Instructions" (37µs). Daher kann unmöglich ein Befehl plötzlich nur 0µs dauern. Die fehlenden Wartezeiten zwischen 2 Befehlen müssen also hinzugefügt werden. Auch die Autoren von Datenblättern sind keine Götter. Manchmal muß man eben den gesunden Menschenverstand einsetzen. Wenn sich 2 Passagen in einem Datenblatt widersprechen, muß man die warscheinlichste selber ermitteln. http://www.adafruit.com/datasheets/HD44780.pdf
Angehängte Dateien:
Antwort schreiben |
Anzeige
|
