Hallo, welchen Wert hat ein Crystal mit der Aufschrift 32.0C6Y? Dieser Quarz wird im Zusammenhang mit einem Epson LCD Controller verwendet. Bernd
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
Ist es ein Alphanumerisches Display (kein grafisches)? Dann dürften das 32kHz sein.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.