Hallo,
ich habe ein 240x128 Display mit T6963C-Controller angesteuert. Da ich
eine eigenen Schriftart verwende, kann ich den internen Zeichensatz
nicht verwenden. Die Schrift ist tlw. auch höher als 8 Zeilen. Um ein
Zeichen darzustellen, muss ich daher mehrere Adressen beschreiben (z.B.
2 untereinander). Damit die einzelnen Zeichen nicht immer erst bei den
nächsten 8 Bit einer Zeile beginnen, ver-odere ich die einzelnen
Zeichen. Die einzelnen Zeichen werden in einer Funktion beschrieben.
Damit das vorige Zeichen nicht tlw. gelöscht wird, lese ich zuert die
aktuelle Adresse aus, dann ver-odere ich dieses Datum mit den Daten des
aktuellen Zeichens und schreibe das Byte wieder raus.
Bisher funktioniert alles gut. Nun habe ich einen neuen
Display-Hersteller. Plötzlich flackert das Display, wenn ich das
aktuelle Datum auslese!!??!! Gebe ich diese Zeile weg, flackert es
nicht mehr, aber die Schrift ist auch nicht vollständig.
Hat vielleicht jemand eine Idee, woran das liegen könnte bzw. wie ich
mir abhelfen kann??
Das neue Display ist von Winstar (WG240128B).
Danke für eure Hilfe.
mfg
Andreas
1. Wie ist dein Code geschrieben bzgl. der Abfrage des Statusworts des
T6963C? Mit TimeOut oder richtige Abfrage vom Status?
2. Hat das Winstar einen kleineren RAM?
3. Sind die Konfigurationspins des T6963C richtig beschalten?
Ralf
Hallo Michael,
danke für deine Antwort, ich war die letzten Wochen auf Urlaub, deshalb
antworte ich etwas verspätet.
ad 1. Ich frage das Statusbyte ab, nicht mit Timeout
ad 2. das Winstar Display hat 8k RAM, das vorige Display 32k; aber ich
verwende nur den Grafikbereich, und der startet bei Adresse 0 => sollte
somit bei beiden Displays funktionieren (Auflösung 320 x 240).
ad 3. Die Konfigurationspins sind richtig beschaltet. Beide Displays
sind pinkompatibel (lt. Datenblatt).
Danke für die Hilfe
mfg Andreas
Wenn ich eins von den Displays bekomme, verrat ich dir, woran es liegt
grins
Nein, quatsch, ernsthaft: also wenn ich folgende Rechnung vornehme:
320 * 240 / 8 = 9600 komme ich auf die benötigte Anzahl der Bytes, die
nötig sind, um über den vollen Display-Bereich Grafik darzustellen.
Bist du sicher dass das neue Display nur 8kB hat? Das könnte nämlich
dann den Fehler erklären :-)
Ralf
Hi,
das dachte ich mir schon, dass es wohl nicht sein kann, dass
irgendjemand ein Grafikdisplay bastelt, dessen RAM nicht voll
ausreicht...
Okay, dann bleibt dir nur noch, hier mal den Code zu posten, vielleicht
kann man da was erkennen... Welchen Controller und welche
Programmiersprache verwendest du?
Ralf
>> LCD_GraphicXY
Könntest du die Funktion wenigstens in groben Zügen mal beschreiben?
Ich werd aus deinen Variablennamen nicht schlau...
Wenn ich weiss, was da passiert bzw. passieren soll, wirds einfacher
für mich...
Ralf
Das hilft nur bedingt. Ich brauch ne Beschreibung, was das Programm bzw.
einzelne Funktionen machen (sollen). Ich werd aus dem Code allein nicht
schlau. Jede gute Software ist dokumentiert.
Ralf
Hallo,
Doku ist sicher nicht schlecht, aber wie immer ist das, was am
wenigsten Priorität hat und auch bei diesem Projekt war so gut wie
keine Zeit dafür...
Prinzipieller Ablauf:
LCD_Init() => Initialisieren des Displays + IO-Leitungen
LCD_ClearDisplay() => Display-RAM löschen
LCD_GotoXY() => Position am Display setzen
LCD_PutStr() => String ausgeben mit eingestellter Schriftart (nicht die
eingebaute Schriftart, sondern selbst definierter Schriftsatz)
LCD_PutStr ruft LCD_PutChar() auf.
LCD_PutChar() => Ausgabe eines einzelnen Zeichens auf das Display. Das
Zeichen wird Zeile für Zeile je 8Bit ausgegeben. Ist das Zeichen z.B.
23 Pixel hoch, so wird die Schleife 23x durchlaufen. Pro Schreibzyklus
können nur 8 Bit in einer Zeile geschrieben werden. Ist das Zeichen
z.B. 11 Pixel breit, so muss man 2x schreiben, um eine Zeile des
Zeichens richtig anzuzeigen. Das erste Zeichen ist eigentlich kein
Problem. Schreibt man aber einen String raus, so schreibe ich nach dem
ersten Zeichen das weitere hinten dran. Nehmen wir an, die Zeichen
werden durch 2 Leerspalten getrennt. Dann sollte das 2. Zeichen ab
Pixel 13 stehen. Da das aber in der Mitte eines Bytes ist, muss ich das
Zeichen auslesen, welches an der Adresse steht (hier steht ein Teil des
ersten Zeichens). Dann muss ich das aktuelle Zeichen entsprechend
verschieben, um die ersten 3 Pixel ((16 - 13) % 8) anzuzeigen. Diese
Daten muss ich mit dem Inhalt des Display-RAMs verodern, um das alte
Zeichen (2. Teil des ersten Zeichens) nicht zu löschen. Danach wird das
Byte wieder geschrieben. usw.
Ist die Beschreibung so ok?
Kleiner Tipp am Rande: Man kann sich viel Datenverkehr sparen, wenn man
den String im RAM des µC vorbereitet.
Ich schreibe eine ganze Zeile (1 Pixel breit) in den RAM (der ist so
breit wie das Display, also 32 Bytes) und muss dann nur links und
rechts die beiden End-Bytes verodern. Alles andere wird überschrieben
- dadurch kann man auch Texte überschreiben, ohne gleich alles löschen
zu müssen.
Zu Deinem Problem: Ich vermute ein Timing-Problem. Ich würde
spaßeshalber in jede Subroutine, die mit dem Display auf Hardwareebene
kommuniziert, mit ein paar eingestreuten NOPs verlangsamen. Vielleicht
ist irgendwo ein Signal einen Tick zu schnell. Bedingt durch
unterschiedliche Layouts könnte es bei einem Display gerade so
hinhauen, beim anderen eben nicht...
Danke für den Tipp. Teilweise habe ich schon nops eingefügt, aber ich
werde das noch mal erweitern. Wenn ich dadurch den Fehler nicht
verhindert kann, muss ich mir auch die Daten vor dem Schreiben im RAM
speichern.
mfg
Andreas
Man könnte das mit dem Verlangsamen auch auf die Spitze treiben: Nach
jedem Programmschritt per serieller Schnittstelle den aktuellen Status
senden und auf eine Quittierung warten - also eine Art "single-step".
Dann sollte man eigentlich den Übeltäter ganz exakt finden.
Hallo,
ich habe jetzt die gesamte SW umgeworfen. Nun gebe ich einen String wie
thkais gemeint hat Zeile für Zeile aus. Dadurch kann ich die Daten im
RAM zwischenspeichern und muss das Display-RAM nicht mehr auslesen.
Allerdings flackert das Display jetzt auch ab und zu, aber weit nicht
so extrem wie vorher...
Danke für eure Hilfe.
mfg
Andreas
Noch n Tip meinerseits, sorry erstmal dass ich erst jetzt schreibe.
Ich habe auch mal einen eigenen Schriftsatz implementiert, und bin
dabei so vorgegangen:
Jeder Buchstabe war über eine Tabelle im Code hinterlegt (wird bei dir
wohl auch so sein).
Die ersten beiden Einträge der Tabelle haben die Größe des Buchstabens
in X und in Y angegeben. Alle weiteren Einträge waren die Pixel, die
den Buchstaben bilden, pro 8 Pixel also ein Byte.
Hatte ich z.B. eine Breite von 14 Pixeln, so habe ich das erste Byte
komplett und vom zweiten eben die höchstwertigen 6 Bits ausgegeben -->
mittels PUTPIXEL.
Ich musste aber nicht auslesen, so wie du es machst, sondern habe nur
die gesetzten Pixel eingetragen.
Wollte ich sicherstellen, dass ein evtl. bereits vorhandener Buchstabe
überschrieben wird, so hab ich natürlich auch die nicht gesetzten Pixel
ausgegeben...
Schließlich hat der T6963C ja eine Pixelfunktion, warum also die nicht
nutzen???
Vielleicht kannst du das auch so machen...
Ob es allerdings mit byteweisem Schreiben schneller geht, müsste ich
mal probieren, dann wäre das ganze nämlich ein Tip von dir an mich ;-)
Ralf
Hallo Ralf,
danke für den Tipp. Das hatte ich mir auch schon mal überlegt gehabt.
Ich dachte mir aber, dass das vielleicht zu langsam werden könnte, da
man immer nur 1 Pixel setzen kann.
Anbei habe ich den neuen Code, falls es dich interessiert.
Auch ich habe mir einige Schriftarten definiert. Mit einem speziellen
Tool kann ich Systemfonts umwandeln und gleich als font-Datei
speichern. Die Höhe eines Zeichens einer Schriftart ist immer gleich,
die Breite des Zeichens steht, wie bei dir, vor den eigentlichen
Daten.
mfg
Andreas
Okay, ich hab demnächst Urlaub, vielleicht probier ich mal die
1-Byte-auf-einmal-Variante...
Wie heisst dein Tool bzw. wo kann ich das herunterladen?
Ralf
Naja, das Tool zum konvertieren habe ich im Zuge eines Projektes in der
Arbeit geschrieben...
Das Tool zum Umwandeln der Systemfonts findest du anbei. Etwas
komisches Programm, aber es funktioniert und wandelt dir die Fonts in
Binäre Daten um. Diese sind aber spaltenweise und müssen erst noch (mit
meinem Tool) umgewandelt werden.
Andreas