also 00001000 = 8 haste ja richtig erkannt... aber warum testest dann das vierte bit? und nicht das dritte.. (man fängt bei 0 an zu zählen..)
das gleich dann bei 16.. da ists bit nr. 4 und nicht 5..

dann haste schon wieder die 0x40 in 11000000 umgerechnet.. richtig wäre das 01000000! du kannst dir das umrechnen aber auch sparen wenn du wie schon erwähnt die 0x40 direkt hin schreibst.. der assembler kann damit genauso viel anfangen.

Gruß,
Chris

Die erste 1 in 1100 0000 ist die kennung für den prozessorbefehl DD-Ram adresse setzen...

also 1xxx xxxx die adresse ist hierbei nur 7-bittig...

oder?

ansonsten werd ich das heut abend mal ausprobieren... ich sag dann bescheid...
Danke...

Quirin

@Verion: Quirino hat recht. Der Befehl ist mit 11000000 schon richtig, um zur zweiten hälfte der Zeile zu wechseln.

@Quirino: Das stimmt mit den Bits was Verion sagt. Das bit3 ist 8 wert, und das bit4 16 (siehe meine Beschreibung oben), ein bit ist immer soviel Wert wie "2 hoch bitnummer".

Ansosnsten müsste Dein Code prinzipiell in Ordnung sein. Achso: Du solltest den Zähler am anfang Deines Programms einmal auf null setzen. Das Zeichen muss vor dieser Routine in das Display geschrieben werden, da sonst ein Zeichen zu früh der Speicherbereich gewechselt wird.
P.S. Ich hab das mit dem Home nicht von der Position abhängig gemacht, sondern ein extra Home COmmando implementiert. Man will ja meisten Home machen, bevor man einen Text schreibt.

So... langsam kommen selbstzweifel auf... bei der eweigen fragerei hätt ich das ja auch gleich euch programmieren lassen können

also...

zähler iss am anfang des programms auf 0 gesetzt...

nun gibts 2 möglichkeiten:

1. Wenn ich diesen programmteil NACH der buchstabensendung ausführe, dann passiert NICHTS . d.h. es verhält sich als wär der Programmteil nicht DA!

2. wennich den Programmteil VORHER ausführe, dann wirt einen Buchstaben zu früh gesprungen (Das ist mir noch klar) aber es werden wieder unbekannte Zeichen an stelle 1 und 8 des displays angezeigt

deshalb poste ich nun noch einmal mein GANZES Programm... ihr müsstet den Grossteil eh schon auswendig kennen, das hauptaugenmerk leigt auf dem Teil der die adressen umsetzt...

die zähler sind jetzt korrigiert, d.h. sprung bei bit 3 und 4...

langsam tuts mir echt schon richtig leid euch so oft zu beanspruchen... ich hoffe das is nu das letzte probelm mit diesem nervigen programm... aber durch die LCD-Display ansteuerung muss jeder mal durch!

also hier mein programm ich bite ein letztes mal um hilfe...

mfg Quirin

Hochgeladene Datei : workinglcd.txt

sorry, an das bit für den steuerbefehl hab ich nich gedacht.. war schon spät :)

Chris

So, ich hab schonmal einen Bug gefunden. Du überschreibst Dir Deinen "sendbuf" an der Stelle, wo Du aus der "sendchar" funktion die "send4bit" funktion aufrufst, um die Addresse zu ändern. Die verwendet ja den "sendbuf" auch, und dann ist Dein Buchstabe durch den Befehl überschrieben.

Ich versteh allerdings nicht, warum der Programmteil garnichts tut, wenn Du ihn hinter das Buchstaben Senden packst. Bau das doch nochmal so um (dann hat sich auch die erste Problematik erledigt), und poste es dann nochmal, wenns immer noch net funzt.

Zum Thema Nerven: Ich langweile mich hier eh grade nur....
also nervst Du mich nicht.

So hallo wiedermal...

Also...

Ich hab nun den buffer umgeschrieben. nun gibt's einen extra buffer für Buchstaben und einen extra buffer für befehle...

Funktioniert so wiet ganz gut... Es zeigt alles richtig an... allerdings nur bis zum 9. buchstaben...

Wenn ich beim schreiben der T's (die testroutine) mitzähle, stelle ich fest, dass auch die anzahl der schritte die er braucvht um das Display ganz zu beschriften genau stimmt (16) allerdings zeigt er die letzten 7 Ts Garnicht an: Bildschirmausgabe:

TTTTTTTTT-------

Wobei ein - jeweils für ein leeres feld steht...

wenn er nach dem 8. Buchstaben weiterzählt, dann bleibt doch bit 3 weiterhin gesetzt... kann es sein, das er nach dem 8. Buchstaben immer auf 8 zurückgesetzt wird (bedingung ist ja dafür erfüllt...)

KAnn ich das eindfach beheben oder muss ich noch eine Speicherposition belegen, die speichert ob er gerade in die 1. oder 2. hälfte des Displays schreibt...

ich hab mir das so vorgestellt:

zählen...
bei 8 zähler rücksetzen und

wenn extra speicheradresse auf 0 dann extra speicheradresse auf 1 setzen
cursor auf 40h

wenn extra speicheradresse 1 ist auf 0 setzen
cursor home

geht das nicht einfacher (will speicher sparen...),
das soll ja nur ein teil des gesamtprogramms werden...

geht das an sich so?

Danke schonma...
mfg Quirin

Haha, hoho... hab das ganze mal programmiert, funktioniert natürlich nicht... tut nischt...

bin wiedermal zu blöd den bug zu finden...

;mitzählen und cursor beim 8.buchsaben(0000 1000) auf 40h setzen... beim 16.(0001 0000) cursor home

incf charpos,1 ;zähler um 1 erhöhen

btfss charpos,3 ;wenn bit3=1 also zähler springt auf 8 dann
goto skipall ;andernfalls übergehe



btfss lineflag,0 ;wenn in zeile 2 dann
goto skipflag ;andernfalls


movlw B'00000011' ;cursor home
call send4bit ;senden an port B

call delay5 ;5 ms warten

clrf lineflag ;zeilenzähler auf 0
clrf charpos ;buchstabenzähler auf 0

goto skipall ;ende des zeilensprunges



skipflag


movlw B'11000000' ;auf adresse 0x40h (2.hälfte des displays)
call send4bit ;senden an port B

call delay5 ;5 ms warten

bsf lineflag,0 ;merken dass lcd in zeile 2 ist
clrf charpos ;buchstabenzähler auf 0

skipall


bin ich blind oder am ende eines langen tages nur zu gestresst um das sauber hinzukriegen?

mfg... Quirin

Gibt es denn keinen Simulator für Pic's? Wenn nicht, solltest du zum AVR umsteigen

_________________
mfg Jornbyte

Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.

Du kannst doch das Word mit ner Zahl vergleichen, Du brauchst ja nicht die Bits abzufragen! Und dann kannste das zweite Register ausbauen. Dein Code ist so ein Durcheinander, dass ich grade garkeinen Bock hatte, ihn zu lesen.

Wieso durcheinander?

Wie würdest denn du sowas übersichtlich schreiben??

Wie gesagt, ich programmier noch nicht soo lang...

na gut... werd versuchen selbst mit dem Problem fertig zu werden... hab eure geduld ja lang genug mit dem Thema strapaziert... sorry...

mfg Quirin

@ Jornbyte:

Ähm ja... ich hab einen simulator für den PIC16f628, aber der versagt mir bei diesem Programm irgendwie den Dienst... scheint nicht so das beste zu sein...