www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Quarz-Wert 32.0C6Y


Autor: Bernd Schuster (mms)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

welchen Wert hat ein Crystal mit der Aufschrift 32.0C6Y? Dieser Quarz 
wird im Zusammenhang mit einem Epson LCD Controller verwendet.

Bernd

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schonmal mit messen versucht?

Autor: Bernd Schuster (mms)
Datum:

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

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es ein Alphanumerisches Display (kein grafisches)? Dann dürften das 
32kHz sein.

Autor: Bernd Schuster (mms)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es handelt sich um ein monochromatisches graphisches display (sorry hab 
ich vergessen zu sagen) und wird mit dem Epson controller S1D13700 
angesteuert.

Bernd

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

Bewertung
0 lesenswert
nicht lesenswert
Dann ist es ganz klar ein 32MHz Quarz.

Autor: Bernd Schuster (mms)
Datum:

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

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

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

Autor: Bernd Schuster (mms)
Datum:

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

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

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

Autor: Bernd Schuster (mms)
Datum:

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

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

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

Autor: Bernd Schuster (mms)
Datum:

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

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

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

Autor: Bernd Schuster (mms)
Datum:

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

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

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

Autor: Bernd Schuster (mms)
Datum:

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

Autor: Bernd Schuster (mms)
Datum:

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

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

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

Autor: Bernd Schuster (mms)
Datum:

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

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

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

Autor: Bernd Schuster (mms)
Datum:

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

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

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

Autor: Bernd Schuster (mms)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
for(i=0; i<16; i++)
  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

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

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

>
for(i=0; i<16; i++)
>   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.

Autor: Bernd Schuster (mms)
Datum:

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

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

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

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.