Autor Tema: Como funcionan los carteles a LED RGB?  (Leído 21589 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado elgarbe

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2178
Como funcionan los carteles a LED RGB?
« en: 21 de Septiembre de 2012, 23:41:53 »
Buenas, soy usuario de este foro y del de neoteo, los cuales leo constantemente aunque no participe tanto (por lo menos en este).
El tema es que estoy estudiando y tratando de entender como funcionan los carteles RGB, por ejemplo los de los estadios de futbol que pasan propagandas (en Argentina).

Bueno, hasta ahora tengo lo siguiente:

    Hay paneles controlados por driver's de led con PWM incluido (se le carga la informacion con SPI o I2C) y otros en los que los drivers de los led no tienen PWM incluido, en ese caso traen señales como si fuesen un registro de desplazamiento, CLK, LE, OE y Data. Todavía no descubro que es lo desisivo entre un tipo de drive y otro. Como decido si uso uno u otro.
    El tiempo necesario para barrer un panel (aunque sea chico) en el eje horizontal + dar la informacion de PWM de cada línea es algo que lleva mucho tiempo. Para que un panel tenga colores vivos debemos tener un PWM con frecuencia mas o menos alta (mejor dicho, mayor que un panel cuyos colores no pretendamos sean muy vivos). Para obtener altas velocidades de operacion se utilizan FPGA's. Si bien lo vi por arriba en la facu, no tengo idea como se usan ni sus virtudes. Creo que lo que tienen es muchos pines de I/O y una alta velocidad de operacion.
    Me gustaría poder hacer pequeños cálculos de tiempos necesarios y velocidades de trabajo necesarios pero aún no termino de comprender como hacer dichos cálculos. Es decir si yo quisiera armar un panel de, por ejemplo, 8x32 led RGB como hago para calcular todo. Tampoco tengo muy en claro como se almacena la imagen a mostrar en una memoria....


luego de investigar un poco más y con la ayuda de usuarios de NeoTeo puede hacer el siguiente intento:

Bueno, siguiendo con la intriga del cartel RGB, si usamos el TLC5916, el cuál es un driver de corriente para led de 8 canalesque con entrada serie y salida serie (típico registro de desplazamiento) que puede operar a 25MHz, supongamos que lo usamos con un uC a 40 MHz (el uC, por ejemplo el 18F4550) y suponiendo que al TLC lo trabajamos a 20MHz tengo que entre dato y dato hay 50ns. Si tengo un cartel de 32 led RGB (96 led individuales) me tomaría unos 5 us llenar de datos los 12 TCL. Bien?

Por lo que ví, en el caso de estos driver's que no tienen PWM uno debería hacer el PWM con el uC. Entonces, suponiendo que quiero un PWM de 8 bits (16M de colores) tengo que barrer 256 veces al panel, se entiende? si quiero un pixel con medio tono rojo, 1/4 tono verde y 3/4 tono azul, entonces las primeras 64 pasadas tengo las 3 salidas en 1, luego pongo a 0 el color verde y dejo el rojo y el azul 64 barridos más, a partir de la pasada 128 apago el rojo y desde la 196 en adelante tengo todo apagado. Bueno, hacer eso me llevaría 12,8 mseg con lo que obtendría 78 fps, lo cual es muy alto, no?

voy bien? esas serían las cuentas?

Para los driver's con I2C y pwm incluido se me complican las cuentas porque no conozco de tasas del I2C.... pero ya lo averiguaré...

En fin, me gustaría recivir (y cruzar con el otro foro también) algo de info como para entender un poco más y quizás diseñar un pequeño panel de pruebas...

Saludos y gracias!
-
Leonardo Garberoglio

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Como funcionan los carteles a LED RGB?
« Respuesta #1 en: 22 de Septiembre de 2012, 02:23:49 »
Hola!

Hace años que diseño carteles a LED y hace poco menos que diseño carteles RGB full color. Tus cálculos están bastante bien, excepto en un par de lugares.

Utilizando el 18F4550, a su velocidad máxima, nos da uno 12mips(48Mhz de clock).  Si utilizamos el SPI para comunicarnos con la cascada de TLC, la velocidad máxima a la que puede correr el SPI es a 12Mhz también, lo que hace que el tiempo mínimo de envío de un bit sea de unos 84nS. Multiplicando eso por 96 nos quedaría que llenar los TLC nos costaría unos 8uS exáctamente. Ahora, para hacer PWM necesitamos hacer 255 pasos(no 256, algo nos ahorramos ahí). Eso te da que un refresco completo ocurre en 2.04mS. Eso te daría unos 490Hz,que es una buena frecuencia de refresco. El problema es que eso es ideal, y dificilmente logremos cargar los registros a esa velocidad, teniendo en cuenta que también tenemos que recibirlos y procesarlos de alguna manera antes de poder enviarlos.

Personalmente no utilizo PICs para paneles tan exigentes en recursos y velocidad, sino que uso microcontroladores ARM, que me ofrecen un rendimiento unas 10 veces más que el 18F4550, y son incluso más económicos, irónicamente.

Veo que has estado leyendo e investigando mucho sobre el tema, lo que me ha motivado a responderte. Lamentablemente hay ciertas partes de lo que hago que no puedo publicar por acuerdos de confidencialidad.

Me parece bien que empieces con una matriz relativamente chica(aunque para nada fácil). Ahora agrandando la apuesta, si pensamos en pantallas de más pixeles, como las que pasan publicidad en partidos de fútbol que mencionaste, hay dos grandes grupos. Si utilizás integrados sin generación de PWM integrada, vas a estar obligado seguramente a irte a FPGA por cuestiones de rendimiento y costos. Si pensás en seguir utilizando uC, vas a necesitar integrados que te generen el PWM a velocidades lo suficientemente altas como para poder generar el color en tiempo y forma sin grandes requisitos de procesamiento de parte del uC.

Gran parte del problema no termina siendo sólo la generacion de los grises, sino la transportación y distribución de la información gráfica entre un servidor(que suele ser una PC) y las controladoras que redestribuyen la información. Es todo un desafío y casi siempre se está ajustado. Cualquier demora hace que todo el resto no sirva.

Saludos.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado elgarbe

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2178
Re: Como funcionan los carteles a LED RGB?
« Respuesta #2 en: 22 de Septiembre de 2012, 11:53:40 »
Bruno, muchas gracias por tu respuesta!!

Es cierto que he investigado mucho, he leido unas cuantas hojas de datos de driver y he pedido algunos a TI para probar. Aún no tengo decidido armar un pequeño cartel RGB para hacer pruebas, por ahora es todo curiosidad. Estoy más orientado a intentar hacer un cartelito POV RGB para probar los driver's y su capacidad, pero lo de los carteles gigantes es una intriga muy grande que me gustaría resolver.

Me podrías comentar algo del timing para controladores con PWM incluido? estoy dandole vueltas a las hojas de datos, estudiando el I2C y aún no consigo aproximar una cuenta (como en el caso de los otros drivers).

En el caso de ARM, arquitectura que desconozco por completo, que micro puedo investigar como para arrancar con esto?

Por lo que me comentas, se puede safar de usar FPGA (otra cosa que desconozco, pero que me despierto en las noches pensando en ellas) con ARM, pero hasta que aplicación? Si es algo como las publicidades en las canchas hay que usar FPGA si o sí?

Bueno, por ahora gracias, espero alguna punta más para seguir investigando.

Saludos!
-
Leonardo Garberoglio

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Como funcionan los carteles a LED RGB?
« Respuesta #3 en: 22 de Septiembre de 2012, 15:32:19 »
Me podrías comentar algo del timing para controladores con PWM incluido? estoy dandole vueltas a las hojas de datos, estudiando el I2C y aún no consigo aproximar una cuenta (como en el caso de los otros drivers).

Son la solución a utilizar si no querés terminar con FPGA o con micros ARM de alta gama(y alta complejidad). Desconozco los que utilizan I2C. Te recomiendo los que usen SPI o simil. El I2C no suele ser muy rápido. Los SPI típicamente soportan un clock de 33Mhz para la generación de grises, y 30Mhz para la carga de datos. Estas velocidades son el standard de la industria. Las cuentas dan muy bien con esas velocidades. Con 8 bit de profundidad de color, te da que trabajan hasta a 129Khz.

En el caso de ARM, arquitectura que desconozco por completo, que micro puedo investigar como para arrancar con esto?

Podés arrancar con algún kit. Podría ser los de mbed, los de lpcxpresso, los de Texas, cualquiera. Personalmente me gustan mucho los de NXP(Philips). En argentina podés conseguir las LPCXpresso en MercadoLibre por precios entre 200 y 350 pesos. Es un kit muy interesante.

Por lo que me comentas, se puede safar de usar FPGA (otra cosa que desconozco, pero que me despierto en las noches pensando en ellas) con ARM, pero hasta que aplicación? Si es algo como las publicidades en las canchas hay que usar FPGA si o sí?

Si o si no. Seguramente podrias hacerla hasta con 16F84, pero la pregunta esta en que cantidad de integrados vas a necesitar, cuanto lugar y complejidad al circuito van a agregarle y, lo mas importante, cuanto costo adicional?
Puede que con ARM puedas arrimarte a hacer algo así, pero profesionalmente suelen llevar FPGAs. Es la solución más barata, especialmente para recibir los datos de la PC y redistribuirlos. Las pantallas chinas suelen traer drivers sin generacion de pwm incorporada. Hay un FPGA cada tanto encargandose de llenar los drivers y recibir la trama de datos por par diferencial.

Saludos.
« Última modificación: 22 de Septiembre de 2012, 15:38:12 por BrunoF »
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado elgarbe

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2178
Re: Como funcionan los carteles a LED RGB?
« Respuesta #4 en: 22 de Septiembre de 2012, 16:34:54 »
Perfecto, me queda todo mucho más claro, por lo menos la parte "gruesa" de lo que sería un proyecto de cartel RGB.

Quizá comienze a armar un cartelito como para probar algunos integrados o quizá algún sistema POV que son mas llamativos...

Al principio de todo, cuando hablamos del 18F4550 me quedaría muy justo para un cartel de, por ejemplo, 8x32. Supongo que con algún PIC24 o PIC32 podría estar más holgado, pero en ese caso la balanza se inclinaría más aún por un ARM por su costo, verdad? Entonces la principal pregunta que se desprende es poque no hay tantos usuario de ARM? Yo supongo que porque son uC que no hace mucho que están al alcance de un usuario básico...

Bueno, investigaré un poco el tema de los ARM y ya veremos si avanzo con alguna prueba. Por ahora muchas gracias!

Saludos
-
Leonardo Garberoglio

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Como funcionan los carteles a LED RGB?
« Respuesta #5 en: 22 de Septiembre de 2012, 16:58:28 »
Perfecto, me queda todo mucho más claro, por lo menos la parte "gruesa" de lo que sería un proyecto de cartel RGB.

Quizá comienze a armar un cartelito como para probar algunos integrados o quizá algún sistema POV que son mas llamativos...

Al principio de todo, cuando hablamos del 18F4550 me quedaría muy justo para un cartel de, por ejemplo, 8x32. Supongo que con algún PIC24 o PIC32 podría estar más holgado, pero en ese caso la balanza se inclinaría más aún por un ARM por su costo, verdad?

Seguramente te quede apretado. La balanza tiene que ver con lo que más te pese a vos. Por ahí con PIC24 o 32 lográs sacarlo andando en poco tiempo, y eso es lo que más pesa para vos, pese a que el costo del producto se incremente un poco, o bien te interese aprender a programar ARM(lo que te va a llevar tiempo, y tiempo = dinero) por lo que la decisión es realmente tuya. Ojo que los PICs son más fáciles de conseguir que los ARM en Argentina. Eso también es algo a tener en cuenta.

Entonces la principal pregunta que se desprende es poque no hay tantos usuario de ARM? Yo supongo que porque son uC que no hace mucho que están al alcance de un usuario básico...

Tiene que ver con varios aspectos... Es importante lo que mencionás: Las empresas que utilizan ARM como core hace poco que empezaron a poner el ojo a los hobbystas y personas freelancers que no necesariamente son parte de una corporación que está dispuesta a invertir el tiempo y dinero necesario para capacitar a sus empleados con una determinada tecnología. Por otro lado, en Argentina nunca tuvimos real acceso a los ARM, por lo que tampoco es sencillo acceder físicamente a ellos siquiera. Los encapsulados en los que vienen los ARM(casi todos en SMD, excepto contadas ocaciones, aunque ahora empresas como NXP empezaron a lanzar algunos modelos en DIP para alentar a los usuarios que no se animan a soldar SMD) también resultan desalentadores para muchos usuarios. Otro factor importante es la dificultad en aprender dicha tecnología fuera de la capacitación oficial(también ausente en Argentina). No hay cursos de ARM como los hay de PIC. El año pasado dimos un curso de ARM en Pergamino, Pcia Buenos Aires a traves de un laboratorio del cual formo parte(LIMIE), utilizando la LPCXPresso con el LPC1343, para aprender a familiarizarse con los ARM, la arquitectura von Neumann(a diferencia de un 18F4550 que utiliza Harvard) y algunos periféricos básicos como IO, Timer, UART, etc. No creo que nadie haya hecho un curso antes en Argentina basado en un ARM de NXP al menos.

Esos son algunos de los factores que hacen que ARM no sea muy utilizado en Argentina, al menos no desde cero. Seguramente muchas empresas compran placas prefabricadas con ARM para realizar productos embebidos.

El problema de programar PICs, es que muchas veces uno se hace PIC-dependiente, y no logra lanzarse a programar en microcontroladores de otra marca.

Personalmente me acerco cada vez más a los ARM y alejo para nuevos desarrollos de los PICs.

Saludos.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado elgarbe

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2178
Re: Como funcionan los carteles a LED RGB?
« Respuesta #6 en: 22 de Septiembre de 2012, 17:20:18 »
Entiendo lo que me comentas.
En mi caso en la facu no dimos PIC, dimos los motorolas, en ese momento los jk3 con la arquitectura von Neumann. Siempre me gustaron más esos micros que los pic, pero como bien dices, cuando hay que sacar algo rápido adelante (me paso en estos ultimos meses) tuve que caer en los PIC ya que hay mil puntos de información, se consiguen en cualquier kiosko, etc.
Particularmente no soy un gran programador ni de pic ni de motorola, pero me gusta mucho la programacion y aprendo muy rápido, por eso y pensando en posibles proyectos futuros quizá trate de entrar al mundo de los ARM.
Ya te estaré matando a preguntas para iniciarme...

Saludos!
-
Leonardo Garberoglio

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Como funcionan los carteles a LED RGB?
« Respuesta #7 en: 22 de Septiembre de 2012, 17:39:01 »
Bueno, yo estudié Ing. Electrónica en la UNR y realmente algo de PIC se da en alguna que otra materia, aunque muchas veces depende del profesor de la cátedra. Otros utilizaban como bien dijiste vos Motorolas, o incluso Intel.

Una cosa más a favor de los PICs es la cantidad de información disponible que hay en español. Personalmente me da lo mísmo español o inglés, pero para muchos que no se llevan bien o no saben leer en inglés, eso significa una traba más.

Saludos.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado Marioguillote

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1926
    • Servisystem
Re: Como funcionan los carteles a LED RGB?
« Respuesta #8 en: 22 de Septiembre de 2012, 18:36:43 »
Ya te estaré matando a preguntas para iniciarme...

Una cosa más a favor de los PICs es la cantidad de información disponible que hay en español.

Y otra cosa a favor es que estamos los tres a pocos kilómetros de distancia ... esto sería un tema ideal para compartir y expandir conceptos, ideas y hasta prototipos experimentales un Miércoles (o cualquier día) ¿que te parece Bruno?.  :-)

Ya te voy a estar contando de qué se trata garbe ...  ;-)

Saludos!
Mario

Desconectado elgarbe

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2178
Re: Como funcionan los carteles a LED RGB?
« Respuesta #9 en: 22 de Septiembre de 2012, 19:13:39 »
No sé porque me parece que esto será más que interesante....

Espero ansioso...

Saludos
-
Leonardo Garberoglio

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Como funcionan los carteles a LED RGB?
« Respuesta #10 en: 22 de Septiembre de 2012, 21:07:25 »
Ya te estaré matando a preguntas para iniciarme...

Una cosa más a favor de los PICs es la cantidad de información disponible que hay en español.

Y otra cosa a favor es que estamos los tres a pocos kilómetros de distancia ... esto sería un tema ideal para compartir y expandir conceptos, ideas y hasta prototipos experimentales un Miércoles (o cualquier día) ¿que te parece Bruno?.  :-)

Por supuesto que sí! Podemos coordinar y reunirnos! Estamos en tres partidos limístrofes! Cuenten conmigo!

Abrazo.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado Marioguillote

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1926
    • Servisystem
Re: Como funcionan los carteles a LED RGB?
« Respuesta #11 en: 22 de Septiembre de 2012, 21:27:17 »
No sé porque me parece que esto será más que interesante....

Por supuesto que sí! Podemos coordinar y reunirnos! Estamos en tres partidos limístrofes! Cuenten conmigo!

Sí señor ...   :-)
Se pude formar un crisol muuuuuy interesante  :)

No interrumpo más. Continúen con la charla. Todos en el foro estamos muy agradecidos de leerlos y aprender muchos conceptos sobre el tema que por cierto, es muy atrapante.

Saludos!
Mario

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 18269
    • MicroPIC
Re: Como funcionan los carteles a LED RGB?
« Respuesta #12 en: 23 de Septiembre de 2012, 02:45:21 »
Si os sentáis juntos para hablar del tema, tenéis que transmitirlo por Livestreaming, ¿vale?  :)

Desconectado elgarbe

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2178
Re: Como funcionan los carteles a LED RGB?
« Respuesta #13 en: 30 de Septiembre de 2012, 10:50:43 »
Siguiendo con este tema, estuve viendo que el 80% (mas o menos) de la información disponible en internet apunta a usar el TLC5940 como led driver. Imagino que debe haver alguno más nuevo. Mi pregunta es si alguien provó un driver un poco más nuevo.

Bien, suponiendo que hemos podido diseñar un pequeño panel de, digamos 32x32 led rgb, y queremos que reproduzca un video. Por donde viene la solucion? Por que creo que en lo que hardware refiere debe ser la parte más compleja ya que los carteles por lo general aceptan cualquier señal de entrada, super video, video compuesto, vga, etc. Alguien conoce por donde viene la solucion de esta parte?

Saludos!
-
Leonardo Garberoglio

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Como funcionan los carteles a LED RGB?
« Respuesta #14 en: 01 de Octubre de 2012, 13:07:10 »
Siguiendo con este tema, estuve viendo que el 80% (mas o menos) de la información disponible en internet apunta a usar el TLC5940 como led driver. Imagino que debe haver alguno más nuevo. Mi pregunta es si alguien provó un driver un poco más nuevo.

Sí, podés utilizar lost TLC5940 o bien algun driver similar más genérico. En su momento había investigado y había un par que vendían los chinos, que eran más económicos que el TLC5940. Creo que no tengo los modelos anotados. Si revolvés internet o ebay podés dar con algún modelo.

Bien, suponiendo que hemos podido diseñar un pequeño panel de, digamos 32x32 led rgb, y queremos que reproduzca un video. Por donde viene la solucion? Por que creo que en lo que hardware refiere debe ser la parte más compleja ya que los carteles por lo general aceptan cualquier señal de entrada, super video, video compuesto, vga, etc. Alguien conoce por donde viene la solucion de esta parte?

Por lo general, la entrada que no suele faltar nunca es la VGA. Otras implementan entrada ethernet. El resto puede ser opcional. La entrada HDMI es muy tentadora, aunque alargar el cable puede no ser tan sencillo como con VGA.

Tanto para VGA como para HDMI, por ejemplo, vienen integrados dedicados a decodificar la trama, si es que no querés hacerlo vos. Una empresa que brindaba muchas soluciones es Analog Devices(creo), aunque seguramente no es la única. Estos integrados decodifican las tramas y te envían la información digitalizada y RAW(a veces también con compresión) para que vos la utilices. Claro que vas a necesitar un dispositivo que tenga la capacidad de leer datos a esa velocidad y poder transformar,procesar y distribuir la información al resto de las placas controladoras de los paneles.

Texas Instruments había hecho hace unos años una Nota de Aplicación, en la cual utilizaba uno de sus drivers(no recuerdo si era el TLC5940 u otro) para hacer una prueba de concepto: una pantalla de 64x64px rgb(no recuerdo realmente si ese era el tamaño). Para recibir la información gráfica utilizaba un FPGA(creo que mediante conversión A/D de VGA), que era quien procesaba y distribuía la información a los controladores de porciones de pantalla, los cuales también eran FPGAs(si mal no recuerdo). Claro que casi todo(si no todo) el hardware utilizado era de su empresa. El costo de cada panel utilizando esos drivers, recuerdo que era doloroso. No lo ví competitivo en números en su momento, no sé ahora.

Saludos.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.


 

anything