Einiges dazu findest Du auch in dem langen posting vom 30.01.2004, 15:11, Punkt 7 ("INIT"), anderes nicht, deshalb also:

Warum zuerst mit &H38 ("FunctionSet") in den 8-bit-mode -- Ich denke mir das so (bin mir aber nicht ganz sicher):
Niemand kann mit Bestimmtheit sagen, in welchem Modus das LCD beim Aufruf von LCD_INIT ist:
Eigentlich sollte es selbst einen power-on reset gemacht haben und deshalb im 8-bit-mode sein (ist so definiert);
manchmal tut es das aber auch nicht (ist so definiert, zb wenn nicht genug Spannung oder sowas da ist);
wenn aber ein anderer Programm-Zweig schon mal LCD_INIT aufgerufen hat, dann ist es im 4-bit mode.
Deshalb sollte LCD_INIT so geschrieben sein, dass es sowohl bei aktuell laufendem 4-bit, als auch bei 8-bit mode immer in den 4-bit-mode schaltet.
EINE Möglichkeit dazu ist (hab nicht gecheckt, ob's die einzige ist):
Zuerst in den 8-bit mode setzen; dann weiss man woran man ist;
dann in den 4-bit mode setzen; da will man ja hin;
dann im 4-bit-mode alles weitere sagen, denn die Routinen braucht man eh.

Deshalb also zuerst &H38 mit LCD_WRITE_CMD schicken, denn:
Im 4-bit mode ist das das Command "FunctionSet" (bits 001) mit Parametern DL=1="8-bit-mode" (die folgenden Parameter sind auf der HTML-Seite nicht beschrieben: N=1= "2 Zeilen-Display" und F=0= "5x7 characters in 5x8 Matrix").
Im 8-bit-mode gibt diese Ausgabe etwas Mist, aus zwei Gründen:
Erstens gibt LCD_WRITE ja in zwei Takten aus, aber das sind dann im 8-bit-mode für das LCD auch ZWEI Befehle.
Und zweitens sind ja gar nicht alle 8 Datenleitungen des Port zum LCD durchkontaktiert, sondern nur die niedrigwertigen 4 bits des Port auf die höherwertigen vier Datenleitungen des LCD; die niedrigwertigen DL's des LCD hängen in der Luft.
Das LCD erhält also irrtümlich zwei Commands:
&B0011xxxx (FunctionSet, DL=8 bit), und &B1000xxxx (SetDDRAM): Aber OK, ist kein Beinbruch.

Immerhin: Jetzt sind wir also definitiv im 8-bit-mode.
Im Gegensatz zu vorhin (Ausgabe mit LCD_WRITE) legen wir jetzt das Byte &H02 DIREKT an den LCD_PORT an. Das ist also NICHT das Command "02=CursorHome" -- wird ja nicht mit LCD_WRITE ausgegeben; sondern:
Auf grund der Hardware-Kontaktierung stehen im höherwertigen Halbbyte des Port die Steuerleitungen zum LCD (hier: R/W=0 "write", RS = 0 = "RegisterSelect"), und im niederwertigen Halbbyte des Port die 4 HÖHERWERTIGEN Datenbits für's LCD (ist ja so verdrahtet für den 4-bit-mode!!)
Folglich bedeutet die DIREKTE Portausgabe &H02=&B00000010 für das LCD das Command $B0010xxxx, und das ist "FunctionSet" mit DL=0= "4-bit-mode" (restliche bits sind wieder undefiniert, weil nicht kontaktiert).

So: Jetzt sind wir also definitiv endlich im 4-bit-mode.
Das &H28 wird mit LCD_WRITECMD ausgegeben, ist also ein command und bedeutet fast dasselbe wie das vorher das &H02 direkt am Port angelegt, nämlich wieder "FunctionSet" mit DL=0= "4-bit-mode", aber jetzt können wir auch die restlichen bits definiert setzen und damit "2 Zeilen" und "5x8 Matrix" sagen (ähnlich wie vorher &H38 für den 8-bit-mode).


Falls sich tatsächlich ein Hardware-Entwickler das ABSICHTLICH so VORHER überlegt hatte, kann ich nur sagen: Muss Des-sign? -- Aber lass Dich nicht abschrecken: es gibt auch Einfacheres!