Hallo Marco,
Die Anschlüsse stimmen, sonst würdest du gar nichts sehen.
Es kann sein, dass deine Drähte zu lang sind ?
Das kann man auf dem Foto nicht sehen.
Bei mir sind es max. 10cm vom Display zum Controller.
Druckbare Version
Hallo Marco,
Die Anschlüsse stimmen, sonst würdest du gar nichts sehen.
Es kann sein, dass deine Drähte zu lang sind ?
Das kann man auf dem Foto nicht sehen.
Bei mir sind es max. 10cm vom Display zum Controller.
also bei mir können es schon so 20-25cm sein.
Daran kann das schon liegen?
Aber wenn ich das doch mit der beiligenden Platine am Parallelport anshcliße kann das kabel doch auch 2m oder so lang sein
Ist nur eine Vermutung, aber das könnte schon zu lang sein.Zitat:
also bei mir können es schon so 20-25cm sein.
Daran kann das schon liegen?
Das ist auch etwas ganz anderes. Dort ist das Kabel geschirmt und der Schirm ist mit der Masse vom Computer verbunden.Zitat:
Aber wenn ich das doch mit der beiligenden Platine am Parallelport anshcliße kann das kabel doch auch 2m oder so lang sein
Mit frei liegenden Drähten würde das über 2m auch nicht funktionieren.
Ja dann werde ich das morgen mal testen. Danke schonmal für den Tip.
Gibts eigentlich auch ne möglichkeit das Display zu invertieren?
Mit dem Kontrast werde ich mirgen nochmal rumspielen.
Ciao Marco
ist die gleiche Vorgehensweise, wie beim Kontrast.Zitat:
Gibts eigentlich auch ne möglichkeit das Display zu invertieren?
Den Befehl dafür hab ich jetzt nicht im Kopf, steht aber im Datenblatt.
So, die Drähte sind gekürzt,
allerdings immer noch das gleiche Problem.
Echt komisch.
Werde es morgen nochmal wie duz machen und die Dräte driekt an das Display löten.
Habe es jetzt noch so, das ich die Drähte an der Ansteuerplatzine für den Parallelport abgreife, allerdings vor den Widerständen usw.
Aber vielleicht liegts ja da dran!
Ciao Marco
Hallo,
ich habe ein ähnliches Problem wie Marco.
Mein µC ist ein 16MHz atmega128 und ich versuche damit ein HP12542R-DYO anzusteuern, habe bisher ein paar Routinen zur Ansteuerung und einen Charactergenerator in Assembler geschrieben und das funzt auch eigentlich ganz gut, bis auf eine Ausnahme: wenn 0x7f oder 0xff gesendet wird, bekomme ich zwischen dem 0x7f und dem folgenden Zeichen ein
scheinbar willkürliches Bitmuster (meistens 0xff). Ich habe alle mir sinnvoll erscheinenden Reihenfolgen für die Steuerleitungen getestet,sieht aus als wäre das völlig egal, solange die Daten anliegen und dann eine negative Flanke von EN kommt. ??? Auch Delays von einem NOP bis zig µS zeigen keine Wirkung. Laut Datenblatt muß das Teil ja auch ohne jegliche Verzögerung auskommen. (mit einem Testprog. auf dem PC tritt dieses Phänomem nur sehr selten auf.)
Hat jemand etwas ähnliches beobachtet und eine Lösung gefunden?
Gruß Achim
Hallo Achim,
ich fürchte, du musst dein Problem schon etwas genauer beschreiben.
Mit dieser Beschreibung kann ich nichts anfangen.Zitat:
... einen Charactergenerator in Assembler geschrieben und das funzt auch eigentlich ganz gut, bis auf eine Ausnahme: wenn 0x7f oder 0xff gesendet wird, bekomme ich zwischen dem 0x7f und dem folgenden Zeichen ein
scheinbar willkürliches Bitmuster (meistens 0xff).
Etwas Quellcode wäre auch sehr hilfreich.
Hallo albundy,
erst mal Danke für die schnelle Antwort.
Mit unten stehender Routine lassen sich mit und ohne delay
alle Bitmuster problemlos ausgeben bis auf 0x7f bzw. 0xff völlig unabhängig von dem Programmteil welches die Zeichen erzeugt.
folgender Code erzeugt das Phänomen:
ldi r16,0x7f
call dtaout
ldi r16, beliebiger Wert
call dtaout
loop:rjmp loop
dtaout: ;send r16 to display as databyte
sbi porte,d_dta ;set A0 pin high (cmd)
; call delay
cbi porte,d_ncs ;set /CS pin low
; call delay
sbi porte,d_en ;enable pin high
; call delay
out portb,r16 ;send data
; call delay
cbi porte,d_en ;enable pin liw
; call delay
sbi porte,d_ncs ;set /CS pin high
ret
;Display Initialisierungsfolge wird übertragen wie Daten nur halt mit A0 low
init: .db 0x40,0xA0,0xA3,0xC0,0x2F,0x20,0xAC,0x81,0x20,0xA4, 0xAF,0xA6
Ich hoffe Du kannst damit etwas mehr anfangen. Übrigen habe ich auch mit
einem zweiten Display getestet mit gleichem Resultat.
Möglicherweise ist auch einfach nur mein Verbindunskabel zu lang, ca. 40cm Flachbandkabel (IDE) .
Gruß
Achim
Hallo Achim,
laut Datenblatt müssen die Daten min. 30ns anliegen, bevor EN von High auf Low geht. Ich würde "out portb,r16" als erstes in "dtaout:" ausführen lassen, dann kannst du die delay's weglassen.Zitat:
sbi porte,d_en ;enable pin high
; call delay
out portb,r16 ;send data
; call delay
cbi porte,d_en ;enable pin liw
Aber das ist sicher nicht die Ursache.
Ich denke nicht, das es mit den Bytes $7F bzw. $FF zusammenhängt, da es sonst auch mit Kombinationen wie $7E oder $FE Probleme geben müsste.Zitat:
... bis auf 0x7f bzw. 0xff völlig unabhängig von dem Programmteil welches die Zeichen erzeugt.
Bei einem Flachbandkabel von 40cm Länge würde ich schon eher die Ursache suchen. Zumal das Übersprechen bei dieser Länge doch schon erheblich sein dürfte. Liegt eventuell die Ader für EN im Kabel neben einer Datenader ?