7'' TFT mit SSD1963: 16bit Farbmode (565-Mode) geht nicht

[Hanns-Jürgen M. (yogy)]

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

[Display Programmierer (Gast)]

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.

[Hanns-Jürgen M. (yogy)]

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:

  TFT_Write_COM8(0xB0);    //LCD SPECIFICATION
//  TFT_Write_DATA8(0x24);    // 24 Bit Mode
  TFT_Write_DATA8(0x04);    // 18 Bit Mode
  TFT_Write_DATA8(0x00);
  TFT_Write_DATA8(0x03);    //Set HDP  799
  TFT_Write_DATA8(0x1F);
  TFT_Write_DATA8(0x01);    //Set VDP  479
  TFT_Write_DATA8(0xDF);
  TFT_Write_DATA8(0x00);

Das Problem ist damit gelöst.

[Display Programmierer (Gast)]

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?

[Hanns-Jürgen M. (yogy)]

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.

[c-hater (Gast)]

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.