Proyecto: Cartel RGB 16x256px a 8 colores

[elgarbe]

Bueno, creo que ya casi esta listo para mandar a fabricar las placas:

Esta es la controladora de 16x32 pixeles RGB:





Estos conectores que van de abajo son para "pinchar" la placa controladora sobre el panel de LEDs



Panel de led:







por supuesto que uno de los dos conectores debe ser hembra, pero no he actualizado el 3D de una de las placas 

Saludos!

[juaperser1]

Hola leonardo, tiene muy buena pinta, enorabuena.

sin embargo te voy a decir algunas cosas simplemente para que las tengas en cuenta, no te lo tomes a mal.

la placa de los led es muy grande, deberás tener cuidado con los conectores, ya que cuando se introduzca en el horno, se le palique calor, o cuando te la den fabricada, se van a producir tracciones y contracciones que pueden hacer que luego no encajen demasiado bien los conectores al ser la placa tan grande, en tu caso no son muchos conectores, pero a mi se me ha dado el caso, de en placas grandes, tener primero que poner los conectores pinchados y luego soldarlos a la placa.

en la controladora, no se aprecia muy bien, pero parece que tienes zonas que no están conectadas a nada, supongo que tu zona es capa de masa, se debe evitar que queden isletas aisladas sin conectar a la masa comun, es decir que no estén conectadas a nada.

por lo demás esta todo muy bien organizado (esto lo digo sin saber las corrientes ni frecuencias de las pistas y tal), buen trabajo

[elgarbe]

Si, lo de los conectores es una preocupacion, pero no puedo achicar la placa de leds.... voy a probar y si se complica el enganche, veré si las puedo enganchar y luego soldar.

Tengo por costumbre desactivar el "remove dead copper" porque nunca supe si era mejor dejarlo o sacarlo. hay algún motivo para eliminarlo?

saludos y gracias!

[juaperser1]

Tengo por costumbre desactivar el "remove dead copper" porque nunca supe si era mejor dejarlo o sacarlo. hay algún motivo para eliminarlo?

motivo lo hay... espero que aparezca alguien y nos lo explique a los dos .

yo lo se por que lo he visto en comentarios de el usuario "suky" (desaparecido en combate pero mítico) que decía que hay que quitarlo, y otros mucho mas duchos en la materia que yo, lo hacen y me lo han dicho aunque nunca me han explicado el por que, es lo típico que sabes por que te lo dicen, pero nadie te lo termina de explicar bien.

aunque me huelo que es tema de alta frecuencia, y no creo que a ti te afecte para nada.

[elgarbe]

Bueno, finalmente me llegaron las placas de los chinos!
Dejo unas imágenes del panel de LED y de la controladora:











Me han faltado unos componentes que pensé tenia en la empresa, pero resulta que no. Esta semana los compro y espero el dinde poder ponerme un rato con alguna placa de evaluacion de algún ARM para hacer las primeras pruebitas básicas. El cartel que tenemos que fabricar está formada por 8 de esos paneles+controladora...

Saludos!

[juaperser1]

tiene muy buena pinta, ¿han encajado bien los conectores? ¿o has tenido algún problema por las torsiones por el calor?

tengo ganas de verla en funcionando, ¿lo has soldado tu al horno? ¿o lo has mandando montar?

un saludo

[elgarbe]

tiene muy buena pinta, ¿han encajado bien los conectores? ¿o has tenido algún problema por las torsiones por el calor?

tengo ganas de verla en funcionando, ¿lo has soldado tu al horno? ¿o lo has mandando montar?

un saludo

Los conectores han ido bien de una. Pero por las dudas, seguí tu consejo y los soldé unidos.
Arme/solde todo yo. El panel de led's me esta dando un trabajo terrible con la batea. Me parece que no va a funcionar y voy a tener que mandar a soldar por ola. Los pad de los led estan muy cerca y me quedan muchos cortos. La otra placa, he comprado el stencil al mismo chino de las PCB (pcbway) y a funcionado de 10.
Hasta ahora, los stenciles para mis productos me los estaba haciendo yo, ya que en Argentina un buen stencil de inoxidable cuesta unos USD500. Ahora viendo el precio y la calidad de los stenciles de los chinos, ya me estoy haciendo una lista para comprarles todos a ellos!

Estoy con poco tiempo de escritorio así que las pruebas tendrán que esperar 1 semana más 

Saludos!

[juaperser1]

Estoy con poco tiempo de escritorio así que las pruebas tendrán que esperar 1 semana más

pues a esperar para verlo     

[elgarbe]

Bueno, me sentado un rato (llevo unas 10 horas) a ver si pruebo las placas. Me ha tocado renegar bastate, he cometido algunos errores en el diseño del hardware, por suerte todos solucionables...
el resultado hasta ahora:

ahora biene lo mejor, sentarse a escribir código para que esto se mueva y cascadear 8 paneles para el cartel.

Saludos!

[juaperser1]

  muy bien leonardo.

parece que esto va para delante, por cierto he visto que no algunas veces no se encienden algunos colores como por ejemplo en el minuto 0,17 que hay un par de led que no se encienden en azul por ejemplo.

¿esto son los problemas de hardware a los que te refieres?

¿cuanto consume?

un saludo

[Nocturno]

Ahora empieza lo divertido 

[elgarbe]

muy bien leonardo.

parece que esto va para delante, por cierto he visto que no algunas veces no se encienden algunos colores como por ejemplo en el minuto 0,17 que hay un par de led que no se encienden en azul por ejemplo.

¿esto son los problemas de hardware a los que te refieres?

¿cuanto consume?

un saludo

Si, tuve algunos problemas para soldar con la batea el panel de led's. fui corrigiendo todos los que pude y me quedaron 2 azules y un verde creo sin funcionar.
Pero los errores en hardware fueron otros. Primero la controladora del panel esta pensada para funcionar con 2 drivers de TI. El tlc5954 y el 5958. <el priero es solo on/off y el segundo trae PWM incorporado. Con el primero puedo obtener 8 colores y con el segundo puedo hacer el panel full rgb, con la ventaja de que todo el hard del pwm esta en el drive, incluso posee memoria interna para mejorar la performance en multiplexaxion 1:32. El tema es que son pines compatibles, pero no Tension compatible  Diseñé todo para el 5958 que funciona con 5V, pero el 5954 funciona hasta 3.6V... me comi ese detalle. Lo soluciono bastante fácil, sin cortar ninguna pista, pero montando un reguladorcito de 3.3V medio en el aire. Otro error mucho mas feo es que uno de los conectores de los led me quedo rotado de una placa a la otra. Cada controladora posee 2 TLC (48 salidas cada una) puestos en cascada. Entonces era de esperarse que si yo envio 0000000000000000000....1 - 000000000000000...1  (dos tandas de 48 bits con el LSB en 1 y el resto en 0) se tendría que encender el Rojo del LED 1 y el Rojo del LED 17. Cuando hice esa prueba veo que se me enciende el 1 color Rojo pero el led 32 color azul (el de la otra punta)... mire las dos placas y me di cuenta que un conector está rotado 180°. Eso lo soluciono por software, ya que tengo las pacas ya fabricadas  por suerte son pocas, vendimos 2 carteles de 8 paneles cada uno.
El error de este proyect es que lo iba haciendo de a poco, hace como 7 meses que vengo con esto poniendome de a ratos y cambiando de esquema. Pero bueno, por lo menos lo vamos a poder hacer funcionar y ya la proxima version saldra sin errores... espero...

Ahora viene un poco de desafio de software. Estoy pensando en hacer un buffer de video en la RAM y luego usando el SPI y DMA ir scando los datos. El tema acá es como codificar el texto con colore, ya que, por ejemplo si quiero encender el LED uno tengo 3 bits consecutivos que me indican el color de ese led. 001 es rojo, 010 es verde, 100 es azul, 111 es blanco, etc. Lo bueno es que el cartel vendido tiene 0 exigencia, se programa una vez y muestra 2 textos diferentes (fijos) en funcion de una entrada digital, por lo que no hay que hacer cosas en "runtime" solo almacenar los 2 mensajes y mostrar uno u otro, con colores fijos, preconfigurados...
Ahora lo que sí sería bueno es hacer las funciones lo mas genéricas posibles para poder meter efectos sin problemas.

En principio entiendo que hay 2 capas de software en este caso, una con las funciones básicas que toman el buffer y manejan la pantalla y otro grupo de funciones que se encargan de llenar ese (o esos, pueden ser 2 para modificar uno mientras se muestra el otro) buffer.

Ya ire poniendo lo que valla consiguiendo hacer.

Saludos!

[juaperser1]

Ahora viene un poco de desafio de software. Estoy pensando en hacer un buffer de video en la RAM y luego usando el SPI y DMA ir scando los datos.

uff tiene pinta de que hay que echarle horas, pero sarna con gusto no pica.

por los fallos...quien ha hecho una placa perfecta a la primera? los típicos errores que cuando te das cuenta de ellos dices...estoy tonto o que me pasa 

un saludo y gran trabajo, espero seguir viendo los avances 

[elgarbe]

Bueno, a ver si avanzamos y me ayudan a pensar parte de la implementacion del firmware.
Cada TLC maneja 16 led RGB (48 salidas) y mi módulo posee 32 led por fila (2 TLC). Los TLC reciben la señal en forma serie y tiene un modo de datos on/off y un modo configuracion. Para ello debemos enviarle 49 bits. El bit adicional dice si es un comando de configuracion o si es un datos para activar/desactivar las salidas.
Por ahora quiero ver solo la carga de datos.
El cartel que tengo que desarrollar posee 8 módulos de 32 columnas = 256 pixeles horizotales x 16 filas.
El barrido de las filas se realiza con un 74hc138 y 4 salidas del uC. Esa parte es, en principio la más simple, pongo un timer a correr para que me de una interrupcion cada XX seg (despues paso el cálculo) y en cada interrupcion hago el cambio de una fila a otra y actualizo un contador de fila actual y preparo para enviar la info de la nueva linea.
El tema que es un poco más complejo es el barrido horizontal. En mi caso tengo 49bits/TLC x 2 TLC/modulo x 8 módulos = 784 bits o lo que es lo mismo 98 bytes.
En principio el frameBuffer sería algo como uint8_t framBuff[16][98]. En cada interrupcion de cambio de fila prepararía un canal DMA para que envíe los 98 bytes por el SPI para cargar los registros de los TLC y todo listo. En el buffer tengo que tener presente que la posicion nx49 bit no es dato, sino que siempre tiene que ser un 0 para indicarle el TLC que lo que enviamos es Dato y no comando.
Bien, acá ya me da a pensar que quizá el buffer de Video, donde se configura el texto a enviar podría ser uno con los 97 bytes corridos con los datos puestos por las rutinas de mayor nivel uno a continuacion de otro y luego, por medio de una funcion separar los datos agregando el bit 49 en donde corresponda antes de enviarlo por el SPI. De ese modo podría usar funciones típicas de llenado de buffer sin tener que preocuparme por la implementacion particular del manejo de los TLC con 49 bits. Si a esto le agrego la cagada que me mandé al invertir uno de los conectores y por lo tanto al primer TLC los datos van MSB->LSB->0 y en el segundo tengo que mandar LSB->MSB->0, creo que toma más sentido aún  tener 2 buffer, uno en dode las funciones de alto nivel ponen texto y grafico en el buffer y otra funcion de bajo nivel que prepara el buffer para ser sacado por el SPI de acuerdo a lo que mi aplicacion puntual requiere.
Ahora hay una complicacion adicional que aún no tengo pensado como resolver y es el tema de los colores. Generalmente una fuente biene codificada así:

Código: C

1. // Character bitmaps for Arial Black 11pt
2. const char fnt2[] ={
3.     // @0 '!' (15 pixels wide)
4.     0b00000000, 0b00000000, //
5.     0b00000000, 0b00000000, //
6.     0b00000000, 0b00000000, //
7.     0b00000000, 0b00000000, //
8.     0b00000000, 0b00000000, //
9.     0b00000000, 0b00000000, //
10.     0b00000000, 0b00000000, //
11.     0b00000000, 0b00000000, //
12.     0b00000000, 0b00000000, //
13.     0b00000000, 0b00000000, //
14.     0b00000000, 0b00000000, //
15.     0b00000000, 0b00000000, //
16.     0b00000000, 0b00000000, //
17.     0b00000000, 0b00000000, //
18.     0b00000000, 0b00000000, //
19.  
20.     // @0 '!' (15 pixels wide)
21.     0b00000000, 0b00000000, //
22.     0b00000011, 0b10000000, //       ###
23.     0b00000011, 0b10000000, //       ###
24.     0b00000011, 0b10000000, //       ###
25.     0b00000011, 0b10000000, //       ###
26.     0b00000011, 0b10000000, //       ###
27.     0b00000011, 0b10000000, //       ###
28.     0b00000011, 0b10000000, //       ###
29.     0b00000000, 0b00000000, //
30.     0b00000011, 0b10000000, //       ###
31.     0b00000011, 0b10000000, //       ###
32.     0b00000011, 0b10000000, //       ###
33.     0b00000000, 0b00000000, //
34.     0b00000000, 0b00000000, //
35.     0b00000000, 0b00000000, //
36.  
37.     // @30 '"' (15 pixels wide)
38.     0b00000000, 0b00000000, //
39.     0b00001110, 0b11100000, //     ### ###
40.     0b00001110, 0b11100000, //     ### ###
41.     0b00001110, 0b11100000, //     ### ###
42.     0b00001110, 0b11100000, //     ### ###
43.     0b00000000, 0b00000000, //
44.     0b00000000, 0b00000000, //
45.     0b00000000, 0b00000000, //
46.     0b00000000, 0b00000000, //
47.     0b00000000, 0b00000000, //
48.     0b00000000, 0b00000000, //
49.     0b00000000, 0b00000000, //
50.     0b00000000, 0b00000000, //
51.     0b00000000, 0b00000000, //
52.     0b00000000, 0b00000000, //
53.  
54.     // @60 '#' (15 pixels wide)
55.     0b00000000, 0b00000000, //
56.     0b00000110, 0b01100000, //      ##  ##
57.     0b00000110, 0b01100000, //      ##  ##
58.     0b00000110, 0b01100000, //      ##  ##
59.     0b00111111, 0b11100000, //   #########
60.     0b00111111, 0b11100000, //   #########
61.     0b00001100, 0b11000000, //     ##  ##
62.     0b00001100, 0b11000000, //     ##  ##
63.     0b00111111, 0b11100000, //   #########
64.     0b00111111, 0b11100000, //   #########
65.     0b00011001, 0b10000000, //    ##  ##
66.     0b00011001, 0b10000000, //    ##  ##
67.     0b00000000, 0b00000000, //
68.     0b00000000, 0b00000000, //
69.     0b00000000, 0b00000000, //

Y cuando uno quiere poner un caracter en el buffer de video, simplemente tiene una funcion que toma el caracter y lo "copia" bit a bit en el buffer en la posicion deseada. Todo esto es bastante standar. El tema es que esto es si trabajamos a 1 color. Si trabajamos con 3 bits de color, entonces cada pixel (bit en la font anterior) se transforma en 3. Bien, el buffer de salida, el que usa el SPI tiene que tener el texto y la codificacion de color ya puesta. Por ejemplo encender un pixel rojo será poner 001 en el punto deseado, encenderlo verde será poner 010 y azul 100. Ahora, el buffer de video de la palicacion y la fuente no estoy seguro como codificarla. Las fuentes probablemente tenga que teneral expandidas a 3 bits por punto y tenerlas almacenadas en un color. El buffer de video de la aplicacion seguramente la tendré que tener expandida tambien y al momento de poner el caracter en el buffer tendría que recodificar la fuente para que tome el color deseado.

En resumen creo que sería un buffer de aplicacion con 2x48x8 bits en donde toda la informacion es texto y en donde por cada pixel hay 3 bits. En ese buffer escribiría la aplicacion de alto nivel, la que pone el texto y graficos. Luego una funcion intermedia que agarra ese buffer y lo reacomoda, agregando el bit 49 e invirtiendo el orden de los bits del segundo TLC de cada panel. Este buffer será tomado por el DMA que comandará al SPI para sacar todos los datos.

Bien, algunas de estas funciones, las de acomodar los bits de un buffer a otro son las que quizá podrían realizarce en ASM para ARM de acuerdo a lo que estamos conversando acá: http://www.todopic.com.ar/foros/index.php?topic=45280.0

Como ven la idea?

Saludos!

[juaperser1]

En teoría tiene buena pinta, pero es algo bastante complejo de lo que estamos hablando y que tu y solo tu tienes una comprensión total, ya un tercero, como yo, debería estudiar el hardware y el software para poder darte alguna idea que pudiera ser mejor que la tuya, que lo mismo ni siquiera la hay mejor, simplemente decir que ahora mismo el que puede decidir mejor el camino a seguir eres tu, los demás podemos ayudarte con funciones puntuales, en problemas separados, pero una idea para el proyecto general es dificil, quizá alguien que haya hecho algún proyecto parecido si que pueda decirte si es mejor como tu dices o de alguna otra manera.

Como digo en teoría, como lo explica parece coherente y bien. Experemos que en la implementación no surjan complicaciones.

Por mi parte espero poder ayudarte en algo.

Un saludo.