LC Display schaltet nicht ein

[gamy (Gast)]

Hallo,ich habe LC 
(http://www.voelkner.de/products/28506/LCD-Modul-Stn-Refl.-Gelb-Gruen-16x2.html#tech-data) 
gekauft und angeschlossen aber die wird nicht reagiert und wird nicht 
mal nicht geschaltet ,ist die Kaputt,wie kann ich den Display üperprüfen 
,ob kaputt ist ?
Danke im Voraus
lg

[Rufus Τ. F. (rufus)]

gamy schrieb:
> und angeschlossen

Woran?

Und wie?

[gamy (Gast)]

Danke erstmal für Schnelle Antwort
alles hab ich wie im Bild  von pin1 bis pin14 außer 7,8,9,10  weil 4 Bit 
Mod und pins15,16 habe ich nicht angeschlossen ,Das hatte ich vergessen 
zu erwähnen, 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

[Christian (Gast)]

Schließ noch die Hintergrundbeleuchtung (pin 15 &  16) an.

[gamy (Gast)]

ich habe gehört ,pin 15 und 16 ,braucht man nicht oder?

[Axel S. (a-za-z0-9)]

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.

[Nop (Gast)]

Woran hast Du das angeschlossen? Und initialisierst Du das 
softwareseitig auch richtig und überträgst Daten?

[spess53 (Gast)]

Hi

>ich habe gehört ,pin 15 und 16 ,braucht man nicht oder?

Hat dein Display überhaupt eine Beleuchtungg.

MfG Spess

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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.

[Karl B. (gustav)]

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

[spess53 (Gast)]

Hi

>Hatte ähnliches Problem.

Warum muss man dafur die Geschichte der Menschheit sei dem Urknall 
erzählen?

Es hätte gelangt, wenn du gesagt hättest: Ich habe die Wartezeit lt. 
Datenblatt nicht eingehalten.

Mit µC und LCD an der gleichen Versorgungsspannung hat das überhaupt 
nichts zu tun. Das machen zehntausend Andere auch so. Ohne Probleme.

MfG Spess

[Karl B. (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 (Gast)]

Hi

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

Klar haben die Wartezeiten keinen Einfluss auf den POR. Aber bei zu 
kurzer Wartezeit fängt die Initialisierung schon während des POR an.

>Der POSReset beim LCD wird durch den Spannungsanstieg auf Vcc
>erreicht.Fertigungsbedingt.

Aber nur durch den richtigen. Der POR funktioniert nämlich nur, wenn die 
Spannung am LCD innerhalb von 10ms erreicht wird.

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

Außer E haben alle anderen LCD-Anschlüsse( RS, RW und D0..D7) 
integrierte Pull-Up-Widerstände. Damit wäre E der einzige Eingang der im 
Normalfall Störungen einfangen kann.

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

MfG Spess

[Karl B. (gustav)]

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 (Gast)]

Hi

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

Man legt sie nicht auf GND, sondern lässt sie offen.

>Es ist besser, den Datenbus auf ein definiertes Potenzial zu legen.
>Low muss sein, sonst initialisiert's nicht.

Hast du eigentlich schon mal ein Datenblatt eines Displaycontrollers 
gelesen?

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.

>Ganz einfach: ...

Nochmal, keine Menschheitsgeschichte ab Adam und Eva. Die ersten 
LC-Displays habe ich vor fast 20 Jahren benutzt.

MfG Spess

[Karl B. (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

[spess53 (Gast)]

Hi

>Das ist von Display zu Display verschieden dokumentiert. Siehe
>DOGM-Serie.

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. Lt.Tabelle auf S.63 sind im Parallelmode die internen 
Pull-Up-Widerstände eingeschaltet. Also gilt das gleiche wie für HD77480 
und kompatible: offen lassen.

Abgesehen davon benutze ich bei DOG-Displays keine 8/4-Bit-Parallel 
sondern die serielle Ansteuerung.

>Jedenfalls klappt es bei mir nicht ohne definiertes Potenzial am Bus.
>(Siehe UKW-Knatterstörungen).

Das ist aber nicht das normale Verhalten von Displays. Aber nach deinen 
Misshandlungen wurde ich auch als Display 'knattern'.

MfG Spess

[Karl B. (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.

[Karl B. (gustav)]

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)

[Georg G. (df2au)]

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.

[Marc V. (Firma: Vescomp) (logarithmus)]

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

[Teo D. (teoderix)]

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

[Karl B. (gustav)]

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