Display init erst nach MCU Reset

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?

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.

Wobei diese Aussage

1

RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0

2

 0  0   0   0   1   1   *   *   *   *

3

4

           BF cannot be checked before this instruction.

5

6

           BF can be checked after following instruction.

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

1

           BF can be checked after following instruction.

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