mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Display mit T963C


Autor: Der Dude (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du mal ein Foto von der fehlerhaften Ausgabe machen ?
Verwendest du nur Text, ohne Grafik ?

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur Text. Foto kommt gleich.

Autor: Der Dude (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier kommt das Bild.

Mit Grafik ist es das Gleiche.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Dude (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Dude (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
der Fehler beginnt genau bei dem 161. Pixel einer Zeile. Ich glaube, das 
hat mit den Vertikaltreibern zu tun, da macht jeder 80 Pixel.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das eigentlich interessante fehlt: Was für einen Wert hat BYTES_PER_ROW 
?

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#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

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#define PIXPERBYTE    6    heisst es natürlich....

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich schon alles ausprobiert...Ergebnis immer gleich...

danke jedenfalls für Deine Mühe. Da steht mir noch ein langer Abend 
bevor.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Holger,

würde das schon die erste Zeile killen?

#define G_BASE  0x0400         bringt das gleiche Ergebnis.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>würde das schon die erste Zeile killen?

Nö, eigentlich nicht. Erst im unteren Bereich.
Kannst du nicht mal dein komplettes Testprogramm posten ?

Autor: Der Dude (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Dude (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
die .c datei

Autor: Der Dude (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
und die .h

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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);

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ;)

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das erklärt aber nicht den horizontalen Versatz.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Dude (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>und sind horizontal verschoben.

Quatsch, vertikal natürlich :(

Autor: Der Dude (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt hab ich was gefunden.

Der Font Select war auf High. Wenn ich den auf Low stelle, sieht's so 
aus.

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber das ist doch falsch, oder? FS=1 bedeutet 6x8 Pixel, 0 bedeutet 8x8 
Pixel.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sende glaube ich nicht zu wenige Zeichen. Die kommen ja alle an, nur 
an der falschen Stelle.

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ausserdem funktioniert mein Programm ja bei Holger's Display?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du siehst aber: Bei 8 Pixel Zeichenbreite passt es, bei 6 nicht. Ich bin 
mir zu 99% sicher, dass es daran liegt.

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Der Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Siehst Du denn einen horizontalen Versatz?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Torsten S. (tse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Timo Birnschein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.