Ich steuere mit einem ATMEGA8515 einen EPSON S1D13005 LCD Controller mit Hitachi SP14Q002 LCD Display an. C Quellcode und Datenblatt ist im Anhang. Ich habe damit das Phänomen, dass alles, was ich in die obere hälfte des Displays schreibe, auch in der unteren Hälfte auftaucht. Im Textmodus habe ich 30 Zeilen (240 Zeilen/8 Pix Zeichenhöhe). Alles, was ich in Zeile 1 hinein schreibe, ist auch in Zeile 16 zu sehen. Alles, was ich in Zeile 4 hinein schreibe, ist auch in Zeile 19 zu sehen. Wenn ich in Zeile 20 was hinein schreibe, ist es einfach nicht zu sehen. Wenn ich im Grafikmodus oben ein Kästchen hinzeichne, dann ist dieser auch in der hunteren Hälfte gezeichnet. Wenn ich in die untere Hälfte was hinein zeichne, ist es ebenfalls nicht mehr zu sehen. Wie kann man sich das Phänomen erklären? Zunächst dachte ich, dass einer der Bits am Datenbus zum Controller eine Unterbrechung haben könnte, aber es kommen wirklich alle 8 Datenleitungen an. Die Pixelangaben und initialisierungsroutine scheint auch zu stimmen, soweit ich das mit dem Datenblatt vergleichen kann.
> Wie kann man sich das Phänomen erklären?
der Sekt gestern abend war schlecht, und nun hast du Lesefehler und
siehst alles doppelt
Der Sekt ist schon abgeklungen, aber ich sehe immer noch alles doppelt :c)
Gast
#1537750
Ich hebe keine Lust das Datenblatt zu lesen (schei... Sauferei), aber kann es sein, dass das Display zwei Controller mit zwei CS-Leitungen hat, die du separat ansteuern solltest?
Gast
#1537757
Sieh Dir im Datenblatt im Abschnitt 8.x mal die Initialisierungen an und prüfe, ob Du alles richtig eingestellt hast, insbesondere die Zeilenzahl TC/R und L/F. Der Controller weiß ja in der Regel nicht, wie viele Pixel das angeschlossene Display besitzt.
Stell mal den Schaltplan rein. Woher hast du das display? Steuerst du`s im 4-oder 8Bitmodus an?
Aaaaalso schaltplan gibts keinen, ich habe das Zeug vielen Jahren in der Schublade. Damals hat das Display mit LCDHYPE auf einem Parallelport funktioniert. Nun verwende ich einen Atmega8515, der auf einem STK500 sitzt, und mit einzelnen drähten angesteckt ist. Hier ein paar Bilder. Die Pinbelegung habe ich aus der 1335.h entnommen, das CS signal habe ich testweise auf LOW geleht, funktioniert aber auch, wenn ich die auf WR lege. Es ist eine 8-Bit Verdrahtung, der Controller lässt ja keine 4-Bit Initialisierung zu. Die Anzahl der Pixel stimmen ebenfalls in der 1335.h ich habe auch mal mit allen Werten der Init Routine herum gespielt. tut mir leid, eine Datei ist zwei mal angehängt. Das Forum bietet keine Möglichkeit es zu löschen...
Angehängte Dateien:
-
controller.gif
(230 KB)
-
display.gif
(160 KB)
Hat schon jemand ein Projekt mit dem Controller und dem LCD Zusammen gehabt? Ich würde gerne mal die Initialisierungsroutine vergleichen...
Gast
#1538233
Schon versucht die Initialisierung zu ändern? 1335.c lcd_write_command(0x40); lcd_write_data(0x38); lcd_write_data(0x87); lcd_write_data(0x07); lcd_write_data((LCD_X_SIZE/8)-1); lcd_write_data((LCD_XTAL 70 LCD_Y_SIZE) / 9); lcd_write_data(LCD_Y_SIZE - 1); lcd_write_data(LCD_X_SIZE/8); ändern zu lcd_write_command(0x40); lcd_write_data(0x30); // Single-Panel drive siehe 8.2.1.5 lcd_write_data(0x87); lcd_write_data(0x07); lcd_write_data((LCD_X_SIZE/8)-1); lcd_write_data((LCD_XTAL 70 LCD_Y_SIZE) / 9); lcd_write_data(LCD_Y_SIZE - 1); lcd_write_data(LCD_X_SIZE/8); Ungetestet, nur kurz ins Datenblatt geschaut.
Ja, habe ich, dann bleibt das Display komplett leer.
Also ich gehe langsam von einem Defekt des Controllers aus...
Die Delay-Routinen sind für 8Mhz geschrieben. Ist das auch Dein Takt?
Mit 8MHz bekomme ich auch kein Bild zustande. Ich habe alle Frequenzen durchprobiert und habe memerkt, dass ich mit 1MHz zumindest diesen text darstellen kann. Bei 2MHz ist auch schon kein Bild mehr zu sehen. Ich tausche die Delay Routinen mal gegen _delay_ms() aus... Mal sehen was dann passiert...
Leider nein. _delay_ms(2); hat auch nichts gebracht...
@ Igor Ebner (anfaenger69) >_delay_ms(2); >hat auch nichts gebracht... Deine real im Controller verwendete Taktfrequenz muss natürlich mit deiner Angabe im Quelltext übereinstimmen.
1 | |
Und vorsicht! Wenn im Makefile oder im AVR-Studio unter den Projektoptionen schon eine Zahl eingetragen ist, wird DIESE DORT stillschweigend benutzt, egal was du im Quelltext hinschreibst! MFG Falk
Ja, das habe ich mit berücksichtigt. Ich habe nun bei lcd_write_command() angefangen Delays hinzuzufügen. Jetzt habe ich das Bild auch bei 8MHz. Aber auch wieder doppelt :c) Ich denke es ist kein Timing Fehler im Programm, sondern dass er nicht genug Speicher hat, um vollen Inhalt darzustellen, wenn der Speicher für die zweite Hälfte überläuft, beginnt er ja wieder bei 0. Ich versuche gerade am Detenblatt herauszufinden, ob der externe Speicher nur für Zeichensätze brauchbar ist, oder auch für den Grafikspeicher.
Hat keiner vor Euch so ein Display herum liegen?
So, Fehler gefunden (bzw zwei Fehler): Jetzt habe ich doch jemanden gefunden, der das Display benutzt hat. Da habe ich glatt mal die Initialisierungsroutine verglichen. Wie DRJ es schon festgestellt hat, ist das Byte 0x38 in der Initialisierungsrouine falsch. Sein Wert 0x30 war richtig. Dazu kommt jedoch ein zweiter Fehler, dass dann das Bild komplett verschwindet, wie ich es danach beschrieben habe. Tja, was soll ich sagen. Ich habe mal mit dem Wert 0x30 weiter probiert und kaum hat abends die Tischlampe drauf geleuchtet, hat man den richtigen Bildschirminhalt leicht erkennen können. Also lag es an der Kontrasteinstellung. Dabei hatte ich ihn soooooo genau eingestellt, wie auf meinen Fotos zu sehen. Beim 0x30 braucht er halt eine komplett andere Kontrasteinstellung. Die 8 in der 0x38 bewirkt eine Einstellung "W/S" (Single Panel Drive und Dual Panel Drive). Das Datenblatt des Displays beschreibt in der Hinsicht gar nichts, Treiber ICs sind 3 Stück waagerecht und 3 Stück senkrecht zu sehen. Trotzdem muss der Wert W/S auf 0 stehen für Single Panel bei diesem Display. Nochmals danke an alle, die sich die Mühe gemacht haben den Fehler zu erkennen :c)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.