Hallo zusammen, ich habe mir in der Bucht ein 7'' TFT Display gekauft, daß ich nicht im 565-Mode zu Spielen bekomme. Den Display-Adapter verwende ich auch bei eionem 3.2'' Display und SSD1289 Comntroller im 565-Mode, und das funktioniert es einwandfrei. Nur im vorlioegenden Fall, der 1963 ist natürlich auf 16bit-565-Mode eingestellt, will nicht funzen, das HiByte wird immer als 0x00 gekesen (ist aber korrekt) Ich denke, der Controler hat eine MAcke, ich kann das aber mangels zweitem Display nicht verifizieren. Daher will ich als workaround dieses Display im 8.bit Mode ansteuern, was auch funktioniert. Nur, wie mache ich aus der 565-Farbdarstellung die 3 mal 8 bit (888-Darstellung)? Um nicht ein komplett eigenes System nur für diesen einen Anwendungsfall entwerfen zu müssen, wäre das eine akzeptable Lösung. nur, wie? Das Mappen der 5-6-5 bits auf die unteren bits der 8-.8-8 Darstellung verfälscht die farbe komplett und ist natürlich zu dunkel, das Mpeen jeweils auf die oberen Bitpositionen erzeugt ebenso einen unakzeptablen Farbstich. Hat einer eine Idee? Ach ja, die Imnitialisierung der Displays erfolgt gemäß der UTFT Libarary von henning carlsen, Mai 2014. Der Farbmode wird mit dem Befehl 0xf0 korrekt eingestellt: 0x03 für 16 bit 5-6-6, 0x00 für 8-8-8 Mode
Gast
#5210172
Hanns-Jürgen M. schrieb: > Der Farbmode wird mit dem > Befehl 0xf0 korrekt eingestellt: 0x03 für 16 bit 5-6-6, 0x00 für 8-8-8 > Mode Es reicht ja nicht das Display korrekt zu konfigurieren. Ich benutze dieses UTFT Zeugs nicht (und ich wühle mich da auch nicht durch), daher meine Frage bzw Zweifel ob die UTFT den 24-Bit-Modus überhaupt unterstützt... Denn die Unterscheidung 16/24 Bit dürfte die Lib nochmal langsamer machen, zusätzlich zum extra Byte schreiben ... es muss ja für jedes Pixel ein Byte mehr geschrieben werden.
Oh, Mißverständis meines Posts, sorry, mein Fehler.. Ich habe lediglich die Init-Daten für den SSD1963 aus der UTF Lib entnommen, mehr nicht. Denn Rest, wie das Beschreiben, das Umschalten Portrait/Landscape, Rechteck-Funktion, Fontververabeitung habe ich selber entworfen. Das funzt auch alles. Aber offenbar sind die INIT Werte im Befehl 0xB0 falsch, und das auch im Datenblatt (oder ich habe das falsch verstanden). Nach Wechsel des erstenm Parameters von 0x24 (24 bit) auf 0x04 (18 bit) funktioniert das Ganze richtig. Ich hatte den Hinweis gestern abend spät im Internet gefunden, aber leider den Link nicht abgespeichert. Sourcecodeausschnitt:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Das Problem ist damit gelöst.
Gast
#5210661
Hanns-Jürgen M. schrieb: > Das Problem ist damit gelöst. Das heisst die UTFT Lib kann 18/24 Bit? Oder ist der relevante Teil (ein Pixel setzen) dann selbst geschrieben?
Display Programmierer schrieb: > Hanns-Jürgen M. schrieb: >> Das Problem ist damit gelöst. > > Das heisst die UTFT Lib kann 18/24 Bit? Oder ist der relevante > Teil (ein Pixel setzen) dann selbst geschrieben? Ja, beide Varianten 8-8-8 (3 bytes hintereinander) und 5-6-5 (ein word) funktionieren Befehl 0xb0, Data 0x24 Befehl 0xf0, Data 0x01 Dann 3 bytes (RGB) hintereinander pro Pixel senden Befehl 0xb0, Data 0x04 Befehl 0xf0, Data 0x03: Dann ein Word mit Farbmode 565 pro Pixel senden. Beides geht.
Gast
#5211251
Hanns-Jürgen M. schrieb: > Um nicht ein komplett eigenes System nur für diesen einen Anwendungsfall > entwerfen zu müssen, wäre das eine akzeptable Lösung. nur, wie? Das > Mappen der 5-6-5 bits auf die unteren bits der 8-.8-8 Darstellung > verfälscht die farbe komplett und ist natürlich zu dunkel, das Mpeen > jeweils auf die oberen Bitpositionen erzeugt ebenso einen unakzeptablen > Farbstich. > > Hat einer eine Idee? Da stimmt was nicht in deinem Code. Mapping auf die Bits von 7..2 (für den 6er-Kanal) bzw. 7..3 (für die beiden 5er-Kanäle) sollte exakt das gewünschte bewirken. Wenn da ein Farbstich entsteht, hast du einen Bug in deinem Code oder das Display ist Scheisse oder nicht RGB, sondern YUV.