Ich habe dein Programm nicht gelesen. Habe aber eine Gegenfrage:
machst du eine kleine Pause, nachdem du das Zeichen an das LCD übergibst?

_________________
mfg Jornbyte

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

Moin,

Wie sollen wir denn den Fehler finden, wenn wir den Originalkode nicht haben?

Du musst keine Verzögerung, wie von Jorn vorgeschlagen, reinbauen, wenn du das Busyflag testest. Das tust du, ob du es richtig machst, kann ich dir nicht beantworten, da ich keinen PIC-Assembler verstehe, oder nur rudimentär.
Sollte das Testen des Busyflags allerdings nicht klappen, dann ist Jornbytes Einwand allerdings berechtigt.

Tabelle? Werden denn die richtigen Zeichen im ROM korrekt addressiert? Wann ist der String zuende? Nullterminiert? Oder bekannte Länge? Wenn er nicht nullterminiert ist, dann wird fleißig jeder weitere Datensalat aus dem Flash oder RAM gelesen und als Datenbyte ins Displayram kopiert. Nullterminiert bedeutet aber auch, dass du selbst überprüfen musst, ob das gelesene Zeichen ungleich NULL (0) ist! Sind die Zeichen unter den ASCII-Zeichen 0x0-0x7, dann wird der Inhalt des Character Generator RAMs aufs Display abgebildet. Das Ganze geht so schnell, dass du vermutlich kaum die ersten paar korrekten Zeichen des Strings sehen kannst, bevor sie mit Datensalat überschrieben werden. Ist dann noch ein Fehler in der LCD-Routine, was ich wie gesagt nicht herausfinden kann, dann ist es klar, dass das nicht geht.

Hast du denn das Display überhaupt korrekt initialisiert? Sieht ganz und garnicht so aus! Eine fehlerhafte Initialisierung ist schlecht.
Hast du irgendwo eine Endlosschleife eingebaut? Ja, bei warten2. Wird zwar, soweit ich sehe, nie ausgeführt, ist aber blödsinnig.
Andere Probleme sind vllt. vorhanden, kann ich aber schlecht sagen, da Assemblerdialekt fremd.



---
Mi den Strings ist das so eine Sache, die man ohne Quellkode nicht beantworten kann, zumal der sicherlich nicht so lang sein wird, dass man ihn nicht hier reinstellen könnte.

_________________


[ Diese Nachricht wurde geändert von: DonComi am 12 Apr 2008  2:58 ]

Zitat :

machst du eine kleine Pause, nachdem du das Zeichen an das LCD übergibst?

Ich frage das Busy-Bit ab. Ich habe die Routinen aus dem alten Programm nicht geändert, und da hat es einwandfrei geklappt.

Zitat :

Tabelle? Werden denn die richtigen Zeichen im ROM korrekt addressiert? Wann ist der String zuende? Nullterminiert?

Ich habe das so gemacht: Ich lege einen dt-String ab, an dessen Ende ein 0xFF steht. die Sendeschleife hat geprüft, ob das eingelesene Byte 0xFF ist und hat dann aufgehört.

Im hochgeladenen Code wird jeder Buchstabe einzeln übertragen, und dann in eine Endlosschleife gesprungen.

Zitat :

Hast du denn das Display überhaupt korrekt initialisiert? Sieht ganz und garnicht so aus!

Ich habe ja die einzelnen Schritte kommentiert, was fehlt denn deiner Meinung nach?

Ich habe jetzt mal das Programm so umgebaut, dass man für jeden Buchstaben einen Taster drücken muss. Ergebnis bleibt aber das gleiche.

_________________
Fnord ist die Quelle aller Nullbits in deinem Computer.
Fnord ist die Angst, die Erleichterung, und ist die Angst.
Fnord schläft nie.

Würde dein Code exakt sein, würde aber dieser Fehler nicht auftreten! Es muss ein Wurm drin sein, und der Teil, der das Busyflag pollt ist recht merkwürdig.

Normalerweise sehe das so aus:

- Port auf Eingang stellen
- Instruction Register anwählen
- Edit: Read-Write auf Read stellen!
- E setzen, solange E high ist, steht Busyflag zur Verfügung
- Warten, bis Busyflag low wird
- E löschen
- Port auf Ausgang stellen

---
Bei dir sieht das irgendwie komisch aus.
Solche Fehler treten i.d.R. dann auf, wenns dem Kontroller zu schnell geht, siehe Jornbytes Einwand.
Mach doch mal eine Verzögerung nach jedem Zeichen von ca. 1ms rein - ist viel zu viel, aber besser reproduzierbar. Schreibe Debugkode, der es ermöglicht, das Busyflag mit dem Oszi zu betrachten. Vielleicht wird das Busyflag einfach übersprungen - dann ist dieser Fehler im wahrsten Sinne des Worten vorprogrammiert
(Wie gesagt, ich kann diesen Dialekt nicht 100%, nur in Etwa nachvollziehen, was passiert)

Die Initialisierung sieht normalerweise noch etwas anders aus:
Laut Pollins Beschreibung zu meinem ersten Display (Wintek irgendwas) soll man nach Erreichen der Betriebsspannung von etwa 4,5V noch etwa 15ms warten.

Man schreibe nun 0x30 ins Instruction Register,
warte 4,1ms oder mehr,
schreibe erneut 0x30,
warte 100µs oder mehr
und schreibe erneut 0x30.
Nun erst ist das Busyflag nutzbar.
Es folgen die Befehle zum Initialisieren, wobei Systemset der erste ist.

Aus rechtlichen Gründen verweise ich hier nur auf das PDF, du findest es hier:
Bestell-Nr.: 120 232
-> Download
-> Text LCDs.pdf (oder so)

Dort steht das drin. Daran halte ich mich seit Ewigkeiten, und alle Displays laufen.


Zu den Strings:
Keine Ahnung, wie das bei Pics mit den Adressen ist, ob die Word- oder Byteweise adressiert werden, aber kann es nicht sein, dass du an der falschen Stelle ließt?

Dennoch deutet der Fehler auf ein fehlerhaft initialisiertes Display hin. Oder du schreibst die Daten ins falsche Register.

_________________


[ Diese Nachricht wurde geändert von: DonComi am 12 Apr 2008 12:57 ]

[ Diese Nachricht wurde geändert von: DonComi am 12 Apr 2008 13:02 ]

[ Diese Nachricht wurde geändert von: DonComi am 12 Apr 2008 13:04 ]

Zitat :

Man schreibe nun 0x30 ins Instruction Register, warte 4,1ms oder mehr, schreibe erneut 0x30, warte 100µs oder mehr und schreibe erneut 0x30.

Sprut schreibt auch dreimal 0x30 ins Instruction Register, habe mich immer gewundert warum

Zitat :

Normalerweise sehe das so aus: - Port auf Eingang stellen - Instruction Register anwählen - Edit: Read-Write auf Read stellen! - E setzen, solange E high ist, steht Busyflag zur Verfügung - Warten, bis Busyflag low wird - E löschen - Port auf Ausgang stellen

Ich mache es ähnlich, ich lese das Busybit in das Register "Daten" und prüfe es dort. Wenn es high ist, geht er in die kurze Warteschleife und versucht es nochmal. Werde die Routine aber heute Abend umschreiben, heute Mittag bin ich bei meiner Mutter.

_________________
Fnord ist die Quelle aller Nullbits in deinem Computer.
Fnord ist die Angst, die Erleichterung, und ist die Angst.
Fnord schläft nie.

Moin,

I.d.R. liegt der Fehler im Detail. Wie gesagt, sowas kann passieren, wenn man "gekonnt" das Busyflag überließt.

Viel Spaß bei deiner Mutter,
und das Display wird noch .



Grüße

Edit:
Ich beziehe mich hierauf:
;Busy-Bit abfragen
BLCD
call warten
BusyLCD
bsf STATUS,RP0 ;Bank 1
comf TRISB,1 ;alles input
bcf STATUS,RP0 ;wieder bank 0
BCF RS ;Statusregister
BSF RW ;lesen
BSF Enable ;Interface ein
nop
nop
MOVFW PORTB
MOVWF Daten ;Nach Daten lesen
BCF Enable ;Interface aus
nop
bsf STATUS,RP0 ;Bank1
clrf TRISB ;alles output
bcf STATUS,RP0 ;bank0
btfsc Daten,7 ;Busy gesetzt?
goto BLCD ;ja, nochmal prüfen
call warten
return

Das find ich zumindest merkwürdig.
Ich würde erst alles auf Eingang setzen und solange auf Eingang lassen, bis das Busyflag soweit ist.
Und jetzt, wo ich mit klaren Kopf das PÜrogramm lese, fällt mir auf, dass warten2 Absicht ist ...



_________________


[ Diese Nachricht wurde geändert von: DonComi am 12 Apr 2008 13:57 ]