Das ist ja Merkwürdig. Wie meinst Du das mit dem PIC die Zeichen übergeben ? meinst DU im Quelltext mit 'K' , oder meinst Du über Uart?
Normalerweise dürften die ASCIIS vom Compiler nicht gespiegelt werden. Kannst ja mal 0x41 anstatt 'A' testweise ausprobieren. Wenn beide das gleiche ergebnis liefern, dann
liegts jedenfalls nicht am Compiler. Hattest Du den Datenbus vieleicht falschrum am Controller , und jetzt ist er richtigrum??

Hallo...

Wenn ich in Quellcode 0x41 statt "A" schreibe, dann kommt ein A im display an.

Ich übergebe dem Compiler schon den wert A (das was angezeigt werden soll iss schon im Programm gespeichert, kein Uart.)

ich denke die Datenleitung iss jetzt richtigrum, weil er die richtigen Buchstaben anzeigt, wenn ich sie ihm im compiler übergebe...

alle steuerbefehle hingegen muss ich nibbleweise spiegeln
( die übergebe ich dem compiler als binärcode)

woran könnte das liegen?

jetzt muss ich aber noch was fragen:

Ich krieg s nicht hin, dass er wenn er in der mitte des displays angekommen ist auf die richtige DD-Ram adresse springt um die zweite hälfte des displays zu beschreiben...

Liegt da noch ein Speicherbereich dazwischen?
wenn ich ihn einwach die ganze zeit in einem loop was schreiben lasse, dann schreibt er bis zur hälfte, dann dauert das etwas(ausgezählt ungefähr 48 buchstaben lang)
und dann schreibt er auf die 2. Hälfte...
ich experimentier schon ne weile nun rum um die richtige Speicheradresse zu finden...
ich übergeb sie auch im Binärcode (weil ich sie ja nibbleweise spiegeln muss)

das display hat 1 zeile 16 Buchstaben...

as muss ich da nun für ne Adresse ansteuern für buchstabe 8???

bitte hilfe, trial and error iss hier zu zeitaufwändig und irgendwie hab ich das gefühl 0x40h isses nicht, dass iss doch hex oder?

das müsste dann der Adresse 64 entsprechen, oder?

das wäre binär dann '0111 1111' Oder?

IOch komm schon auf ne adresse knapp daneben, aber wenn ich auf 0101 1111 geh, dann fehlen 2 adressen, d.h. er fängt in einem Speicherbereich vor 40h zu schreiben an, was auf dem display unsichtbar bleibt...

vom Wort "Bereit" bleibt dann am display

_ _ _ _ _ _ _ _ r e i t _ _ _ _

wobei ein underline für einen leeren Buchstaben steht...

bitte hilfe... ich komm nich weiter...
mfg Quirin

Hier sind die adressen aufgelistet:
http://www.sprut.de/electronic/lcd/index.htm#adressen

btw, ich benutz den 16F877, und wenn ich schreib:

movlw 'G'
call OutLcdDaten

dann funzt das ohne irgendwas zu tauschen...

mit steuerzeichen das selbe.

weis nicht in wieweit sich die typen im assembler untschrscheiden, aber die OutLcdDaten funktion macht bei mir nix andres als busy flag abfragen und dann das 'G' auf den LCD anschluss port zu legen..
Ich benutz das ganze zwar 8-bittig, aber das sollte dabei ja wurscht sein.

Chris

aso, und:

0x40h ist nicht 0111 1111 sondern 0100 0000 ... wenn du ersteres genommen hast, würd ich die probleme damit erklären, dass dein display keine Speicheradresse 127 oder auch 0x7Fh hat (das kommt raus wenn man deins umrechnet)

also versuch mal mit 0100 0000 oder direkt 0x40 (wozu selber umrechnen??) :)

Chris

Argghl.. ich muss es selber umrchnen , weil ich es nibbleweise spiegeln muss!!!

entweder ich muss meine Buchstaben von hand umrechnen und spiegeln oder ich muss meine Befehle umrechnen und speigeln, beides geht nicht, weil das Programm ja in oben genannter weise spinnt!? ich verstehs ja nicht!!!!

trotzdem danke für die adressliste, werd mir das ma angucken und dann sag ich wieder bescheid!! bis dann
Quirin

Zeig nochmal Deine aktuelle Version des Programms, dann können wir mal schauen.

Nur noch mal zur Info fals Dein Problem da liegt

Binärcodes:
| Byte |
| High Nibble | Low Nibble |
bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0
128 64 32 16 8 4 2 1

Hex Codes können Nibbleweise in Binär umgerechnet werden.
z.B 0x40 : 4 -> 0100 0 -> 0000
was dann 01000000 gibt.

Ja... muss ich zugeben... die umrechnerei is eins meiner probleme... hier iss mal mein jetziges Programm...

hab die ganze zeit versucht direkt nach der initialisierung in die 2. zeile mit dem befehl 1 101 1111 umzuschalten... mit diesem befehl komm ich dem ganzen am nächsten... versteh auch nicht warum...

als info:

Alle Steuerbefhle sind Nibbleweise gespiegelt d.h. aus
'1010 1110' wird '0101 0111'

das 'T' im unterprogramm "haupt" wird in 300ms abständen immer in die nächste adresse geschrieben, zu testzwecken.

Ansonsten funktioniert das programm 1A muss nurnoch mehr optimiert werden...


bin ja mal auf deine meinung gespannt

mfg Quirin


Hochgeladene Datei : workinglcd.txt

Ich hab eben mal in meiner DisplayRoutine geschaut, und bei mir klappt das mit dem 0x40 . Man muss dem Display dazu den Befehl 0xC0 senden, also 11000000 .
Das ist auch ein Einzeiliges Display mit 16 Zeichen. Bei Mir ist übrigens ein SED1278 Chip auf dem Display. Der original HD44780 ist das fast nie(Ich hab aber auch ein Display mit HD44780, war sehr erstaunt, denn ich dachte den gibts nur in Sagen und Legenden.)

Ich send ihm mal schnell den befehl... bin gleich wieder da!

Toll... jetzt blick ich garnicht mehr durch:

Wenn ich den Befehl 1100 0000

also bei mir mit gespiegelten nibbles

0011 0000
sende, dann zeigt er schwarze ausgefüllte buchstabenfelder (cursorzeichen ascii 1111 1111) i9n der ersten hälfte des displays(zeichen 1-8) an in denen schwächer , also hellgrau(nicht leer) irgenwelche anderen zeichen durchschimmern!!

das ist seeeeeeehr unerklärlich!

was ist das?

ps ich muss ja um ihm klarzumachen, dass jetzt eine DD-Ram adresse kommt immer 1xxx xxxx senden, oder?

mfg quirin

Also, mal schauen...

Bei Init Schritt 4 ist der Befehl garnicht gespiegelt, aber es funktioniert...ist das Display vieleicht doch jetzt richtig angeschlossen?
Mal weiterschauen...wenn das so währe, dann würden die anderen Befehle was machen?
Schritt 7 setzt cgram adresse ->egal
Schritt 8 macht cursor home ohne löschen
Schritt 9 schaltet das Display aus
Schritt 10 schaltet es wieder an mit Cursor der nicht blinkt


Wenn Du ein Cursor im Display siehst, obwohl Du den eigentlich ausgeschaltet haben wolltest, dann wirds wohl daran liegen, dass Du nur glaubtest, die Befehle nibbleweise invertieren zu müssen. Mach das am besten mal rückgängig/neu, und dann wird das schon klappen !
Ich denk ja mal, Das Display ist jetzt so an den Port angeschlossen:

Display Micro
Pin14 -> bit3
Pin13 -> bit2
Pin12 -> bit1
Pin11 -> bit0

Das ist nämlich richtigrum.

Du hast grade gepostet, während ich am schreiben war. Dein Ergebnis stützt nur meine Theorie. Mit dem Befehl 0x30 schmeisste nämlich das Display wieder in den 8bit Modus....

Ähm ok... da hast du recht...
sowas kommt bei trial and error initialisierung raus...
ich schreib das grad mal alles auf nicht invertierte Nibbles um und dann sag ich dir bescheid...
bis gleich Quirin