LC Display schaltet nicht ein

gamy schrieb:
> und angeschlossen

Woran?

Und wie?

gamy schrieb:
> an Vo habe ich ein Poti mit 20 K OHM und baut ein Spannungsteiler mit
> jeweils 10k also 2,5 V ,ich habe den Poti langsamm gedreht aber das
> ändert gar nix

Zwischenfrage: denkst und lötest du auch so schlampig, wie du schreibst? 
Da tut einem ja vom bloßen Lesen der Kopf weh!

Und was das Kontrastpoti angeht: das muß mit dem einen Ende an GND. Die 
Position für besten Kontrast ist auch meist nahe an diesem Ende. 
Schleifer direkt an Vo. Kann durchaus sein, daß du durch die 2 10K 
Widerstände keinen ausreichenden Einstellbereich hast. Im Zweifel halte 
dich an die Schaltung aus dem Datenblatt.

Das ist alles recht schwammig. Aber wenn dein Display Speisespannung 
erhält und der Kontrastregler richtig steht, sollte die erste Zeile aus 
Blöcken bestehen, die gut sichtbar sind. Die verschwinden erst, wenn das 
Display initialisiert wird.

Hatte ähnliches Problem.
Die Pinne für Enable, R/Wquer, RS sollten auf GND beschaltet werden, 
bevor irgendeine Betriebsspannung angelegt wird. Ebenso zwingend 
notwendig, vor  dem Test Poti an V0 für Kontrastspannung.
Ich dachte auch, das Ding ist kaputt. Es knatterte im UKW-Radio. Aha,
die Ausgänge koppeln auf die superempfindlichen MOS-Eingänge. Es kommt 
zu HF-Schwingungen. Ich hatte dann nochmals die Betriebsspannug falsch 
herum angeschlossen. Das Ding wurde heiß.
Das war der erste Test - ohne MCU...
Dann richtig verdrahten - mit MCU verbinden.
Trotzdem lief es hinterher- richtig gepolt - einwandfrei. Kann also 
einiges ab. Der Power on self reset verlangt eine Betriebsspannung, die 
nicht zu träge hochfährt. Also dicke Elkos und Widerstände in der 
Versorgungsspannung sind Gift. Dann sieht man trotz korrekter 
Initialisierung nur schwarze Balken. Solche Probs treten häufig auf, 
wenn LCD und MCU an derselben Versorgungsspannung. MCU ist schon am 
initialisieren, während der POS vom LCD noch rattert.

ciao
gustav

Hallo,
der POS wird vom Display selbst ausgeführt, darauf hat eine externe 
Software, sprich vom MC gelieferte Initialisierungsroutine nur indirekt 
Einfluß, indem Warteschleifen am Anfang eingefügt werden. Ist 
fertigungsbedingt.
Darum geht es aber nicht im Beitrag von mir.
Dachte auch, bei mir funktioniert alles es auf Anhieb.
Mir fiel auf, das das Radio auf FM, das direkt am Arbeitsplatz steht,
direkt nach Anlegen der Betriebsspannung am LCD furchtbar zu knattern 
anfing.
Es war nur ein Testaufbau, um direkt nach dem Erhalt der Ware das LCD zu 
testen. (Genauso verstehe ich die Anfrage des Thread openers.)

Deswegen wurden nur die IMHO allernotwendigsten Verbindungen angelötet:
Versorgungsspannung (an 5V stab.)
Poti (10kOhm) von + nach -, Schleifer an Vee)
Dachte, das reicht. Pustekuchen.
Dann dachte ich, vielleicht Plus mit Minus vertauscht, wie es schon mal 
vorkommt. Ding wird heiß.
OK. Das war's wohl. Mülltonne.
Haaalt!
Nochmals Polung andersherum und mit dem Finger mal an den Anschlüssen 
spielen. Da fiel mir auf, wenn RS, R/Wquer und Enable Massekontakt 
haben, hört das Geknatter im Radio auf.
OK. Fest verdrahtet. Siehe da, der Kontrast läßt sich einstellen, es 
kommen die berühmten Balken oben.
Hinterher alles richtig mit MCU verbunden- und läuft.

Stelle nur fest, wenn ich den Netzstecker paarmal rein- und rausziehe
dass dann das LCD im POS hängenbleibt. Also nur schwarze Balken zeigt.

Da ja noch ein RS232-Anschluß da ist, konnte ich feststellen, daß auch 
dann, wenn sich das LCD tot stellt, die Hyperterminalanzeige losrennt.
Was zu vermuten gewesen wäre, daß die MCU eben nicht korrekt anschwingt, 
war nicht der Fall.

Also: LCD initialisiert nicht, wenn kurz Spannung mal weg ist, sprich
POS muss abgewartet bzw. korrekt gestartet werden können. Der POSReset 
beim LCD wird durch den Spannungsanstieg auf Vcc 
erreicht.Fertigungsbedingt.
(OK. Vielleicht hat das Ding durch die Verpolung doch einen Schlag weg, 
glaube ich aber nicht. Das Ding wird bewusst gestresst: also 
runterfallen lassen, drauf regnen lassen, in Gefrierschrank stellen etc. 
falsche Polung mal sehen ob es härtesten Bedingungen standhält. Kostet 
ja bei Tante Polli nur 4 Euro 95. Den Spaß leiste ich mir.)

Nochmals zusammenfassen:
Verdrahtung des LCD korrekt?
Kontrastspannung mit Poti korrekt? (Poti an + und -, Schleifer an Vee)
Steuereingänge korrekt angeschlossen ?
Portzuweisungen korrespondieren mit MCU und "Software"
Die bei 4-Bit-Modus unbenutzten Eingänge zur Sicherheit über 
Abschlusswiderstände (2,7 kOhm) an GND.
(lieber nicht direkt an Masse - man könnte sich ja im Programm vertan 
haben, dann sind Eingänge plötzlich Ausgänge - und Kurzschluss.)

Hope that helps the father on the bicycle

ciao
gustav

Achtung! Das Anag Vision LCD kenne ich auch, hat aber eine abweichende 
Anschlussbelegung zum im angehängten Bild gezeigten Schema. (Vcc und GND 
liegen ganz woanders, bitte beachten, für selbstverschuldete Unfälle 
wird nicht gehaftet.)

spess53 schrieb:
>>Die bei 4-Bit-Modus unbenutzten Eingänge zur Sicherheit über
>>Abschlusswiderstände (2,7 kOhm) an GND.
>
> Schwachsinn. Du 'erkaufst' dir nur einen höheren Stromverbrauch.

Man kann sich bei noch nicht "sauberem" Programm zum Beispiel bei der 
Busyflagabfrage vertun, hier werden ja Eingänge zu Ausgängen geschaltet. 
Leicht gibt's da einen Kurzschluß, liegen diese Anschlüsse direkt auf 
GND.
Es ist besser, die unteren Datenbusbits auf ein definiertes Potenzial zu 
legen.
Low muss sein, sonst initialisiert's nicht.
.......
Verständnisschwierigkeiten gibt es hier schon in der 
Initialisierungsroutine im Einrichten des Vierbitmodus,
beziehungsweise im Wechsel vom Achtbit- in den Vierbitmodus.
Standardmäßig befindet sich das Display nach dem Power-on-self-Reset im 
Achtbitmodus.
Also, wie können dann ganz am Anfang der Initialisierungsroutine
acht-Bit-breite Befehle gesendet werden, wenn nur noch vier Anschlüsse 
vorgesehen sind ?

Ganz einfach:
Der Code ist schon intelligent genug, bei dem Function Set, wie oben 
beschrieben, nur "High"-Signale im Bereich der oberen Vierergruppe zu 
verwenden.
-->Die unteren vier Bit liegen
verdrahtungsmäßig sowieso meistens (sicherheitshalber über Widerstände) 
schon auf "low", <--

Am Anfang der Initialisierungsroutine steht das Senden von dreimal 
hintereinander Hex 30.
Das bedeutet, daß das Display in den Achtbitmodus gefahren wird.
Die 3 steht ja schon in der Gruppe der höherwertigen Bits.
Gibt also keine Probleme, diese zu senden mit nur vier Anschlüssen.
Nur, man muß jetzt jedesmal noch einen Enableimpuls senden.

Erst jetzt sollte in den Vierbitmodus gewechselt werden.
Dazu sendet man Hex 20, also auch die 2 steht schon in der Gruppe der 
höherwertigen Bits.
Jetzt wird noch ein Enableimpuls gesendet.

Und nun erst kommt der Wechsel in der Art und Weise, wie weitere Befehle
an das Display zur Weiterverarbeitung am sinnvollsten übergeben werden 
sollten.

Man kann natürlich für die Initialisierungsroutine die acht-bit-breiten 
Argumente nach High- and Low-Nibble (Nibble = Gruppe von vier Bits) 
spiegeln, übergeben und danach jeweils einen Enableimpuls programmieren. 
Da der Mikrocontroller nur acht-Bit-breite Befehle laden kann, würde 
dann aus einem LCD-Befehlssatz einmal in Achtbit-Modus-Sendepraxis:

ldi temp, 0b00101000  oder in Hexadezimalschreibweise $28
out datenport, temp
=> nur ein Enableimpuls

dann beispielsweise in Vierbit-Modus-Sendepraxis:

ldi temp, 0b00101000  oder hexadezimal  $28 "high Nibble"
out datenport, temp => Enableimpuls
ldi temp, 0b10000010  oder hexadezimal  $82 "low Nibble"
out datenport, temp => Enableimpuls

So ist es auch in einigen Datenblättern beschrieben.
Und das ist komplett falsch!

Richtig muß es lauten:
ldi temp, 0b00100000  oder hexadezimal  $20 "high Nibble"
out datenport, temp => Enableimpuls
ldi temp, 0b10000000  oder hexadezimal  $80 "low Nibble"
out datenport, temp => Enableimpuls,

denn die unteren 4 Bits müssen ausgeblendet, also im Programm zunächst 
auf null ("low") gesetzt werden. Damit diese unteren vier Portbits nun 
auch anderweitig belegt werden, zum Beispiel zur Übertragung für das RS- 
und Enable-Bit auch ausgenutzt werden können, werden die unteren Nibble 
in der boolschen Algebra zunächst mit dem UND-Befehl ausgeblendet 
(ANDI), anschließend der Port mit dem ODER-Befehl (ORI) maskiert.
Dies wird am besten mit Ausgaberoutinen bewerkstelligt, die ohnehin 
später noch gebraucht werden, immer, wenn etwas ans Display gesendet 
bzw. aus ihm ausgelesen werden soll.
Ab jetzt bietet es sich also in der Initialisierungsroutine geradezu von 
selbst an, daß nach jedem geladenen Befehlsargument, das wie ein 
Achtbitmodusbefehl aussieht, also nach wie vor acht Bits enthält, hier 
beim weiter unten angegebenen Programmierbeispiel in das Label 
"Kommando" gesprungen wird, damit die Enableimpulse nicht noch extra 
programmiert werden müssen. Diese Impulse werden jetzt vom Unterprogramm 
"Kommando" wiederum direkt im weiteren Unterprogrammaufruf des Labels 
"Enable" automatisch ausgeführt.
->Die Enableimpulse müssen nämlich jetzt, nachdem das
Display auf den Vierbitmodus gesprungen ist, nach jedem Nibble gesendet 
werden, das hieße doppelt so oft wie im Achtbitmodus.<-
Die Steuerbefehle zur Initialisierung des Displays sind also im Acht- 
wie Vierbitmodus völlig identisch, werden im Vierbitmodus nur n a c h e 
i n a n d e r übertragen.
Es gibt, wenn man so will, nur einen Achtbit-Steuerbefehlssatz.

Bei den ATMEL AVRs befinden wir uns in der glücklichen Lage,
daß es schon einen Befehl gibt, der Vierergruppen von Bits in der
korrekten Zusammensetzung verschiebt,
also ohne die Reihenfolge der Bits in sich nochmals zu verdrehen,
was in einigen Datenblättern zur LCD-Initialisierung zu weiterer,
nun kompletten Verwirrung führte.
usw....

ciao
gustav

spess53 schrieb:
> Der Zustand von Bit3..Bit0 interessieren bei der Einstellung der
> Datenbreite nicht die Bohne. Können also beliebig L oder H sein. Deshalb
> funktioniert auch eine 4-Bit-Initialisierung mit internen
> Pull-Up-Widerständen und offenen D3..D0.

Das Display ist am Anfang doch im 8-Bit Modus, bevor die 
Umsteuerungsbefehle gesendet werden. Woher weiß es dann, ab wann es in 
den 4-Bit-Modus geschaltet wird?
Die entsprechenden Portbits sind dann noch nicht tri-state (don't care), 
solange nicht die hex20 und hex28 gesendet, sondern können kurzzeitig 
einem u.U. selbszerstörenden Stromfluß ausgesetzt sein. Deswegen R's 
nach Masse - nicht direkt oder offen- wenn's beliebt. Bei ca. 47 k 
Pullups ist's aber doch noch nicht so .....weiß nicht...

Übrigens sollte das Display hier zunächst für mehrere Versuchsaufbauten 
eingerichtet werden, um verschiedene Ansteuerungsmethoden 
auszuprobieren.
Jedenfalls klappt es bei mir nicht ohne definiertes Potenzial am Bus. 
(Siehe UKW-Knatterstörungen).


ciao
gustav

Karl B. schrieb:
> Das Display ist am Anfang doch im 8-Bit Modus, bevor die
> Umsteuerungsbefehle gesendet werden. Woher weiß es dann, ab wann es in
> den 4-Bit-Modus geschaltet wird?

Das war meine eigentliche Überlegung: Ich habe 8-bit-breite Befehle.
Aber die MCU hat nur vier Drähte (an D4-D7). Woher weiß das Display, 
dass D0 bis D3 definiert auf Low stehen für die Befehle hex 30 und hex 
20. Ist da jetzt ein Pullup drin, sieht der Befehl so aus: hex 3F oder 
hex 2F.
Lege ich die Leitung auf GND (über R) habe ich definiert low. Also
vom logischen Standpunkt müssten die unteren Eingänge auf Low stehen.

Man könnte vielleicht verifizieren, indem man in der 
Initialisierungsroutine mal hex3F
explizit reinschreibt, wäre auf das Ergebnis gespannt.

ciao
gustav

Vorsicht Falle: Es geht jetzt nicht um die Portzuweisungsdiskussion im 
weiteren Programmverlauf, die ja schon geführt wurde. Da werden dann die 
swap-Befehle noch geändert etc. etc.

Hi,
habs eben ausprobiert, komisch mal geht's, mal nicht. (Anstelle hex30 
hex3F und anstelle hex20 hex2F und die Widerstände raus). Meistens 
bleibt's bei den schwarzen Balken.

(Jetzt an einem anderen Display Displaytech162F  = DCF77)

Also, bleibe bei meinen hex30 und hex20.

Das kann so auch nicht gehen, weil die Steuerbits am MCU-Port mit high 
überschrieben werden.
Müsste den Versuch nochmal mit voller 8-Bit-Verdrahtung an MCU 
wiederholen.
Vielleicht komme ich noch dazu.

ciao
gustav


Hauptsache die Uhrzeit stimmt.......(grins)

Karl B. schrieb:
> komisch mal geht's, mal nicht

Du findest hier 1001 Beiträge zum LCD mit dieser Aussage. Die Ursache 
ist immer die gleiche: Da wollte jemand schlauer sein als das 
Datenblatt. Es gibt (auch hier im Forum zu finden) erprobte 
Initialisierungen nach Vorgabe des Datenblattes. Wenn die Hardware 
passt, funktionieren die immer und zuverlässig.

Karl B. schrieb:
> Das war meine eigentliche Überlegung: Ich habe 8-bit-breite Befehle.
> Aber die MCU hat nur vier Drähte (an D4-D7). Woher weiß das Display,
> dass D0 bis D3 definiert auf Low stehen für die Befehle hex 30 und hex
> 20. Ist da jetzt ein Pullup drin, sieht der Befehl so aus: hex 3F oder
> hex 2F.

 Du hast es immer noch nicht verstanden.

 Beim Init wird zwar 8-bit angenommen aber trotzdem werden nur die
 bits 4-7 geprüft.

 Deswegen ist es auch absolut egal, ob 0x30 oder 0x3F gesendet wird.

 Also:

 Es wird 3 Mal 0x30 gesendet, dabei reicht es vollkommen, Enable in
 einem Abstand von 1ms Low-High zu schalten, du brauchst nicht 3 Mal
 Daten zu senden (wie in deinem Program).

 Danach wird 0b0010xxxx für 4-bit Breite gesendet (wobei es wiederum
 egal ist, ob 0b0010 1111 oder 0b0010 0000 gesendet wird), es werden
 nur die oberen 4 bits geprüft.

 Für 8-bit Breite wird 0b0011 NFxx gesendet.

 Soll heissen:
 Wenn bit4 High ist, dann geht es mit 8-bit weiter, wenn bit4 Low
 ist, geht es mit 4-bit Breite weiter.

 P.S.
 Es werden zuerst nur High Nibbles gesendet.
 0x30
 0x30
 0x30
 0x20
 Ab jetzt sendet man Bytes, z.B.
 0b0010 N F x x
 ...

spess53 schrieb:
> Auch wenn im Display-Datenblatt die unbenutzten Pins auf VCC gelegt
> werden sollen, gibt es im Datenblatt des ST7036 keinen Hinweis, das das
> ein Muss ist.

Nach meiner Erinnerung steht da eh was von "können"....

Marc V. schrieb:
> Beim Init wird zwar 8-bit angenommen aber trotzdem werden nur die
>  bits 4-7 geprüft.

Das hatte ich mir schon gedacht. Die Prämisse ist falsch. Denn es 
funktioniert bei Versuch mit 8-bit-Busbreite tatsächlich in beiden 
Varianten.
(Die Steuerimpulse werden dabei über einen anderen MCU-Port gesendet.)
Im Datenblatt steht aber nicht "supposed to be 8 Bit" sondern nur: 8 
Bit... und Busyflagabfrage geht nicht, solange etc....
OK. Das würde ja schon darauf hinweisen, dass zu dem Zeitpunkt der Ini 
nicht die volle Busbreite benötigt wird.
Dass man nicht immer wieder gebetsmühlenartig alte Werte ins selbe 
Register laden muss und Ausgaben erzeugen, einfach Enable toggeln 
lassen, ist eine brauchbare Programm-Verschlankung. Danke für den Tip. 
Insofern hat sich der Thread für mich gelohnt.


Mit LCD-Initialisierung hatte ich schon seit etwa 2008 echte Probs bzw. 
Verständnisschwierigkeiten.

Was jetzt als nächste Fehlerquelle numero 1 kommt, wären die 
Verzögerungsschleifen.

Da wurde bei meinem ersten Init Programm (nicht das hochgeladene) nicht 
beachtet, dass man für die Variablen-Register nicht dieselben 
Temporärregister in den Zeitschleifen nehmen sollte, ohne zu pushen und 
zu poppen.

Zeige hier mal, welcher Murks das allererste Init-Programm war:
(Übrigens auch vom Mikrocontroller.net nicht hinterfragt abkopiert)

Fehlerquelle numero 2 ist oft:
Das Display verarbeitet im 4-Bit-Modus die gesendeten Nibble 
unveränderbar in fester Reihenfolge. Also zunächst High Nibble, dann 
Low-Nibble. Da ist nichts dran zu rütteln.
So muss es dann auch von der MCU geswappt werden. Die Reihenfolge ist 
wichtig. Wenn jetzt noch die Portbits anders definiert werden, verdreht 
sich u.U. alles wieder. Ich hatte mich für die nicht im Tutorial 
gezeigte Variante entschieden (mittlerweile steht da auch noch ein 
diesbezüglicher comment drin).

ciao
gustav