Hallo JanPeter!
Ja, wieder zurück: war sehr schön (aber auch sehr teuer...)

Die hex 25: meinst Du dieses Teil: ' read back LCD PCF (test only) ?

An dieser Stelle wollte ich einfach den momentanen Inhalt der PCF Ports lesen (das ist noch NICHT der Inhalt des LCD, das am PCF hängt -- das kommt erst später im Test).

Woher kommt die HEX 25:
Ich hatte vorher als letztes Zeichen ein kleines "u" ans LCD ausgegeben; kleines u ist HEX 75. Um dies als Daten ans LCD auszugeben (im 4-bit mode), musste ich die Nibbles 7 und 5 einzeln ans LCD schicken, jeweils mit RS=1=DATA, und um E zu "pulsen" je einmal mit E=1 und E=0. Insgesamt werden damit für das eine Data-Byte $75 vier Bytes an den PCF und das LCD geschickt, und zwar $67 - $27 (für das high nibble "7"), und dann $65 - $25 (für das low nibble "5" von $75="u").
Genau dieses letzte Byte $25 muss jetzt wieder reinkommen, wenn ich einfach vom PCF lese (und tuts auch). -- Kleines u habe ich nur genommen, weil dann das zurückkehrende Nibble "5" schön abwechselnd die Kombination 0101 ist...

Den eigentlichen Inhalt des LCD zu lesen, ist erheblich aufwendiger; wird in Routine "LCD_READ" gemacht:
Wegen 4-bit mode werden auch hier zwei Nibbles gelesen, und weil E gepulst werden muss, muss man zum LESEN vom LCD insgesamt 4 Bytes SCHREIBEN und 2 Bytes LESEN. Dabei hatte ich zwei Probleme:
1. LCD READ data (1 Nibble) sind nur gültig während E=HI
2. Von den 8 Bits des PCF sind zwar die LCD Steuerleitungen OUT, aber die 4 Datenleitungen sind mal OUT, mal IN. Damit ich die IN Daten vom LCD lesen kann, muss ich vorher "1111" auf diese PCF-Ports schreiben; das wird vom LCD ignoriert, weil ich dem LCD in der Steuerleitung ja gleichzeitig R/W = 1 = READ sage, und für den PCF bewirken die "1", dass auf INPUT umgeschaltet wird ("quasi-bidirectional I/O without the use of a control signal for data direction").

Uff!