F:Timing für LCDs mit HD44780

Hallo,

ich versuche gerade einige LCDs mit dem HD44780 Controller anzusteuern und mir dafür meine C Routinen für meinen AVR (Atmega 8 mit 4MHz Clock) selbst zu schreiben. Ja, ja ich weiß es gibt im Web unendlich viele Routinen zu Download. Aber erstens ist mein Interface etwas anders und zweitens möchte ichs halt einfach selber machen...

Nun, ich habe den Eindruck daß der Controller zumindest bei der Initialisierung sehr große Wartezeiten braucht um alles richtig zu übernehmen. Das zeigt sich auch im Programmcode anderer, die viel mit Warteschleifen und Wiederholungen von Kommandos arbeiten. Laut den Timingangaben in den Datenblättern sollte das aber IMHO nicht so kritisch sein und immer irgendwo

Reply to
Michael Amann
Loading thread data ...

...

....

Michael,

nach meinen Erfahrungen schwanken die tatsächlichen Zeiten zwischen verschiedenen Modellen. Was du an Quellen gefunden hast, sind Programme die das Busy-Bit nicht auslesen und daher worst-case Annahmen machen müssen.

Spendier deiner Schaltung eine weitere Datenleitung für R/W, lese das Busy-Bit und du wirst keine Probleme mit dem Timing haben.

Siehe auch:

formatting link

Andreas

--
Andreas Tönne @ home
mailto:atoenne@t-online.de * http://www.atoenne.de
 Click to see the full signature
Reply to
Andreas Tönne

Hallo Andreas,

danke für die schnelle Antwort. Ich versuche das Busy Flag auszulesen, komme aber irgendwie trotzdem nicht so recht um längere Delays beim Setzen von Enable herum. Die Progrämmchen, die ich gesehen habe, lesen alle das Busy Flag aus und verwenden for-Schleifen und Kommandowiederholungen. Selbst die bei Codevision mitgelieferte LCD-Library verwendet neben dem Busy-Flag noch "künstliche" Delays.Von meinem Verständnis sollten die Zeiten für Enable, Enable-hold, Data-hold u.s.w. bei einem AVR mit 4MHz nicht sonderlich kritisch sein. Ich schau mal auf Deinen Link....

Danke und Gruß Michael

Reply to
Michael Amann

Es ist in der Regel kein Problem, LCD-Displays ohne Lesezugriff zu betreiben.

Ich habe gerade mal ein Datenblatt für ein 16-Chracter-Display herausgesucht. Die meisten Kommandos benötigen da 40us, Clear-Display und Display-cursor-home ca. 1,6 ms. Mit ein wenig Sicherheit sollte es ausreichen, zwischen zwei "normalen" Kommandos 100us zu warten.

Gruß

Stefan

Reply to
Stefan Bröring

Hallo Stefan,

ja das würde ich so beim Ansehen des Datenblattes eigentlich auch vermuten. Die Methode mit dem Busy-Flag liegt mir persönlich aber näher. Aber das ist eine programmier-ethische Sache ;-)

Mal sehen, was ich auf der Seite von Andreas finden kann....

Gruß Michael

Reply to
Michael Amann

Hallo Michael.

Das waere auch mein Tipp gewesen. Ich arbeite auch mit diesen Displays. Seitdem ich das Busyflag abfrage, kann ich wesentlich schneller auf dem Display schreiben. Waehrend ich ohne Busy-Flag solange Wartezeiten hatte, dass ich beim Beschreiben des Display zuschauen konnte, kann ich jetzt kaum noch eine Zeitverzoegerung zwischen dem ersten und letzten Zeichen auf dem Display wahrnehmen. (2*20)

Ein Ausschnitt, wie ich das Busy-Flag abfrage: regselect = RS readwrite = R/W enable = E

unsigned char displayBusy (void) /* */ { /* */ unsigned char addresscounter; /* received byte from display */ displaydata = 0xFF; /* prepare port to read */ regselect = setfunction; /* set display parameter */ readwrite = readfromdisplay; /* set display parameter */ enable = 0x01; /* validate bus data */ addresscounter = displaydata; /* save bus data */ enable = 0x00; /* disable bus data validation*/ return addresscounter >> 7; /* check msb (busy flag) */ } /* */

Im Programm steht dann eine Schleife: while (displayBusy());

Gruß Karsten

Reply to
Karsten Busenbender

Hi,

ganz wichtig ist, dass die Pullups an den Leitungen nicht zu hochohmig sind. Mit 10k habe ich schon schlechte Erfahrungen gemacht, mit 1k gehts sicher.

Michael

Reply to
Michael Rübig

Hallo,

ja genau das ist der Grund weshalb ich das auch mit Busy machen möchte. Außerdem erscheint mir das einfach als sauberer programmiert und unabhängiger vom µC und seiner Geschwindigkeit. Ich lese mir mal Deinen Code durch und vergleiche ihn mit dem was ich da so habe.

Gruß und danke Michael

Reply to
Michael Amann

Hallo Michael,

Pull-ups? Mein AVR hat an dem Port eine Push-Pull Stufe und keinen open drain oder so etwas. Und so wie ich das Hitachi DB verstehe, hat der Datenport des Controllers im Falle eines Ausgangs auch interne Pull-ups. Oder täusche ich mich da?

Gruß Michael

Michael Rübig schrieb:

Reply to
Michael Amann

Michael Amann schrieb:

In der avr-libc-Doku habe ich mittlerweile auch ein Beispiel drin, in dem HD44780-Clones angesteuert werden (das stdiodemo). Timed delays werden nur in der Initialisierung benutzt und dann exakt so, wie im HD44780-Datenblatt genannt. Alles andere pollt busy. Alle mir bislang untergekommenen LCDs tun damit.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
 Click to see the full signature
Reply to
Joerg Wunsch

Hi,

An irgendeinem der 3 Steuerleitungen aber nicht. Wie ich später herausgefunden habe, sind die Steuerleitungen kritisch bezüglich Pullup.

Wenn Du Push-Pull Stufen verwendest, ists aber ideal.

Michael

Reply to
Michael Rübig

dann werden auch die anderen Leitungen sicherlich so gesetzt werden... Ich hatte in einem 80C537-System ebenfalls ein HD44780-Display mit Busy-Auswertung eingesetzt - absolut ohne Probleme. Selbst als Floureszenz-Anzeige. Lediglich der Linearregler war dann am Kochen ;)

Wie lang sind die Impulse, die zur Ansteuerung gebraucht/erzeugt werden? Passt das Timing? Was sagt das HD-Datenblatt dazu? Und was das Assembler-File?

Heinz

PS: Taktfrequenz war 16MHz

Reply to
Heinz Liebhart

Wie lange die genau sind, kann ich nicht sagen. Ich habe da keine Anhaltswerte. Mir reicht, dass das Beispiel einwandfrei funktioniert. Man muss allerdings darauf achten, dass man bei hohen Taktraten darauf achtet, dass die Ausgaenge am Mikrocontroller auch gesetzt sind. Das Display ist bislang immer mitgekommen.

Taktrate bei mir ist 11,0952 MHz, aber das muss man ja noch durch 12 teilen. Und dann muesste man sich anschauen, wie viele Maschinenbefehle daraus werden. (89C51 brauchen 12 Taktzyklen/Maschinenbefehl)

Also durch 12 nur geringfuegig schneller als bei mir. Wenn was nicht funktioniert, dann dauert das Umschalten der Register zulange und man muss einfach mal ein NOP einfuegen.

Gruss, Karsten

Reply to
Karsten Busenbender

Mit 22 MHz Quarz hat es auch noch funktioniert. :-)

Gruss, Karsten

Reply to
Karsten Busenbender

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.