Hallo Kollegen, hat jemand schon mal das DEM240128D (Datenblatt im Anhang) verwendet? Ist ein 240 x 128 GLCD mit T6963C, recht preiswert bei Schukat für ca. 40 Euronen. Ich kann Zeichen darstellen, aber das letzte Drittel rechts, also die 80 Zeichen, die an dem letzten der drei Vertikaltreiber hängen, sind teils horizontal und vertikal um einige Pixel verschoben und mehrfach abgebildet. Habe eigene Routinen und zur Kontrolle die Lib's von Benedikt und Nico ausprobiert. Ergebnis immer gleich. uC ist ein ATMega16 11 MHz 5 Volt. Der nette Mann von Schukat hat mir erzählt, sie hätten das Display erst seit Januar im Programm, aber von den bisher verkauften 50 Stück gäbe es keinen Rückläufer.
Kannst du mal ein Foto von der fehlerhaften Ausgabe machen ? Verwendest du nur Text, ohne Grafik ?
Sieht interessant aus. Da der T6963 sowas eigentlich nicht kann, bleiben 2 Möglichkeiten: - Entweder entsteht das durch einen parasitären Effekt zufällig - Das Display hat irgendeinen Schaden Ich würde aber erstmal auf das erstere, also einen Softwarefehler tippen. Prüfe mal, ob du wirklich ausreichend Zeichen pro Zeile sendest, oder nicht doch zu wenige.
Zeichen bekommt das Display ausreichend - so sieht's aus, wenn ich an Pos. 22 in der ersten Zeile starte. Schaden glaub ich auch nicht, habe zwei Stück hier, beide verhalten sich gleich. Spannungen stimmen auch alle.
OK, starte mal noch ein paar Zeichen weiter rechts (irgendwo ab da, wo das Bild gestört ist). Da das ganze um eine Grafikzeile versetzt ist, sieht das für mich so aus, als würde der Bereich rechts die Daten der vorhergehenden Zeile eine Zeile später bekommen. Das würde den Versatz erklären.
der Fehler beginnt genau bei dem 161. Pixel einer Zeile. Ich glaube, das hat mit den Vertikaltreibern zu tun, da macht jeder 80 Pixel.
Der Dude wrote:
> Ich glaube, das hat mit den Vertikaltreibern zu tun, da macht jeder 80 Pixel.
Ja, 80 ist der übliche Wert. Da es aber bei beiden LCDs ist, und es bei
anderen zu gehen scheint, würde ich trotzdem auf einen Softwarefehler
tippen.
Zeig mal deine Initialisierungsroutine.
void DisplayOn(void) { unsigned int i; INIT_CONTROL_PINS(); //set WR,CE,RD,C/D to outputs WR_ON(); // CE_ON(); RD_ON(); _delay_ms(10); RES_OFF(); _delay_ms(10); RES_ON(); DATA(); DATA_DIR_OUT(); //DatenPort auf Ausgang zum schreiben for (i=0; i<0xFFFF; i++) asm volatile ("nop"); //Write text home address=0x0000 WriteData2(T_BASE,0x40); //Write graphic home address WriteData2(G_BASE,0x42); //Text area column set= Setze Textspalten // WriteData2(BYTES_PER_ROW,0x41); WriteData2(BYTES_PER_ROW,0x41); //Graphics area column set in Bytes !!! WriteData2(BYTES_PER_ROW,0x43); //set display mode = OR WriteCommand(0x84); //Text and graphic display !! WriteCommand(0x94); //9C WriteCommand(0xA7); ClearGScreen(G_BASE,G_END1); ClearScreen(); } Das ist die letzte Version, die ich ausprobiert habe (ist glaub ich original von Holger Klabunde). CE hab ich auskommentiert, weil das bei mir auf Masse liegt.
#define LCD_WIDTH 240 //Display Breite #define LCD_HEIGHT 128 //Display Höhe #define PIXPERBYTE_6 #define BYTES_PER_ROW LCD_WIDTH / PIXPERBYTE // how many bytes per row on screen #define DISPLAYBYTES BYTES_PER_ROW * LCD_HEIGHT // how many bytes for a screen
Passt eigentlich alles. Wenn die Befehle auch so im Display landen, wie sie hier stehen (wovon ich ausgehe, denn grundsätzlich läuft das LCD ja), dann müsste eigentlich alles funktionieren. Konkret weiterhelfen kann ich jetzt leider auch nicht. Ich würde mal versuchen die Zeilengröße zu ändern, und zu zu schauen was dann passiert. Was passiert z.B. wenn du die Zeilengröße auf 156 setzt ?
Hab ich schon alles ausprobiert...Ergebnis immer gleich... danke jedenfalls für Deine Mühe. Da steht mir noch ein langer Abend bevor.
Wie hast du G_BASE definiert ? Bei 240x128 und 6x8 Font reicht 0x200 nicht mehr. Besser so machen: #define G_BASE 0x0400 // base address of first screen 240x128 ?
Hallo Holger, würde das schon die erste Zeile killen? #define G_BASE 0x0400 bringt das gleiche Ergebnis.
>würde das schon die erste Zeile killen?
Nö, eigentlich nicht. Erst im unteren Bereich.
Kannst du nicht mal dein komplettes Testprogramm posten ?
Sicher - ich schick mal die letzte Version, die ich ausprobiert hab, das war die von Dir (falls Du der Holger bist). Die mirror-funktion hab ich eingebaut, weil die Portpins layoutmässig bei mir andersrum dranhängen.
Hmm, also bei mir funktioniert dein Programm. Ist aber nur ein 240x64 Display. Reset Pin ist bei mir auch anders angeschlossen. Änder das mal so: RES_OFF(); _delay_ms(10); RES_ON(); _delay_ms(10);
Ok. Hab ich grad gemacht. Leider ohne Erfolg. Es erhärtet sich der Verdacht, dass mit den Displays was nicht stimmt. Wenn ich nicht weiterkomme, werde ich den Krempel zurückschicken. Vielen Dank an alle.
>Es erhärtet sich der Verdacht, dass mit den Displays was nicht stimmt. >Wenn ich nicht weiterkomme, werde ich den Krempel zurückschicken. Was für ein Resonator klebt bei dir auf dem Display ? Meins hat einen 6MHz Resonator. Laut Datenblatt scheint deins einen 3MHz Takt zu haben. Evtl. musst du bei den Zeiten noch was drauflegen. Du hast da auch einige NOPs in meinem Code entfernt ;)
1040F5663 steht auf dem Quarz. Messen kann ich nicht, weil ich nicht rankomm im Betrieb. Hab aber mal meinen ATMega auf 1 MHz int RC gefused. Ergebnis ist das gleiche. Die Zeiten, die im Datenblatt angegeben sind, halte ich locker ein.
>Du hast da auch einige NOPs in meinem Code entfernt ;) Upps ! Hast du nicht. Der Code ist von 2003 ;) >Hab aber mal meinen ATMega auf 1 MHz int RC gefused. Ergebnis ist das >gleiche. Das sollte allerdings gehen.
Der Dude wrote: > 1040F5663 steht auf dem Quarz. Messen kann ich nicht, weil ich nicht > rankomm im Betrieb. Laut Datenblatt wäre für dieses Displays (M=32, N=16) ein Quarz von 3,932MHz optimal. 3MHz ist also ok. Wie gesagt: Ich erkläre mir das so, dass der rechte Teil die Pixeldaten eine Zeile verspätet erhält, warum auch immer.
Wenn ich richtig gezählt habe, ist der horizontale Versatz alle 32 Pixel ab dem 160. Jetzt müsste man das LCD genauer kennen, um zu wissen wieviele Treiber ICs verbaut sind: Dann kan man sagen ob jedes IC zufällig 32 Pixel ansteuern.
>Dann kan man sagen ob jedes IC >zufällig 32 Pixel ansteuern. Der T6963 steuert alle Pixel. Wenn es zu einem Versatz kommt muss das Layout des Displays komplett Schrott sein. Oder irgendwo in der Software wird die Basisadresse des Displays unkontrolliert verschoben oder der RAM Inhalt verändert. Das gepostete Testprogramm hat mit den Bildern oben nicht viel zu tun. Der Text beginnt mit Großbuchstaben. Die sehe ich in den Bildern nicht.
holger wrote: >>Dann kan man sagen ob jedes IC >>zufällig 32 Pixel ansteuern. > > Der T6963 steuert alle Pixel. Das ist schon klar. Daher schrieb ich ja auch Treiber ICs > Wenn es zu einem Versatz kommt muss das Layout des Displays komplett Schrott sein. Ist äußerst unwarscheinlich. Wobei ich sowas auch schon gesehen habe, allerdings nicht bei einem Serienreifen Display. > Oder irgendwo in der Software wird die Basisadresse > des Displays unkontrolliert verschoben oder der RAM Inhalt verändert. Könnte sein, aber man kann beim T6963 Buchstaben nicht Pixelgenau positionieren, sondern nur in Buchstabenschritten, also 6x8. Von daher kann es eigentlich nicht direkt am T6963 liegen. Außer eben der T6963 gibt zu wenige Pixel aus, bzw. setzt das LP Signal falsch, so dass der restliche Teil der Zeile die Daten erst eine Zeile später bekommt.
>Das gepostete Testprogramm hat mit den Bildern oben >nicht viel zu tun. Der Text beginnt mit Großbuchstaben. >Die sehe ich in den Bildern nicht. Anbei der Bildschirm zum Programm. Der vertikale Versatz wundert mich am allermeisten. Der 6963 kann doch gar nicht vertikal shiften?
Wenn ich das richtig sehe: - 160 Pixel normal - 16 Pixel um 2 nach unten versetzt, beginnt 16 Pixel später, da wo die 160 aufhören - 32 Pixel um 1 nach unten versetzt, beginnt ab da wo die 160 aufhören - 32 Pixel, beginnt ab da wo die 160 aufhören Das verstärkt meine Theorie, dass aus irgendeinem Grund zu wenige Pixel ausgegeben werden. Sieht für mich so aus, als wenn 32 Pixel zu wenig ausgegeben werden. Mach mal den Wert in der Software um 32 größer, setze also die Displaygröße auf 256.
@ Der Dude Danke für das neue Bild ! Das sieht jetzt so aus wie bei mir. Bis auf den ganz rechten Teil. Die Buchstaben werden teilweise doppelt ausgegeben und sind horizontal verschoben. Benedikt hat schon recht: Das geht eigentlich gar nicht im Textmodus. Das Display muss ne Macke haben.
Jetzt hab ich was gefunden. Der Font Select war auf High. Wenn ich den auf Low stelle, sieht's so aus.
aber das ist doch falsch, oder? FS=1 bedeutet 6x8 Pixel, 0 bedeutet 8x8 Pixel.
Jetzt hast du den 8x8 Font ausgewählt, sendest also mehr Pixel an das LCD, da eine Zeile länger wird. Dann ist das genau das was ich die ganze Zeit schreibe: Du sendest zu wenige Daten an das LCD.
Ich sende glaube ich nicht zu wenige Zeichen. Die kommen ja alle an, nur an der falschen Stelle.
Du siehst aber: Bei 8 Pixel Zeichenbreite passt es, bei 6 nicht. Ich bin mir zu 99% sicher, dass es daran liegt.
Ich kann aber die text home address beliebig verschieben, der Text wandert dann mit, wird aber immer an der gleichen Stelle falsch angezeigt. Ich glaube, die Displays haben einen systematischen Bug, der bisher nur noch niemandem aufgefallen ist. Die haben ja erst 50 Stück verkauft und das erst seit Januar.
>Du siehst aber: Bei 8 Pixel Zeichenbreite passt es, bei 6 nicht. Ich bin >mir zu 99% sicher, dass es daran liegt. Merkwürdig. Ich kann machen was ich will. FS falsch stecken für 6x8 oder 8x8 Font. Programm compilieren für 8x8 und 6x8 und FS jeweils falsch anschliessen, aber den vertikalen Versatz sehe ich auf meinem Display nicht. Ich glaub ich muss mir mal ein 240x128 Display besorgen.
>Siehst Du denn einen horizontalen Versatz?
Nein, wird zwar teilweise falsch angezeigt, aber das liegt dann
am falsch eingestellten FS Pin.
Pixelweise verschoben sind meine Texte jedenfalls nicht.
Kann zwar nur für reinen Grafik-Modus sprechen, aber ein ähnliches Phänomen habe ich auch. Ich verwende ein YL#24012-70. Dieses 240x128 GLCD zeigt einen Versatz von einem Byte nach rechts an. Es möchte unbedingt mit der normalen Grafik-Startadresse minus 2 initialisiert werden, dann klappt alles. Das Verhalten tritt auch mit Beispielen aus der Codesammlung in diesem Forum auf. Ich habe mal zum Test andere GLCDs an die gleiche HW/SW angeschlossen. Keine Probleme. Falsche Verdrahtung / SW Bugs sind also ausgeschlossen. Das ist eine Sache wo ich mir keinen Reim drauf machen kann, da sind LCD-Experten gefragt. (Benedikt?) Torsten
Torsten S. wrote: > Ich verwende ein YL#24012-70. Dieses 240x128 GLCD zeigt einen Versatz > von einem Byte nach rechts an. Es möchte unbedingt mit der normalen > Grafik-Startadresse minus 2 initialisiert werden, dann klappt alles. Das kann eigentlich von der Logik her garnicht sein (außer der T6963 hätte einen Bug). Denn wie Grafikstartadresse schon aussagt, ist das nicht viel mehr als nur eine Adresse ab der die Daten ausgegeben werden. Bist du sicher, dass es nicht die Zeilenbreite war, die auf 2 größer gesetz werden musste ? Wie bereits gesagt, ich bleibe bei meiner Behauptung, dass das LCD zu wenige Daten bekommt. Und es hängt natürlich vom LCD ab, wie die Spaltentreiber darauf reagieren wenn zu wenige Daten ankommen.
Hey Leute, ich habe die Gaudi mittlerweile beim Hersteller reklamiert. Hie die Antwort aus Fernost: Display Abnormity Analysis: For driving IC, Pins MD2 and MD3 are used to define the number of characters per row, MD2 1 0 1 0 MD3 1 1 0 0 Columns 32 40 64 80 The module size is 240X128, 30 characters are shown per row if 8X8 character is used; and 40 characters are shown per row if 6X8 character is used. MD2=1 and MD3=1 is set for the module, only 32 characters can be displayed per row. Therefore, 8X8 character type can be displayed normally, but the display is abnormal for 6X8 character type. Solution: 1. Only 8X8 character type can be used for this design. 2. Change the PCB wiring and use MD2=0 and MD3=1 for display 40 characters per row. Both 8X8 and 6X8 character type can be display normally. Noch geiler geht's doch gar nicht, oder was meint Ihr?
Die Antwort ist sehr gut und vor allem ehrlich. Die gestehen da nen echten DesignBug ein, denn kein Mensch würde heutzutage darauf kommen nur 32 statt der möglichen 40 Zeichen fest zu verdrahten. Ich würde die Pins hoch biegen und entsprechend umverdrahten mit Lackdraht und das Problem ist gelöst. Das steht übrigens auch im Datenblatt des T6963C. Es gibt ne Sektion darüber, wie man diese Pins beschalten muss wenn man ein neues Design anfertigt.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.