Grafik LCD, 128*64, T6963C, Pollin, 7.95 EUR

Ich hab jetzt mal eins bestellt. Bin ich ja mal gespannt.

Werner

Man könnte neidisch werden bei den Bildern

Ich habe meins naja auseinander gerupft ..aber ich warte erstmal auf mein PSone TFT

I30R6

Zitat

Original von I30R6
Man könnte neidisch werden bei den Bildern

Ich habe meins naja auseinander gerupft ..aber ich warte erstmal auf mein PSone TFT

I30R6

Ja, habe gelesen, dass Du dir eins bestellen wolltest, das wollte ich auch. TFT ist ja der Mercedes.

Aber RESPEKT
für Entwicker des lowcost Displays.

Mal sehen, ob auch ich das Teil zum laufen bekommen werde

Super Arbeit!!

Gruß
Daniel256

Hallo !

Zitat

Aber RESPEKT
für Entwicker des lowcost Displays.

Mal sehen, ob auch ich das Teil zum laufen bekommen werde

Dem Respekt lann ich mich auch nur anschließen ! (schleim...)
Nee, wirklich. Teuer kaufen kann jeder, aber LowCost mit Handarbeit für andere finde ich klasse, wenngleich ich mich wegen mangelnder Kentnisse noch nicht einbringen konnte.
Ich würde gerne beim Testen mit meinem LINVDR0.7 helfen !
Klappt es schon ?

Gruß, Pappnase

Hallo, gibt es das Display und die Ansteuerplatine bei Pollin noch ich finde nichts ?

Zitat

Original von hhh
Hallo, gibt es das Display und die Ansteuerplatine bei Pollin noch ich finde nichts ?

Display: Best.Nr. 120 292
Platine: Best. Nr. 120 297

Also, ich würde auch mit Linvdr0.7 testen

Gruß
Daniel256

Hat Pollin, auch andere mit blauer Hintergrundbeleuchtung?

Zitat

Original von DrSat
Hallo Torsten,

bei mir ist es wohl auch zweiteres. Ich habe mir einmal alle Zeichen auf dem Display angeschaut und mir ist aufgefallen, dass in X-Richtung immer zwei benachbarte Pixel aufleuchten, nie eins alleine oder gar eine Kette mit ungerader Anzahl. In Y-Richtung sieht das schon anders aus.

Mit -X 64 und abgeschaltetem Logo kann man das Plugin aber schon ganz gut verwenden. Ich habe mal ein Bild beigefügt

Vielen Dank schon einmal für diese ausgezeichnete Arbeit!

Gruß,

DrSat

Alles anzeigen

Hallo DrSat,
ich hab' im Netz noch einen Tip gefunden: Schau doch mal nach, ob im BIOS der Parallelport Deines VDR auf SPP oder EPP bzw. ECP/EPP konfiguriert ist. Bei EPP werden die Pins angeblich als Open Collector mit Pullup konfiguriert, bei SPP als "echte" TTL. Bei mir hat's geholfen (s. Bild). Ganz perfekt ist es immer noch nicht, sporadisch verdoppelt's jetzt noch mal 'ne einzelne Spalte (ist schön im angehängten Bild zu sehen). Mit der Timing-Einstellung im Plugin mußt Du allerdings etwas spielen (bei mir geht's so ab +7 aufwärts).

Meines Erachtens sind hier tatsächlich Pegelprobleme verantwortlich - die Erklärung im Netz (übrigens hier: http://www.mikrocontroller.net/forum/read-1-233662.html zu finden) erscheint dabei plausibel. Und: Es haben auch einige Leute von Problemen mit der Windows-Software von Pollin berichtet.

Hallo Torsten,

auch bei mir kommt es jetzt nicht mehr zur Doppelung der Pixel, allerdings werden einige Zeilen meistens ein wenig nach rechts versetzt dargestellt. Da mache ich mir im Moment aber noch keinen Kopf drum, da ich vermute, dass es am Mainboard liegt und ich ohnehin in den kommenden Tagen zu einem anderen wechseln wollte.
Vielen Dank für den Tipp!
Gruß,

DrSat

hallo thorsten und DrSat,

habt ihr eure displays mit einem verlängerungskabel oder direkt an den druckerport
angeschlossen?

bei mir habe ich festgestellt, wenn ich das display direkt per gender changer
an den druckerport anschliesse, dann tritt dieser zeilenversatz nie auf.

wenn ich per flachbandkabel ca 30cm das display anschliesse, dann habe ich im
unteren bereich den zeilenversatz.

schliesse ich das display per 1m druckerverlängerungskabel an, dann habe ich
im oberen und unteren bereich einen zeilenversatz.

falls möglich, könnt ihr das bei euch mal checken?!?!

gruss cypher_head

Hallo cypher_head,

ich habe das Display mit einem Druckerverlängerungskabel (2m) angeschlossen und beobachte die Störungen auch eher im ganzen Bildbereich. Auch nach einer Kürzung auf 0.9 m hat sich daran wenig getan. Allerdings hatte ich das Display mit dem selben (langen) Kabel an meinem Windows-Rechner ohne jegliche Störungen am laufen, weswegen ich nicht so recht daran glauben möchte, dass es nur am Kabel liegt. Merkwürdige Sache...
Im Mikrocontroller.net-Froum wird ein anderer Verursacher diskutiert:
http://www.mikrocontroller.net…read-1-233662.html#239592
Hat jemand eine Idee, wie man den Wert "32" in das Register 0x77A bekommt?

Gruß,

DrSat

glcd ist halt einfach die langlaeufige 'bezeichnung' fuer graphical display (als unterscheidung zu den alphanumerischen displays a la hd44780). scheint sich so eingebuergert zu haben.

@ronnykornexl
compileprobleme mir bitte melden.
ich teste unter linux distris: rh9, fc2-4, solaris10, freebsd.
die ueblichen compileprobleme bei anderen dists ergaben sich durch eine fehlende libgd (in der neuen version wird dies mittels autoconf beruecksichtigt und sollte dann keine fehler mehr liefern (aber auch ein programm weniger erzeugen ;-))

zur ansteuerung: ich habe mir eigentlich nie grosse gedanken ueber SPP/ECP/EPP gemacht da das in diesem anwendungsgebiet nicht wirklich zum zug kommt (wollte die ansteuerung des nokia3510i-displays beschleunigen und habe mich entsprechend eingelesen (n3510i: farbdisplay -> um einiges hoeheres datenaufkommen), da bei der displayansteuerung die ganzen signals direkt gesetzt werden (ob ueber outp oder ioctl-calls) war es ziemlich egal ob ich auf SPP oder ECP geschalten habe). das einzige wo es imho relevant ist: bei displays mit status readback (da muessen die data-bits (D0-D7) dann bei einigen (zb t6963) bi-direktional sein.
sollte ich da falsch liegen: mir bitte sagen vielleicht bekomme ich die farbdisplays ueber normalen parport ohne zusaetzliche hw doch noch schneller hin ...

zur signalqualitaet: habe schon horrorgeschichten gehoert ueber zu lange kabel, dieses und jenes (besonders bei sed1335-based displays): ich habe meine displays tw. ueber 2-3 m lange kabel angebunden oder ueber experimentierboards: keine probleme.
die geschilderten probleme ergeben sich meiner meinung erst in verbindung mit fehlerhaftem/schlechtem timing, besonders in verbindung mit direct-IO (und/oder schlechter abfolge der signalnachbildung)

versuche einfach, wenn du mit direct-IO arbeitest, delays zwischen den einzelnen outp() auf den port zu machen (meist bewirkt ein simples gettimeofday(&tv, 0); wunder)

genereller tip: nie einen beispielcode in diesem bereich als non-plus-ultra ansehen ..

/wastl

Zitat

Original von cypher_head
hallo thorsten und DrSat,

habt ihr eure displays mit einem verlängerungskabel oder direkt an den druckerport
angeschlossen?

bei mir habe ich festgestellt, wenn ich das display direkt per gender changer
an den druckerport anschliesse, dann tritt dieser zeilenversatz nie auf.

wenn ich per flachbandkabel ca 30cm das display anschliesse, dann habe ich im
unteren bereich den zeilenversatz.

schliesse ich das display per 1m druckerverlängerungskabel an, dann habe ich
im oberen und unteren bereich einen zeilenversatz.

falls möglich, könnt ihr das bei euch mal checken?!?!

gruss cypher_head

Alles anzeigen

Yep, hab ich. Interessant ist, daß GraphLCD eigentlich schon per IOCTL versucht, den Port auf SPP umzustellen. Anscheinend geht das bei meinem Pentium M Board aber nicht. Ich werde jedenfalls mal probieren, Pegel und Impedanz ein wenig besser anzupassen. Dann sollte es eigentlich fehlerfrei gehen.

wastl
Im GraphLCD sind sowieso Pausen zwischen den OUTs drin - wie lang, kannst Du über die Timing-Einstellung im Setup konfigurieren (Wert im Menü * 100ns). Leider hilft das nicht - daher denke ich, es ist tatsächlich ein Pegelproblem im ECP Modus.

Was den Modus angeht: Nach dem Posting in dem anderen Forum ist der Modus insofern sehr wichtig, weil die Ausgangsstufen rekonfiguriert werden, d. h. bei ECP arbeitet der Port eben mit OC + Pullup, im SPP-Modus mit einer TTL-kompatiblen Ausgangsstufe. Das ist für den L->H Wechsel sehr wichtig, weil es den Unterschied zwischen einigen 10ns und bis zu einigen us macht. Es geht hier also nicht darum, ob Du Daten zurücklesen mußt, sondern um Dinge wie Ausgangsimpedanz und Flankensteilheit.

Wenn ich mal Gelegenheit finde, werde ich mal ein Speicheroszi dranhängen und mir die Signale anschauen. Problem ist halt, daß es um meinen Produktiv-VDR geht - den kann ich daher nicht in die Firma schleppen

Gruß,
Torsten

torsten

thx fuer die erklaerung mit den pegelwechseln. _so_ habe ich das bis jetzt noch nicht gesehen ... (habe mir nur in verbindung mit uebertragungsgeschwindigkeit diesbez. gedanken gemacht)

sehe ich das richtig: da SPP vs. ECP fuer die geschwindigkeit in unserem fall ohnedies unerheblich ist (was auch meine zeitmessungen zu bestaetigen scheinen) koennte man bei displays, wo nicht status readback benoetigt wird, SPP per ioctl-call / registersetzen (bei directIO) 'forcen', um pegelprobleme bei laengeren kabeln zu vermeiden? (ev. mit weiterer option, die benutzerseitig veraendert werden kann)

/wastl

frage an die hyundai-display besitzer,

wenn ich das richtig in erinnerung habe (habe die datasheets irgendwohin kopiert):
die hintergrundbeleuchtung ist hard-wired und immer an?!

(mache grad die - hoffentlich - letzten feinschliffe fuer die neue version)

/wastl

Zitat

Original von wastl
...
sehe ich das richtig: da SPP vs. ECP fuer die geschwindigkeit in unserem fall ohnedies unerheblich ist (was auch meine zeitmessungen zu bestaetigen scheinen) koennte man bei displays, wo nicht status readback benoetigt wird, SPP per ioctl-call / registersetzen (bei directIO) 'forcen', um pegelprobleme bei laengeren kabeln zu vermeiden? (ev. mit weiterer option, die benutzerseitig veraendert werden kann)

/wastl

So verstehe ich das. Unglücklicherweise versucht das GraphLCD-Plugin nach meinem Verständnis der Sourcen schon die Umschaltung, bei meinem Pentium M Mainboard allerdings ohne Erfolg (ich *muß* im BIOS auf SPP umschalten). Könnte es sein, daß der von der c't genutzte Kernel (2.4.27) den betreffenden IOCTL noch nicht kennt?

Viele Grüße,
Torsten

Zitat

Original von wastl
frage an die hyundai-display besitzer,

wenn ich das richtig in erinnerung habe (habe die datasheets irgendwohin kopiert):
die hintergrundbeleuchtung ist hard-wired und immer an?!

(mache grad die - hoffentlich - letzten feinschliffe fuer die neue version)

/wastl

Alles anzeigen

Yep. Alle Outputs scheinen wohl belegt zu sein - die Platine schaltet sogar R/W fest auf low (nur Schreiben möglich).

Viele Grüße,
Torsten

Zitat

Original von torsten lang
Könnte es sein, daß der von der c't genutzte Kernel (2.4.27) den betreffenden IOCTL noch nicht kennt?

Unter Kernel 2.6.12 sieht es auch nicht anders aus. Erst nach manuellem Umschalten auf SPP im Bios ging das Display bei mir.

Gruß,
DrSat

Hi Leute,
jetzt muß ich doch auch mal meinen Senf dazugeben.

I30R6: eigentlich hätte man hier mal einen neuen Thread aufmachen können, da es sich um ein anderes Display handelt, die eigentlich nichts miteinander zu tun haben.

An die Admins: Kann man das nicht ab Seite 6 in einen neuen Thread schieben und umbenennen (Pollin 128x64 SED1565) ?

Nun zum Thema: Ich habe mir mal gleich zwei Displays bestellt und beide Platinen beim Einlöten dieser Flachbandkabelbuchsen verhunzt. Es sind Kurzschlüsse zwischen benachbarten Pins, die ich nicht mehr wegbekommen habe. Deshalb habe ich das Flachbandkabel am Display kurzerhand abgerissen (geht erstaunlich leicht) und Widerstände (150, 1/16W aus der Bastelkiste) direkt auf die Platine des Displays gelötet. Diese gehen dann auf eine 2 reihige Stiftleiste. Die Diode (Verpolungsschutz, verliert aber 0,6V -> Display wird dunkler) habe ich weggelassen. Den Stromversorgungsstecker (nebst Elko + C) und die Stiftleiste habe ich dann mit Heißkleber auf die Rückseite des Displays festgeklebt.
Unter Win und der Pollin SW funktioniert dies auch einwandfrei.
Nun zum VDR: Nachdem ich die SW von Torsten kompiliert und installiert habe, bekam ich Fehler beim Aufstarten wg. falscher Plugin Version. Da ich noch 1.2.6 laufen habe, bin ich einfach hergegangen und habe den Treiber von Torsten in das Plugin V 0.1.0 einkompiliert.
Das funktioniert soweit auch ganz gut (ohne Doppelpunkte ect).
Trotzdem mal eine Frage: Empfiehlt es sich, die neue Version zu nehmen ? Kann man die noch auf den VDR 1.2.6 anpassen ?
Probleme:
Wenn ich in die Plugin Einstellungen im OSD Änderungen vornehme, verhält sich der VDR instabil. Wenn ich danach boote, ist alles wieder ok.
Nach einiger Zeit ist im Display nichts mehr zu sehen. Die Anzeige ist weg und läßt sich auch durch Restart des VDRs nicht mehr zum Anzeigen bewegen. Erst ein reboot behebt das Problem.

Gruß
beagle