bis jetzt hab iich noch keine möglichkeit das display anzusteuern -
sprich etwas zu messen.. und der quarz sitzt auf der rückseite vom
display. In der spezifikation vom display steht aber nichts bezüglich
eines quarz-wertes drinnen und beim controller ist der bereich für so
einen quarz sehr groß angegeben.
Bernd
es handelt sich um ein monochromatisches graphisches display (sorry hab
ich vergessen zu sagen) und wird mit dem Epson controller S1D13700
angesteuert.
Bernd
noch ein paar fragen zu dem epson controller:
Wie frägt man eigentlich zu Beginn ab, ob dieser Controller schon bereit
für die Initialisierung ist? Geht das nur über das Wait-Signal-Pin -
oder gibt es ein spezielles Register / Registerwert der dann gesetzt
wird?
Ist es sinnvoller direkt über die Register zu arbeiten oder indirekt
über die Variablen wie OV, DM1 (also die einzelnen Werte innerhalb der
Register)?
Standardmäßig wird die Schriftgröße 8x16 verwendet im Controller für den
internen Textgenerator - wenn man größere Buchstaben haben möchte
(benötigt man z.B. zwei speicheradressen) - wenn man Attribute wie Fett
oder Kursiv verwenden möchte, muss man dann eine eigene Bibliothek für
die Zeichen anlegen? Gibt es da bereits vorgefertigte Versionen für
diesen Controller - bzw. kann man auch andere dafür verwenden?
Bernd
Bernd Schuster wrote:
> Wie frägt man eigentlich zu Beginn ab, ob dieser Controller schon bereit> für die Initialisierung ist?
Garnicht. Du musst solange warten, wie im Datenblatt angegeben ist.
> Ist es sinnvoller direkt über die Register zu arbeiten oder indirekt> über die Variablen wie OV, DM1 (also die einzelnen Werte innerhalb der> Register)?
Register, Variablen ? Keine Ahnung was du meinst.
> Standardmäßig wird die Schriftgröße 8x16 verwendet im Controller für den> internen Textgenerator
Nein, die Standardgröße ist 8x8. Die verwendete Schriftart ist 6x8 groß.
> (benötigt man z.B. zwei speicheradressen) - wenn man Attribute wie Fett> oder Kursiv verwenden möchte, muss man dann eine eigene Bibliothek für> die Zeichen anlegen?
Ja, dann musst du alles selbst machen.
>Garnicht. Du musst solange warten, wie im Datenblatt angegeben ist.
d.h. einfach eine for-schleife, die die entsprechende dauer aufweist.
Kann man diese Dauer bzw. wieviele Durchläufe gemacht werden müssen,
ausrechnen?
>> Ist es sinnvoller direkt über die Register zu arbeiten oder indirekt>> über die Variablen wie OV, DM1 (also die einzelnen Werte innerhalb der>> Register)?>Register, Variablen ? Keine Ahnung was du meinst.
Man kann ja den Controller über seine Register (ab Adresse 7FFFh)
initialisieren oder über C und P1-P9; wobei in P1-P9 alle Registerwerte
aufgeführt sind wie z.B. OV - also durch indirect addressing. Und z.B.
über MWRITE und MREAD auf das Memory vom Display zugreifen. Was ist hier
besser zu verwenden? Hab noch nicht ganz verstanden, warum es diese
indirecte Methode gibt.
>> (benötigt man z.B. zwei speicheradressen) - wenn man Attribute wie Fett>> oder Kursiv verwenden möchte, muss man dann eine eigene Bibliothek für>> die Zeichen anlegen?>Ja, dann musst du alles selbst machen.
Gibt es da Bsp. wie man z.b. eine kursive oder fette Schrift realisiert?
Arbeitet man dann mit Bildern (bmp`s die man in den Speicher lädt, oder
über bestimmte Algorithmen)?
Bernd
Bernd Schuster wrote:
>>Garnicht. Du musst solange warten, wie im Datenblatt angegeben ist.>> d.h. einfach eine for-schleife, die die entsprechende dauer aufweist.
Ja.
> Kann man diese Dauer bzw. wieviele Durchläufe gemacht werden müssen,> ausrechnen?
Besser man benutzt vom Compiler zur Verfügung gestellte
Verzögerungsfunktionen.
> Man kann ja den Controller über seine Register (ab Adresse 7FFFh)> initialisieren oder über C und P1-P9; wobei in P1-P9 alle Registerwerte> aufgeführt sind wie z.B. OV - also durch indirect addressing.
Mit der direkten Methode benötigt man einen 64k großen Adressbereich,
die indirekte nur einen 2Byte großen. Außerdem ist der 13700 dann
kompatibel zum 13505.
> Gibt es da Bsp. wie man z.b. eine kursive oder fette Schrift realisiert?
Die übliche Methode ist, die Schriftarten am PC zu erzeugen und als
Array abzuspeichern. Die Bilder der einzelnen Buchstaben muss man dann
nur noch in den 13700 kopieren. Dies läuft dann komplett im Grafikmodus,
der interne Zeichengenerator des 13700 wird dann nicht verwendet.
vielen dank für die antworten.
>Die übliche Methode ist, die Schriftarten am PC zu erzeugen und als>Array abzuspeichern. Die Bilder der einzelnen Buchstaben muss man dann>nur noch in den 13700 kopieren. Dies läuft dann komplett im Grafikmodus,>der interne Zeichengenerator des 13700 wird dann nicht verwendet.
Wird bei dem Standard-Character-Generator eine spezielle Schrift
verwendet (z.B. Arial)?
Wenn man Fettdruck einsetzen möchte ist es wahrscheinlich eh wie du
bereits gesagt hast, besser alle Zeichen in Photoshop als bmp zu
generieren und im ROM vom S1D13700 abzuspeichern. Ist es sinnvoll
hierfür das ROM zu verwenden, da man anscheinend diesen Bereich nicht
durch die MPU auslesen kann?
Warum ist man eigentlich bei Verwendung des Grayscale-Modus in manchen
Sachen eingeschränkt? z.B. bezüglich der Scrollfunktion, die dann nicht
in jede Richtung funktionieren soll?
Bei dem Display Controller gibt es ein WF Register - AC drive method,
welches man gleich WF=1 setzen sollte, um keine Streifen im Bild zu
haben. Konnte im Internet bezüglich AC drive method nichts richtiges
finden, was mir diese Thematik näher beschreiben würde? Was versteht man
genau unter two-frame AC drive method und warum erhält man hier keine
Streifen im Bild?
Bernd
Bernd Schuster wrote:
> Wird bei dem Standard-Character-Generator eine spezielle Schrift> verwendet (z.B. Arial)?
Die Standardschrift müsste System in der Größe 8 sein. Bei einer Größe
von 6x8 sehen aber nahezu alle Schriften fast gleich aus.
> Ist es sinnvoll> hierfür das ROM zu verwenden, da man anscheinend diesen Bereich nicht> durch die MPU auslesen kann?
Welches ROM meinst du ?
> Warum ist man eigentlich bei Verwendung des Grayscale-Modus in manchen> Sachen eingeschränkt? z.B. bezüglich der Scrollfunktion, die dann nicht> in jede Richtung funktionieren soll?
Das liegt vermutlich an der Kompatibilität zum 13505. Dieser konnte
keinen Graustufenmodus.
> Bei dem Display Controller gibt es ein WF Register - AC drive method,> welches man gleich WF=1 setzen sollte, um keine Streifen im Bild zu> haben. Konnte im Internet bezüglich AC drive method nichts richtiges> finden, was mir diese Thematik näher beschreiben würde? Was versteht man> genau unter two-frame AC drive method und warum erhält man hier keine> Streifen im Bild?
Das ganze nennt sich n-line inversion. Ein LCD muss mit einer
Wechselspannung angesteuert werden (zusätzlich zu dem eigentlichen
Zeilenmultiplex). Dazu werden z.B. einmal pro Bild alle Spannungen
umgepolt. Alternativ kann das auch nach n Zeilen (in diesem Fall ist
n=16) geschehen. Welches von beiden besser ist, lässt sich so nicht
sagen, da dies vom LCD und auch vom dargestellten Bild abhängig ist. Es
ist wie immer: beide haben Vor und Nachteile.
>> Ist es sinnvoll>> hierfür das ROM zu verwenden, da man anscheinend diesen Bereich nicht>> durch die MPU auslesen kann?>Welches ROM meinst du ?
ich meine das CG ROM, in welches 160 character passen sollen. Müsste dem
Adressbereich von 8030h – 85Afh entsprechen.
>Es ist wie immer: beide haben Vor und Nachteile.
werde mal nach n-line inversion googlen um mich damit etwas besser
auszukennen, welche Vor- und Nachteile existieren. Im Datenblatt vom
S1D13700 wird bei der n=16 version gesagt, dass es eben aus bestimmten
blickwinkeln zu streifenbildung kommen kann.
>> Man kann ja den Controller über seine Register (ab Adresse 7FFFh)>> initialisieren oder über C und P1-P9; wobei in P1-P9 alle Registerwerte>> aufgeführt sind wie z.B. OV - also durch indirect addressing.>Mit der direkten Methode benötigt man einen 64k großen Adressbereich,>die indirekte nur einen 2Byte großen. Außerdem ist der 13700 dann>kompatibel zum 13505.
Noch eine kleine Frage hierzu: der Adressbereich der Register ist immer
der Bereich von 8000h – 802Fh (Register-Area). In welchem Zusammenhang
stehen jetzt die 64k und 2Byte? Bzw. wie komm ich auf diese Werte? C,
P1-P8 bestehen jeweils aus 8Bits -> also 64Bits - wenn ich über die
Register direkt gehe, benötige ich ja nur einen Zeiger mit dem ich zu
den jeweiligen Werten hinspringe.
Bernd
Bernd Schuster wrote:
>>> Ist es sinnvoll>>> hierfür das ROM zu verwenden, da man anscheinend diesen Bereich nicht>>> durch die MPU auslesen kann?>>>Welches ROM meinst du ?>> ich meine das CG ROM, in welches 160 character passen sollen. Müsste dem> Adressbereich von 8030h – 85Afh entsprechen.
Die Zeichen im CGROM sind fest. Du kannst aber alternativ den
Zeichensatz ins Displayram laden, und den internen Zeichengenerator
entsprechend konfigurieren. Allerdings ist dieser auf 256 8x16 Zeichen
beschränkt.
>>Mit der direkten Methode benötigt man einen 64k großen Adressbereich,>>die indirekte nur einen 2Byte großen. Außerdem ist der 13700 dann>>kompatibel zum 13505.>> Noch eine kleine Frage hierzu: der Adressbereich der Register ist immer> der Bereich von 8000h – 802Fh (Register-Area). In welchem Zusammenhang> stehen jetzt die 64k und 2Byte?
Zu dem Registerbereich kommt noch der Displayspeicher (32kByte).
Insgesamt also 64kByte.
Alternativ kann man das ganze auch über das Befehls/Parameterregister
machen, dann hat man nur diese 2Bytes.
>Zu dem Registerbereich kommt noch der Displayspeicher (32kByte).>Insgesamt also 64kByte.
gut, dann ist es über das Befehls/Parameterregister zu arbeiten und
dadurch ein paar mehr Codezeilen zu haben, sinnvoller, um damit RAM zu
sparen für den Zeichensatz.
>Die Zeichen im CGROM sind fest. Du kannst aber alternativ den>Zeichensatz ins Displayram laden, und den internen Zeichengenerator>entsprechend konfigurieren. Allerdings ist dieser auf 256 8x16 Zeichen>beschränkt
Die Zahl 256 bezieht sich jetzt aber schon auf die Anzahl
abzuspeichender Charakter und nicht auf die Anzahl von darzustellen
Charaktern auf dem Display. Also insgesamt kann das Display 256
verschiedene Zeichen mit diesem RAM darstellen und speichern, aber
natürlich können am display diese 256 Zeichen öfters vorhanden sein.
Wie kann man denn den internen Zeichensatz konfigurieren? Bis jetzt hab
ich nur eine Möglichkeit entdeckt größere Zeichen als die 8x16 zu
produzieren auf kosten von weniger Zeichen, da dann ein Zeichen z.B. 2
Speicheradressen benötigt, statt einer.
Wie ist es denn am sinnvollsten zu arbeiten: Vielleicht ein paar Worte
zu dem was ich darstellen möchte: Auf dem Display 320x240 soll es 5
menüpunkte geben, die immer eingeblendet sind. In dem Menüpunkt in dem
man sich gerade befindet soll hervorgehoben werden (z.B. durch Fettdruck
und etwas vergrößerter Schrift) Gleichzeitig sollen alle fünf Menüpunkte
mit einem Rahmen versehen sein (also ein Grafiklayer). In einem solchen
Menüpunkt sind dann einzelne Textpassagen mit Eingabefelder (wie man es
so kennt in den Windows-Menüs) - also brauch ich hierfür den anderen
Grafiklayer, da diese eingabefelder nicht verodert sondern mit XOR
verbunden werden müssen. Ist das so möglich darzustellen, oder kann ich
nur immer alle Layer miteinander verodern oder mit XOR, oder AND
verbinden?
Bernd
Bernd Schuster wrote:
> Wie kann man denn den internen Zeichensatz konfigurieren? Bis jetzt hab> ich nur eine Möglichkeit entdeckt größere Zeichen als die 8x16 zu> produzieren auf kosten von weniger Zeichen, da dann ein Zeichen z.B. 2> Speicheradressen benötigt, statt einer.
Ein Problem an dem internen Zeichengenerator ist, dass alle Zeichen eine
durch 8 teilbare Breite haben müssen, bzw, falls nicht dann wird auf den
nächsten Wert aufgerundet.
Ich nutze den Zeichengenerator daher relativ selten. Sobald
unterschiedlich große Schriftarten verwendet werden, mache ich das per
Software und setze im µC den Text in Grafik um. Das ist ein wenig
Rechenaufwendiger, ist aber sehr viel flexibler.
>Sobald unterschiedlich große Schriftarten verwendet werden, mache ich >das per
Software und setze im µC den Text in Grafik um. Das ist ein wenig
>Rechenaufwendiger, ist aber sehr viel flexibler.
d.h. mehrere Arrays mit den Texten. Und bmps in Photoshop erzeugen mit
den einzelnen Buchstaben, die im µController dann ebenfalls in Arrays
gegliedert werden (klein-, groß-, fett-, und kursive Buchstaben z.B.)
und die dann als Grafik in den LCD Controller importieren.
Bernd
Fsysclk = 2 * [ClockDiv] Ffr [L/F] * F (Hz)
ist mit Fsysclk, die Frequenz vom Quarz (also 32MHz) gemeint? ClockDiv
wird konfiguriert mit Hilfe der CNF-Pins. Ist die FPSHIFT und Frame
Frequency die gleiche Frequenz?
Bernd
Bernd Schuster wrote:
> ist mit Fsysclk, die Frequenz vom Quarz (also 32MHz) gemeint?
Ja.
> ClockDiv wird konfiguriert mit Hilfe der CNF-Pins.
Genau.
> Ist die FPSHIFT und Frame Frequency die gleiche Frequenz?
Nein. FPSHIFT ist der Pixeltakt für jedes Datenpaket (4 Pixel). Bei
jeder zusätzlichen Farbtiefenverdoppelung, halbiert sich diese Frequenz.
Frame Frequency ist die Bildwiederholrate.
>Frame Frequency ist die Bildwiederholrate.
wie komm ich auf den Wert, den ich für Ffr einsetzen muss? Im Datenblatt
im Controller wird immer von 70Hz ausgegangen. Im Datenblatt vom Display
steht keine Framefrequenz drinnen.
Bernd
Der Wert liegt fast immer zwischen 50 und 100Hz. Bei vielen Graustufen
eventuell auch mal höher bis max etwa 150Hz.
Fsysclk = 2 * [ClockDiv] Ffr [L/F] * F (Hz)
Allgemein kann man sagen:
Pixeltakt= Horizontale Auflösung Vertikale Auflösung
Bildwiederholrate
F müsste demnach die Anzahl an Pixel pro Zeile sein.
hab einfach mal mit 70Hz gerechnet und komm dann auf einen Wert für TC/R
von 234. -> kann nicht richtig sein; Allerdings kann die Quarzfrequenz
höher gewählt werden als der tatsächlich ausgerechnete Wert für Fsysclk.
F = [TC/R] + 4 und TC/R müsste die Anzahl der Pixel in einer ganzen
Zeile sein - d.h. 320 pixel + x. C/R müsste 320 Pixel sein.
[C/R] is the number of bytes per line -> 320 / 8 = 40 sein.
[TC/R] = [C/R] + 4 oder größer -> mindestens 44 Bytes oder 352 Pixel
F wird in Pixel gerechnet -> 44 * 8 + 4 = 356 Pixel
Woher kommen jetzt noch diese 4 Pixel unterschied zu [TC/R] zustande?
[TC/R] > [C/R] -> wegen sauberer Taktfrequenz
Bei einer Frame Frequency von 50Hz komm ich auf eine Fsysclk = 34 MHz
Bernd
Bernd Schuster wrote:
> F = [TC/R] + 4 und TC/R müsste die Anzahl der Pixel in einer ganzen> Zeile sein - d.h. 320 pixel + x. C/R müsste 320 Pixel sein.
Nein, das sind die kompletten Zeichen pro Reihe, also Pixel/8 +
Zeilenrücklauf.
Ich rechne das ganz einfach:
Systemtakt = Pixel/Zeile x Zeilen/Bild x Wiederholrate x bpp x
Teilerfaktor.
zu welchem Zweck liest man Adressen aus dem Display Memory vom
Controller aus mit MREAD? Nur zur Überprüfung, ob an der richtigen
Stelle die richtigen Werte stehen?
Man muss zuerst das Commando CSRR schreiben, anschließend die Adresse
(low-order und anschließend high-order Byte) schreiben und mit dem
folgenden MREAD Commando müsste man den Wert auslesen können.
1
for(i=0;i<16;i++)
2
printf(%d", *p_Data++);
Wenn p_Data die Adresse beinhaltet, die ausgelesen werden soll. Wenn ich
das in einer Schleife laufen lasse, kann ich dann das gesamte Display
auslesen? Oder muss der Cursor nach jedem Zeilenende per Hand auf den
neuen Zeilenanfang miz AP gesetzt werden?
Bernd
Bernd Schuster wrote:
> zu welchem Zweck liest man Adressen aus dem Display Memory vom> Controller aus mit MREAD? Nur zur Überprüfung, ob an der richtigen> Stelle die richtigen Werte stehen?
Meistens um Linien zu zeichnen oder ähnliches (also um 1 Pixel in einem
Byte zu setzen.)
> Man muss zuerst das Commando CSRR schreiben, anschließend die Adresse> (low-order und anschließend high-order Byte) schreiben und mit dem> folgenden MREAD Commando müsste man den Wert auslesen können.
Im Indirekten Modus, ja.
Danach kann man Byte für Byte über das Parameterregister auslesen.
>
1
for(i=0;i<16;i++)
2
>printf(%d", *p_Data++);
>> Wenn p_Data die Adresse beinhaltet, die ausgelesen werden soll. Wenn ich> das in einer Schleife laufen lasse, kann ich dann das gesamte Display> auslesen?
Im direkten Modus funktioniert das so.
>> zu welchem Zweck liest man Adressen aus dem Display Memory vom>> Controller aus mit MREAD? Nur zur Überprüfung, ob an der richtigen>> Stelle die richtigen Werte stehen?>Meistens um Linien zu zeichnen oder ähnliches (also um 1 Pixel in einem>Byte zu setzen.)
Kannst du mir das noch etwas genauer erklären? Man liest eine Adresse
aus dem Speicher aus, und schreibt dann mit MWRITE ein Bit z.B. an diese
Adresse? Welchen Vorteil erlange ich, wenn man zuerst die jeweilige
Adresse ausliest?
>> Wenn p_Data die Adresse beinhaltet, die ausgelesen werden soll. Wenn ich>> das in einer Schleife laufen lasse, kann ich dann das gesamte Display>> auslesen?>Im direkten Modus funktioniert das so.
Wie funktioniert das im indirekten Modus? ich setze das CSRR Commando,
anschließende die Adresse vom Speicher und dann das MREAD Commando. Kann
ich dann im indirekten Modus mit dem Pointer der auf die Adresse im
Speicher zeigt, nur diese Adresse auslesen, oder kann ich den Pointer
auch ganz normal immer mit *ptr++ weitersetzen um mehr auslesen zu
können?
Bernd
Bernd Schuster wrote:
>>> zu welchem Zweck liest man Adressen aus dem Display Memory vom>>> Controller aus mit MREAD? Nur zur Überprüfung, ob an der richtigen>>> Stelle die richtigen Werte stehen?>>>Meistens um Linien zu zeichnen oder ähnliches (also um 1 Pixel in einem>>Byte zu setzen.)>> Kannst du mir das noch etwas genauer erklären? Man liest eine Adresse> aus dem Speicher aus, und schreibt dann mit MWRITE ein Bit z.B. an diese> Adresse? Welchen Vorteil erlange ich, wenn man zuerst die jeweilige> Adresse ausliest?
Man liest ein Byte, setzt bei diesem den gewünschten Pixel (=Bit) und
schreibt das neue Byte. So kann man einen Pixel verändern ohne den Rest
zu beeinflussen.
>>> Wenn p_Data die Adresse beinhaltet, die ausgelesen werden soll. Wenn ich>>> das in einer Schleife laufen lasse, kann ich dann das gesamte Display>>> auslesen?>>>Im direkten Modus funktioniert das so.>> Wie funktioniert das im indirekten Modus? ich setze das CSRR Commando,> anschließende die Adresse vom Speicher und dann das MREAD Commando. Kann> ich dann im indirekten Modus mit dem Pointer der auf die Adresse im> Speicher zeigt, nur diese Adresse auslesen,
Genau. Allerdings kann man den 13700 so einstellen, dass die Adresse
automatisch erhöht wird. In C liest man die Daten dann immer von der
selben Adresse, im 13700 wird der Pointer aber erhöht.
