Forum: Mikrocontroller und Digitale Elektronik Display init erst nach MCU Reset


von Michael (Gast)


Lesenswert?

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.

von isidor (Gast)


Lesenswert?

... und mit diesen vagen Aussagen (kein Code, kein Schaltplan)
meinst du eine vernünftige Aussage und einen Lösungshinweis
auf dein Problem zu bekommen?

von Rainer M. (excogitator)


Lesenswert?

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

von Alex R. (itaxel)


Lesenswert?

Hallo Michael,

da muss ich isidor recht geben.
Was für ein µC benutzt du?
Mit was programmierst du?
Wie sieht dein Code aus?

von Michael (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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!

von Georg G. (df2au)


Lesenswert?

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.

von Christian K. (the_kirsch)


Lesenswert?

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 ...

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

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

von Georg G. (df2au)


Angehängte Dateien:

Lesenswert?

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.

von spess53 (Gast)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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.

: Bearbeitet durch User
von Peter D. (peda)


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.