Hallo Martin,
ohne den Zusammenhang zu kennen,
ist es unmöglich mehr zu sagen,
als das was dasteht in normales Deutsch zu übersetzen.
Das aber wird die Funktion nicht klarmachen.
Was verstehst Du denn nicht an den beiden Zeilen?
Gruss
Oops
OK. Also los:
>Buffer[X + (Y / 8) * 128] &= ~(mask << (shift1));
Indiziere den Vektor Buffer mit X+(Y/8), greife auf den Inhalt zu und
Verknüpfe ihn bitweise mit der UND-Verknüpfung mit einem Wert mask der
um diejenige Anzahl Bits nach links verschoben ist, die in shift1 steht
und dann bitweise negiert worden ist.
Weise das Ergebnis wieder dem mit X+(Y/8) indizierten Vektor Buffer zu.
Gruss
Oops
oops: Nicht ganz:
Indiziere den Vektor Buffer mit X+(Y/8), greife auf den Inhalt zu und
Verknüpfe ihn bitweise mit der UND-Verknüpfung mit einem Wert mask der
um diejenige Anzahl Bits nach links verschoben ist, die in shift1 steht
und dann (nach dem Verschieben) bitweise negiert worden ist.
Weise das Ergebnis wieder dem mit X+(Y/8) indizierten Vektor Buffer zu.
Oops
Buffer[X + (Y / 8) * 128] |= (~B2Write << shift1);
Analog hier: Verschiebung eines Wertes negierten Wertes B2Write vor dem
verschieben. Keine Negation des Schiebeergebnisses. Verknüpfung ist OR
anstelle von UND.
Hilft das (wirklich)?
Gruss
Oops
Also wenn das für'n GLCD ist, dann wird durch X/Y wohl die
Displayposition definiert (Zeile/Spalte).
In der ersten Zeile werden dann entsprechende Pixel gelöscht, während in
der zweiten Zeile entsprechende Pixel gesetzt werden (vorausgesetzt, ein
gesetztes Bit in Buffer[] entspricht einem sichtbaren Pixel... ansonsten
umgekehrt!)
Warum durch 8 geteilt: dazu muss man den Datenblatt von GLCD durchlesen!
(Also ein Byte = 8 "Zeilen", besser gesagt, 8 Bildpunkte untereniander.)
Karoly
Wenn Du darauf anspielst, dass (Y/8)*128 = Y*16 ist...
...weit gefehlt!!!
Die (Ganzzahl-) Division /8 schneidet eventuelle Nachkommastellen
einfach ab. Also z.B. 15/8 = 1
Damit wäre dann (15/8)*128 = 128 und nicht 15*16 = 240!
Wozu das nun gut sein soll, ist ohne weitere Infos zu dem GLCD, dem
restlichen Programm und dem, was damit bezweckt werden soll, nicht zu
beantworten!
Martin wrote:
> Also das ist ein KS0108 Display und er Code ist im Anhang.> Schriftgröße 5*7
Das mag schon sein, ändert aber nichts daran, dass das
GLCD anscheinend immer 8 übereinanderliegende Pixel
hardwaremässig zu einem Byte zusammenfasst.
Das einzige was sich bei einem 5*7 Font und freier
Positionierbarkeit der Buchstaben wirklich interessiert, ist:
In welchem Byte muss welches Pixel gesetzt werden, damit
an der Position X / Y genau das gewünschte Pixel aufleuchtet.
Und da der Text ja nicht rastermäßig genau über einem GLCD Byte
zu liegen kommen muss, kann es eben auch sein, dass 2
(in Y Richtung) übereinanderliegende Bytes begrapscht werden
müssen, damit eine Spalte eines Buchstabens ausgegeben werden
kann.
>Das mag schon sein, ändert aber nichts daran, dass das>GLCD anscheinend immer 8 übereinanderliegende Pixel>hardwaremässig zu einem Byte zusammenfasst.
Das ist beim KS0108 so.
Anscheinend handelt es sich um ein Display mit 128 * 64 Pixeln (d.h 128
Spalten und 8 Zeilen, jede 8 bit hoch), dessen Zeilen/Spaltenmatrix in
einem linearen Buffer nachgebildet wird(daher das x+(y/8)*128)). Da
hinein wird dann ein Maskenbyte logisch verknüpft, um einzelne Bits zu
setzen.
Wofür das gut ist, musst du leider selber rausfinden. Mein Compiler
liest keine pdf-Files :-)
Oliver
Eine eigene Frage?
Dieser Thread ist über 18 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.