Conexión RGB666 a RGB888 (tft lcd).

[remi04]

Edito, solucionado.   Abajo del mensaje original el resultado.



Hola a todos. Me han traído una máquina de diagnosis de motos para reparar que le han roto la pantalla. Es una pantalla 320X240 de la marca Ampire por la cual nos piden un ojo y medio de la cara. (270€ la pantallita) y ni aún así nos la suministran por que dicen que está descatalogada y no se fabrica ni tiene equivalente.   Así que le he encontrado una de Buydisplay que le va perfecta. Solo tengo que hacerle una interface que la hago en Eagle y la mando a JLPCB a hacer.   Ya tengo los conectores FPC y todo listo.

  El procesador de gráficos de la máquina es un Epson S1D13717F el cual me da los datos en formato RGB666. Es decir, 6 bits por color.

  La pantalla original lleva bus de 18 bits, 6 por color. El problema es que la que he comprado solo se puede configurar en 24 bits o en SPI.  Así que lo que quiero saber es cómo conectaríais los 6 bits que tengo a un bus de 8 bits por color, no sé si dejar el 0 y el 7 a low o los dos más bajos, o los dos más altos.   Si repartirlos por el bus, por ejemplo dejarlo así: byte = rrr0rrr0    Donde Los cero son pines que dejo en low y las r los 6 bits que vienen del chip Epson. 

   También puedo poner un micro intérprete que me convierta esa palabra de 6 bits en una de 8 por canal, pero si lo puedo evitar sería mejor..   Por dinero no es por que es una máquina que vale más de 2000€ así que al dueño del taller no le importa si tiene que pagar gastos de desarrollo y demás , hay que repararla si o si.


¿Como lo haríais?    Todavía no tengo el lcd y mientras llega es par ir leyendo sugerencias..

 

  Un saludo.

EDICION:

    Funcionó a la primera. Al final lo que he hecho ha sido dejar a cero los dos bits de menor peso de cada color. También he probado al ponerlo copiando los dos bits mas altos a los mas bajos y el resultado a simple vista es el mismo. asi que se quedaron a cero los dos de menos peso de cada color.

  Este es el resultado de la adaptación. Aparece el display original al cual el he retirado del flex todos los componentes del driver para los led´s y los he aprovechado para recolocarlos en la placa intermedia. 

 

thumbnail.jpg
(190.32 kB, 810x1080 - visto 589 veces)

Y aquí se puede ver la plaquita interface que tuve que hacer para adaptarlo.   A simple vista la plaquita me quedó de lujo. Pero que encima haya funcionado ya ha sido la reostia     Y a la primera....   

  Las dos tardes de estudio y diseño han merecido la pena.

 

thumbnail (1).jpg
(163.87 kB, 810x1080 - visto 488 veces)

       

[KILLERJC]

Si es de 6bits a 8bits yo pondria a 0 los 2 bits de menos peso. Eso siempre y cuando no afecte alguna instrucción que se le de a la pantalla.

[fuente]

No tengo mucha idea de estos temas, pero poniendo a cero los dos bits de la izquierda o de la derecha nunca se podría obtener el negro total o el blanco total ¿no?
¿no convendría entonces convertir de forma aproximada esos valores? De forma simple sería multiplicar por 4,05 (255/63) el valor de 6 bits.

[remi04]

No tengo mucha idea de estos temas, pero poniendo a cero los dos bits de la izquierda o de la derecha nunca se podría obtener el negro total o el blanco total ¿no?
¿no convendría entonces convertir de forma aproximada esos valores? De forma simple sería multiplicar por 4,05 (255/63) el valor de 6 bits.

 Si, he pensado en dejar a cero los de menos peso. En verdad el negro total si que se obtiene ya que cuando llegue un cero en los 6 bits habrá cero total en el bus .

  Lo único que si viene un “1” decimal, pues la pantalla verá un 4.   Si llega un 2, la pantalla verá un 8.  Es prácticamente lo que has puesto , multiplicar por 4.

 Lo que estamos haciendo en verdad es como :
 byte = byte << 2;

  Probaré a ver qué tal.

[remi04]

Si es de 6bits a 8bits yo pondria a 0 los 2 bits de menos peso. Eso siempre y cuando no afecte alguna instrucción que se le de a la pantalla.

 Pues eso haré.

 La verdad es que no he observado que el chip epson envíe comandos. En el osciloscopio solo veo RGB de 6 bits por color, Pixel_CLK de 7 MHZ, HSYNC y VSYNC

 De los 40 pines, 5 son para el táctil (que no lleva) por lo que están sin conectar.  18 para rgb, 8 conectados a GND,  hsync, vsync, Píxel Clock, 1 es el pwm para el driver de los led de retroiluminacion, y 5 conectados a Vdd 3v3.

  Todo lo que es configuración de barrido, gamma y demás está en el propio flex mediante resistencias.

[xocas]

  El procesador de gráficos de la máquina es un Epson S1D13717F el cual me da los datos en formato RGB666. Es decir, 6 bits por color.

En su hoja de características se mencionan 16 bits por píxel así que no descartaría que en realidad se trate de un RGB565. Aunque el bus sea de 18bits quizá dos de ellos no estén en uso, no sean significativos, o cumplan otra tarea distinta. Quizá puedas verificarlo con el osciloscopio.

Te dejo un par de enlaces de stackoverflow sobre el tema: Uno y Dos

  Lo único que si viene un “1” decimal, pues la pantalla verá un 4.   Si llega un 2, la pantalla verá un 8.

No tiene importancia, en una pantalla de esas características no se aprecia diferencia alguna entre un RGB:000 y un RGB:888. Ambos se verán negro.

Puedes trasladar los 6bits de origen a los 6bits de mayor peso en el destino y, además, tomar a su vez uno o dos bits de mayor peso en origen y copiarlos en los bits de menor peso en destino...

Es decir:
R: (MSB) 110100 (LSB) -> (MSB) 11010011 (LSB)

Con esto se mejorarían los tonos más claros.

saludo

[remi04]

  El procesador de gráficos de la máquina es un Epson S1D13717F el cual me da los datos en formato RGB666. Es decir, 6 bits por color.

En su hoja de características se mencionan 16 bits por píxel así que no descartaría que en realidad se trate de un RGB565. Aunque el bus sea de 18bits quizá dos de ellos no estén en uso, no sean significativos, o cumplan otra tarea distinta. Quizá puedas verificarlo con el osciloscopio.

Te dejo un par de enlaces de stackoverflow sobre el tema: Uno y Dos

  Lo único que si viene un “1” decimal, pues la pantalla verá un 4.   Si llega un 2, la pantalla verá un 8.

No tiene importancia, en una pantalla de esas características no se aprecia diferencia alguna entre un RGB:000 y un RGB:888. Ambos se verán negro.

Puedes trasladar los 6bits de origen a los 6bits de mayor peso en el destino y, además, tomar a su vez uno o dos bits de mayor peso en origen y copiarlos en los bits de menor peso en destino...

Es decir:
R: (MSB) 110100 (LSB) -> (MSB) 11010011 (LSB)

Con esto se mejorarían los tonos más claros.

saludo

Mira, esta es la tabla de modos de ese controlador.  La que he rodeado en rojo corresponde a la conexión que tiene este display en esta maquina.

Todo idéntico, con el desorden de los pines y todo incluido. Desorden me refiero a que por ejemplo los pines 3,4 y 5 son los bits altos del verde, mientras los 3 bits bajos los da por los pines 12,13,14.

 Pues ese esquema de conexiones de 18 bits es exactamente el que hay físicamente en la maquina.

 Lo de pasar copia de los bits altos a los bajos es como un acarreo ¿no?.  De todas formas, como bien dices no se va a notar nada y menos en esta maquina que lo que lleva son pantallas (ventanas) con botones, textos, gráficos y demás.  Al mecánico le va a dar igual que el rojo por ejemplo sea mas claro o mas oscuro.
 
   

thumbnail.jpg
(194.72 kB, 766x788 - visto 462 veces)

[xocas]

Lo de pasar copia de los bits altos a los bajos es como un acarreo ¿no?.

Supongo que es una forma de asegurar la posibilidad de un blanco absoluto, dado que no se podría obtener un valor de 255 con esos bits a 0. En la práctica estaríamos ante un caso idéntico a lo dicho para el negro ya que no sería posible diferenciar en una pantalla así un RGB:FFFFFF de un RGB:FCFCFC.

Sería algo así:

 

rgb888.png
(2.71 kB, 543x203 - visto 444 veces)

La imagen es de un procesador gráfico Nec que trabaja con varios espacios de color, pero en otros procesadores he visto que toman únicamente el valor del bit de mayor peso y lo replican en los dos de menor peso e, incluso, alguno que pasa de un RGB565 a un RGB888 replicando el bit de mayor peso de los canales RB a los tres de menor peso y del canal G a los dos de menor peso.
En la práctica no sé realmente si tendrá alguna relevancia asignarle o no un valor a estos dos bits. Ya nos contarás...

Pues será un RGB666 entonces. Lo cierto es que no sabía de su existencia siquiera, mis lecturas siempre fueron sobre el RGB565 y siempre en sentido contrario: conversión de 24bits a 16bits.

saludo

[remi04]

Lo de pasar copia de los bits altos a los bajos es como un acarreo ¿no?.

Supongo que es una forma de asegurar la posibilidad de un blanco absoluto, dado que no se podría obtener un valor de 255 con esos bits a 0. En la práctica estaríamos ante un caso idéntico a lo dicho para el negro ya que no sería posible diferenciar en una pantalla así un RGB:FFFFFF de un RGB:FCFCFC.

Sería algo así:

  - Tienes que ingresar para ver archivos adjuntos -  

La imagen es de un procesador gráfico Nec que trabaja con varios espacios de color, pero en otros procesadores he visto que toman únicamente el valor del bit de mayor peso y lo replican en los dos de menor peso e, incluso, alguno que pasa de un RGB565 a un RGB888 replicando el bit de mayor peso de los canales RB a los tres de menor peso y del canal G a los dos de menor peso.
En la práctica no sé realmente si tendrá alguna relevancia asignarle o no un valor a estos dos bits. Ya nos contarás...

Pues será un RGB666 entonces. Lo cierto es que no sabía de su existencia siquiera, mis lecturas siempre fueron sobre el RGB565 y siempre en sentido contrario: conversión de 24bits a 16bits.

saludo

  Gracias.. 

  Ya terminé la placa y ya está mandada a fabricar. Lo que he hecho ha sido ponerle unos jumper smt (de estos que se cierran o abren con una gota de estaño) para seleccionar así lo que hacer con esos bits, de modo que es fácil probar todas las opciones.

  El display ya lo tengo, ya solo queda esperar a Jlpcb, tardará mas por que lo he puesto por correos normal, no tengo prisa.

  Por DHL es directamente in-trabajable. primero por que son mas de 20€ el envío solo. Ahora sumale gastos de aduana, despacho, iva, y supervisión. Y da igual que sea un paquete de 4€. Siempre encuentran la forma de sumar cargos (Que si gastos de revision del paquete, que si el paquete resultó sospechoso y tuvieron que meterle RX y otro cargo más.  Encima, esos cargos te los suman a los 4€ del valor, se pasa de 22€ y entonces procede aplicar IVA y despacho de Iva. a lo tonto 40€ + los 20 y pico, 60€ pa 5 placas chinas.   Sinverguenzas no, lo siguiente...  Sea culpa de ellos, o de Hacienda. Me da igual.   Sinceramente, no se como hay gente que trabaja con Feddex, Dhal y demás, o como lo hacen para no salir escaldados.



 

[remi04]

Funcionando. Fotos en el mensaje inicial editado.

  Al final los dos bits de menor peso a cero.

  Saludos y gracias a todos por las respuestas..