Hallo,
ich habe hier den folgenden Display Controller für ein 240 x 128 Pixel
Display (UC1698):
http://wenku.baidu.com/view/cbf8c18102d276a200292ece.html
Der RGB Controller scheint mir für ein monochromes Display etwas
exotisch zu sein :)
Ich befinde mich RRRR GGGG BBBB, 4K Color Mode, d.h. jeder Pixel wird
mit 4 Bit angesteuert :)
Der Controller erwartet aber immer mindestens 12 Bit, d.h. ich sollte
immer Minimum 3 Byte senden, um auf eine gerade Pixel Anzahl zu kommen.
Ich würde jetzt gerne eine Funktion schreiben, die gezielt einen Pixel
schreibt und keinen anderen löscht. Zeilen und Spalten kann ich gezielt
ansteuern. Ich habe es im Folgenden mal mit 2 Byte versucht, was den
Nachteil hat, dass immer auch Pixel wieder gelöscht werden !!!!
Wie kann man das besser machen?
Pixel schrieb:> Ich würde jetzt gerne eine Funktion schreiben, die gezielt einen Pixel> schreibt und keinen anderen löscht. Zeilen und Spalten kann ich gezielt> ansteuern. Ich habe es im Folgenden mal mit 2 Byte versucht, was den> Nachteil hat, dass immer auch Pixel wieder gelöscht werden !!!!>> Wie kann man das besser machen?
Dann musst du dir eben aus dem Displayspeicher zuerst das Byte holen, in
welchem die 4 Bit erhalten bleiben müssen. welches das ist, hängt
wiederrum von der auszugebenden Position ab, die du ja in deinem switch
schon berücksichtigt hast.
die 4 Bit extrahierst du dir und ergänzt damit die 4 Bit in deinen neu
zu schreibenden 2 Bytes. Im Endeffekt dürfen sich im Speicher nur die 12
zum relevanten Pixel gehörenden Bits geändert haben und keine anderen.
Ich steuere das Display via SPI an und es ist nur eine Data Input
Leitung und keine SDO Leitung vorhanden. Ich weiss also nicht ganz wie
ich den Displayspeicher auslesen soll, obwohl mir die Idee schon klar
ist.
Überprüfe 16Bit und merke wie die nicht zu setzenden 12 Bit belegt
waren. Schreibe diese 12 Bit wieder und manipuliere nur die neu zu
setzenden 4 Bit?
Eine andere Idee wäre immer 3 Byte, also 24 Bit oder 6 Pixel zu
schreiben!
Etwas unschön, aber das müsste leicht zu realisieren sein.
> Eine andere Idee wäre immer 3 Byte, also 24 Bit oder 6 Pixel zu> schreiben!> Etwas unschön, aber das müsste leicht zu realisieren sein.
Würde dann so aussehen:
Pixel schrieb:> Ich steuere das Display via SPI an und es ist nur eine Data Input> Leitung und keine SDO Leitung vorhanden. Ich weiss also nicht ganz wie> ich den Displayspeicher auslesen soll, obwohl mir die Idee schon klar> ist.> Überprüfe 16Bit und merke wie die nicht zu setzenden 12 Bit belegt> waren. Schreibe diese 12 Bit wieder und manipuliere nur die neu zu> setzenden 4 Bit?>> Eine andere Idee wäre immer 3 Byte, also 24 Bit oder 6 Pixel zu> schreiben!> Etwas unschön, aber das müsste leicht zu realisieren sein.
Das hilft dir aber beim Problem nicht weiter.
Denn von einer Pixel Setz Routine geh ich schon davon aus, dass ich
damit beliebige Pixel setzen kann. Und wenn ich damit ein blaues Pixel
in eine Fläche setzen will, von der ich nichts weiss (weil es zb eine
Bitmap mit einem Bild ist), dann muss sich die Pixel-Setz Routine darum
kümmern, dass die Pixel rundum sich nicht verändern.
Wenn du vom Controller den Speicher nicht auslesen kannst, dann musst du
dir eben im Programm ein Duplikat des Speichers zurecht legen. So
schmerzhaft das auch ist.
Oder aber du lebst mit der Krücke, dass du eben nicht wahlfrei
irgendwelche Pixel verändern kannst.
Kann man machen. Wird aber schnell zu einem 'Pain in the ass'.
Hi,
wenn du solche Manipulationen machen möchtest, empfiehlt es sich den
Bildschirmspeicher min 1x als Abbild im eigenen Speicher zu haben.
Dann werden solche SetPixel Funktionen auf das Abbild angewandt und ans
Display neu übertragen.
OK danke für die Antworten.
Brauche nochmal einen kleinen Anstoss.
Habe es jetzt ein Array angelegt mit 3840 Byte (280 x 128 Pixel -> 3840
Bytes).
Dieses Update ich regelmäßig. Ich bekomme es jetzt hin, dass ich jeden
Pixel darstellen kann.
Die Put Pixel Funktion ist jetzt natürlich nich falsch. Ich möchte
dieser Zeilen und Spalten übergeben und dann automatisch den zugehörigen
Pixel übergeben.
Bis jetzt kann ich ja nur den 1. 9. Pixel usw. setzen.
Pixel schrieb:> Die Put Pixel Funktion ist jetzt natürlich nich falsch. Ich möchte> dieser Zeilen und Spalten übergeben und dann automatisch den zugehörigen> Pixel übergeben.
Und wo ist da jetzt die Frage?
> Bis jetzt kann ich ja nur den 1. 9. Pixel usw. setzen.
Wenn du mit dieser PuPixel Funktion ein Pixel neu setzt, dann kennst du
damit ja aber auch implizit alle Bytes (die ergeben sich aus der Zeile
und der Spalte des neu zu setzenden Pixels), die sich ändern. Deren
Information suchst du dir aus deinem Array zusammen und überträgst sie
so zum Controller, wie der das haben will.
Wo ist da jetzt das Problem, ausser dass es Programmierarbeit bedeutet?
Ich denke, du solltest dir mal ein paar Zeichnungen machen.
Dann wird vieles klarer.
IMHO ist das einer der Grundfehler in der Entwicklung, auf Papier und
Bleistift zu verzichten. Man verliert dann leicht den Überblick.
Pixel schrieb:> Die Put Pixel Funktion ist jetzt natürlich nich falsch. Ich möchte> dieser Zeilen und Spalten übergeben und dann automatisch den zugehörigen> Pixel übergeben.
In Grunde ist deine gesamte Herangehensweise falsch. Du hast dir ein
Display zugelegt und dir dann gedacht, "jetzt mach ich mir zu allererst
ne PutPixel-Routine, wo ich später drauf aufbauen will." Also geradeaus
mit dem Kopf durch die Wand.
Mach es anders, und zwar ganz anders. Trenne die Grafik vom konkreten
Display.
Hä?
denkst du jetzt vielleicht, aber ich meine es ernst:
Richte dir einen Bildspeicher im RAM ein, den du so organisierst, daß es
dir am besten paßt. Also entweder wortweise unter Freilassen von 4 Bit
oder eben kompakt unter Nutzung aller Bits. Dann schreib dir ein GDI
dazu, was nur auf den Bildspeicher arbeitet. Das kanst du dir dann auf
einem PutPixel für den Bildspeicher aufbauen.
Getrennt davon sind dann alle Routinen zum Einrichten des konkreten
Displays und zum Blocktransfer vom Bildspeicher zum Display. Ich mache
das so, daß ich bei jedem Schreibvorgang in den Bildspeicher ein
Kennzeichen setze, was später vom Timertick abgefragt wird, der wiederum
einen "event" generiert, der dann zum Blocktransfer vom Bildspeicher zum
Display führt. Dadurch kann man sorgenlos seine Grafik aufbauen und der
Transfer wird nicht bei jedem Furz, sondern nur dann durchgeführt, wenn
die ganze Zeichnerei im wesntlichen über die Bühne ist.
Und sowas sieht mir viel zu umständlich und rechenintensiv aus:
set_row(row);
set_column(column);
shadow_RAM[column + row * 240] = shadow_RAM[column + row * 240]
Aus dem Handgelenk würde ich es etwa so machen:
L = (X+Bildbreite*Y)*12;
Index = L >> 3;
BitPos = L & 7;
wenn man mit einem Array of byte arbeiten will.
W.S.
Karl H. schrieb:> Ich denke, du solltest dir mal ein paar Zeichnungen machen.> Dann wird vieles klarer.> IMHO ist das einer der Grundfehler in der Entwicklung, auf Papier und> Bleistift zu verzichten. Man verliert dann leicht den Überblick.
Danke für den Tipp mit der Zeichnung. Ich habe es jetzt wie folgt
realisiert. Es geht vermutlich weit aus eleganter :)
Ich kenn deinen Prozessor nicht. Wenn bei dem ein variabler Shift nichts
extra kostet, dann natürlich so (und ohne das extra Array, welches
Bitnummern in Bitmasken umsetzt):
Es sind 32 Byte, also vermute ich stark, dass es im Prinzip ein 16 x 16
Font ist.
Weiss jemand, wie dies in der Regel codiert ist?
Ich habe es mit jeweils 2 Byte horizontal versucht und dann in neue
Zeile usw.
Das Passt noch nicht so richtig.
Ebenfalls die ersten 16 Byte von oben nach unten und dann die letzten 16
Byte wieder von oben nachunten passt nicht.
Dateiname des Fonts ist 12x16 horizontal MSB_1.
8x8 klappt wunderbar und ist eigentlich selbsterklärend.
Nur bei 12 x 16 bin ich nicht sicher in welcher Reihenfolge die Bits
geschrieben werden (im Normalfall).
Gibt es irgend nen Standard wie sowas normalerweise codiert ist?
Pixel schrieb:> Vielen Dank schon einmal für die Hilfen.>> Ich habe noch eine weitere Frage. Ich habe hier einen 12x16 Pixel Font> der folgenden Form (hier für 'A'):>>
>> Es sind 32 Byte, also vermute ich stark, dass es im Prinzip ein 16 x 16> Font ist.> Weiss jemand, wie dies in der Regel codiert ist?
In der Regel ist 1 Bit mit 1 Pixel gleichzusetzen.
Wenn man nichts weiter weiss, dann nimmt man sich einfach mal die Bytes
her, schlüsselt die in Bits auf und malt einfach mal auf einem Papier
(karriertes Papier ist da ideal) für die 1 Bits ein Kreuzerl und für ein
0 Bit nichts.
Mit der Methode des 'scharfen Hinsehens' erkennt man dann meist rasend
schnell, wie der Font aufgebaut ist.
> Gibt es irgend nen Standard wie sowas normalerweise codiert ist?
Nein.
Probieren und die Methode des "scharfen Hinsehens" führen aber bei so
einfachen Fontbeschreibungen in kürzester Zeit zum Ziel.
Karl H. schrieb:> Nein.> Probieren und die Methode des "scharfen Hinsehens" führen aber bei so> einfachen Fontbeschreibungen in kürzester Zeit zum Ziel.
Mach ich das mal mit den von dir geposteten Daten, dann sehe ich
1
7654321076543210
2
** 0x60 0x00
3
** 0x60 0x00
4
**** 0xF0 0x00
5
**** 0xF0 0x00
6
**** 0xF0 0x00
7
* ** * 0x98 0x01
8
* ** * 0x98 0x01
9
* ** * 0x98 0x01
10
** ** 0x0C 0x03
11
****** ** 0xFC 0x03
12
****** ** 0xFC 0x03
13
** ** 0x06 0x06
14
** ** 0x06 0x06
15
** ** 0x06 0x06
16
0x00 0x00
17
0x00 0x00
und das sieht schon fast wie ein 'A' aus. Auffällig ist, dass das 'A'
fast in der Mitte durchgeschnitten erscheint. Aus dieser Ansicht vermute
ich mal ganz stark, dass
* jeweils 2 Bytes zusammengehören
* das jeweils 2 Byte grafisch links vom jeweils 1ten Byte steht
Probiere ich das mal grafisch aus, dann ergibt sich
1
7654321076543210
2
** 0x00 0x60
3
** 0x00 0x60
4
**** 0x00 0xF0
5
**** 0x00 0xF0
6
**** 0x00 0xF0
7
** ** 0x01 0x98
8
** ** 0x01 0x98
9
** ** 0x01 0x98
10
** ** 0x03 0x0C
11
******** 0x03 0xFC
12
******** 0x03 0xFC
13
** ** 0x06 0x06
14
** ** 0x06 0x06
15
** ** 0x06 0x06
16
0x00 0x00
17
0x00 0x00
man muss kein Hellseher sein um zu sehen, dass es jetzt "passt".
Allenfalls kann es jetzt noch sein, dass die Zeichen gespiegelt sind.
Das kann man natürlich auch noch ausprobieren, indem man naiv mit der
bis jetzt gewonnenen Vorschrift einfach mal einen nicht symetrischen
Buchstaben zu entschlüsseln versucht (zb. ein 'B')
Pixel schrieb:> Ich habe noch eine weitere Frage. Ich habe hier einen 12x16 Pixel Font> der folgenden Form (hier für 'A'):
Ja. Habe Font in unbekanntem Format, weiß nicht wie gut er ist und hab
auch kein GDI dafür... Mein Rat: schmeiß sowas weg, du ärgerst dich bloß
drüber.
Falls du tatsächlich Fonts und dazu passendes GDI haben willst, dann
lade dir die Lernbetty (Gebetsmühle...) herunter. Die dortigen Fonts
sind auf unterschiedlichsten Architekturen einsetzbar (auch Bigendian)
und du hast eine dazu passende Routine im GDI, welche dir deine Zeichen
an frei wählbare Stellen im Display setzt. Wie das Ganze funktioniert,
kannst du in der Quelle nachlesen - und wie so ein Font aufgebaut ist,
siehst du im Font. Obendrein hatte ich m.W. auch noch einen kleinen
Fontcompiler dazugepackt, der von Textdateien (in bestimmtem Format)
derartige Font-C-Quellen produziert. Damit hast du das Werkzeug, um dir
verhältnismäßig einfach per Editor eigene Zeichen zu kreieren.
Prinzipiell sind bei dieser Lösung alle Fonts proportional, du kannst
also die Zeichenbreiten der einzelnen Zeichen individuell wählen.
Lediglich die Brutto-Zeichenhöhen (also gesamte Zeichenhöhe plus
Durchschuß) sind innerhalb eines Fonts gleich. Und Fonts mit fester
Breite sind nur ein Sonderfall davon.
So, und wenn du die Lernbetty nicht findest, dann guck in die angehängte
Datei hinein. Ist ein Beispiel.
W.S.
Thread beobachten
Seitenaufteilung abschalten