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.
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 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 ?
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 ?
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 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 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.
