Hallo,
wie bereits erwähnt versuche ich das folgende Display anzusteuern:
http://www.buydisplay.com/default/tft-5-inch-lcd-display-module-w-controller-board-serial-i2c-ra8875
Es sind im Beispiel Code einige Bilder im internen Flash abgelegt, die
ich auch korrekt anzeigen kann.
Jetzt versuche ich mir eigene BMP-Dateien anzeigen zu lassen.
Ich jage zum Beispiel ein 20 x 20 Bitmap File durch den Converter und
lasse es anzeigen. Das BMP File zeigt (bzw. soll zeigen) einen rot -
grünen - rot - blau - rot Streifen.
Auf dem Display angezeigt wird jedoch ein blau - braun - blau - grün -
blauer Streifen.
Das 20 x 20 Pixel Format ist hingegen korrekt. Woran könnte die falsche
Farb-Konvertierung liegen???
Wie gesagt, die Beispiel Bilder aus dem Sample Code werden korrekt
angezeigt.
Habe auch schon verschiedene Converter ausprobiert, da ich ursprünglich
dachte, dass der Fehler beim Konvertieren passiert. Mittlerweile glaube
ich aber, dass es an den Displayeinstellungen liegen müßte.
Bedankt im Voraus!
HMMM,
ich konvertiere mit 16 Bit Farbtiefe. Also das BMP-Bild an sich hat eine
Farbtiefe von 24 Bit und ich hau es in den Converter von Microchip mit
16 Bit Farbtiefe. Ein Bild mit 40 x 40 Pixel ergibt dann ein Array von
3200 Elementen mit jeweils 8 Bit.
Die Bilder die ich aus dem Example Code anzeigen kann sind
beispielsweise 112 x 140 Pixel und haben 31360 Elemente a 8 Bit.
Vermutlich doch ein Fehler in der Konvertierung?
Die Frage wäre ob die du die Farben auch im Richtigen Bitformat
umrechnest:
24Bit BMP = R(8) + G(8) + B(8)
16Bit Display = R(5) + G(6) + B(5) (je nach Display ggf. auch anders)
@Irgendwer:
Das ist interessant und vermutlich liegt hier der Hund begraben.
Habe mal genau in dem Datasheet des Display Controllers nachgeschaut
(RA8875).
Ich nutze den 16-Bit Data Bus MCU mit 65K Colors.
In diesem Mode ist nach Datasheet das RGB Format in der Tat:
R(5), G(6), B(5)
wie genau kann ich jetzt die von Dir angesprochene Umrechnung von
R(8), G(8), B(8)
durchführen???
Das ist mir noch nicht ganz klar!
Einfacher wäre vermutlich das BMP direkt in 16 Bit abzuspeichern, aber
der andere Weg ist mir deutlich lieber.
Meine Funktion zum Zeichen sieht bis jetzt in etwa so aus:
Ich habe jetzt einen Konverter gefunden (GIMP) mit dessen Hilfe man ein
Bild genau in dem Format 16Bit Display = R(5) + G(6) + B(5) abspeichern
kann.
Dieses Bild konvertiere ich dann mit 16 Bit und lasse es mit der obigen
Funktion bmp_picture auf dem Display ausgeben und die Farben sind immer
noch vertauscht.
Wie kann das sein??
Jeglicher Input willkommen. Danke.
Mach dir doch das Leben einfacher: Erzeuge ein einfarbig rotes Bild und
konvertiere es. Dann sieh dir die Ausgabe an. Nun weißt du, wo die roten
Bits gelandet sind und kannst deine Ausgabe anpassen. Anschließend das
Gleiche noch einmal mit Blau und Grün und du bist fertig.
Georg G. schrieb:> Mach dir doch das Leben einfacher: Erzeuge ein einfarbig rotes> Bild und> konvertiere es. Dann sieh dir die Ausgabe an. Nun weißt du, wo die roten> Bits gelandet sind und kannst deine Ausgabe anpassen. Anschließend das> Gleiche noch einmal mit Blau und Grün und du bist fertig.
Danke Georg. Ich blicke nicht mehr ganz durch. Habe deinen Rat befolgt.
Aus Blau -> Blau
Aus rot -> beige (oder brau, gelb)
Aus grün -> eine Mischung aus Violett und braun
Das Blau scheint genau die richtige Farbe zu sein. Es scheint aber auch
nicht eine bloße Vertauschung zwischen Rot und Grün zu sein
Was mich wundert ist, dass der Graphics Converter von Microchip genau in
das richtige Format bei 16 Bit konvertieren sollte -> R(5), G(6), B(5)
siehe Anhang!
Lisa schrieb:> Aus Blau -> Blau> Aus rot -> beige (oder brau, gelb)> Aus grün -> eine Mischung aus Violett und braun
also wenn bei grün was violettes raus kommt ist ja wieder irgendwie blau
mit drin
evl stimmt ja weder die Bitrichtung (LSB->MSB) noch die Zuordnung
H-/L-Byte.
Kannst du nicht mal ein paar Daten von Hand erzeugen, oder in einer
Schleife mal die 16-bit als konstannten Wert ausgeben?
Ich habe mir wie empfohlen erst einmal manuell versucht ein blaues
Kästchen zu zeichnen in dem oben angegebenen 16 Bit Format:
R(5) + G(6) + B(5)
also
Sende 0b00000000
und dann
Sende 0b00011111
Dies ergibt einen blauen Pixel.
Dann habe ich mir einen blaues Bitmap gezeichnet und dieses mit zig
verschiedenen Konvertern so lange konvertiert bis ich ein Array der
Form:
Steef schrieb:> Schließlich habe ich einen Konverter gefunden...
Ja - das scheint seit einigen Jahren der aktuelle Zeitgeist zu sein.
Bloß nichts mehr selber machen, nichts mehr selber verstehen, nichts
mehr selber können.
Dabei ist das Ganze doch so strunz-einfach:
/****************************
wandelt rgb nach color565 um
****************************/
word RgbToColor (byte r, byte g, byte b)
{ word w, c;
w = (b << 8) & 0xF800;
c = (g << 3) & 0x07E0;
r = r >> 3;
w = w | c | r;
return(w);
}
/****************************
wandelt color565 nach rgb um
****************************/
COLOR ColorToRGB (word color565)
{ COLOR E;
E.b = (color565 >> 8) & 0xF8; /* linksbündig */
E.g = (color565 >> 3) & 0xFC;
E.r = (color565 << 3) & 0xF8;
return E;
}
Aber ganz offensichtlich ist sowas für die heutige Ingenieurs-Generation
bereits unzumutbar.
W.S.
W.S. schrieb:> Dabei ist das Ganze doch so strunz-einfach:> /****************************> wandelt rgb nach color565 um> ****************************/> word RgbToColor (byte r, byte g, byte b)
.....
danke dafür, sieht aus als wenn ich das grad am Adafruit TFT brauchen
könnte
Ich habe mir das noch nicht genau angesehen aber es sind da auch 16 Bit
und eine Vollfarbe war 0xF800 (ein alter Ing der nicht gerade
Profiprogger ist, aber fürs Nötigste reicht es)
W.S. schrieb:> Aber ganz offensichtlich ist sowas für die heutige Ingenieurs-Generation> bereits unzumutbar.
nun ja manche haben auch anderes zu tun als Nebenkriegsschauplätze
aufzutun ;-) Wenn ich mich um jedes Byte persönlich kümmern würde wäre
ich nur an Nebenkriegsschauplätzen.