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í?
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...
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.
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?. :-)
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!
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?
Bruno, como siempre gracias, eres un libro abierto!
No piensen que este tema quedo relegado, lo tengo siempre presente, pero tengo muchos proyectos abiertos que me estan consumiendo más tiempo.
Aparte estaba esperando que la gente de Texas me entregue las muestras delo 5940. Ayer me llegaron y estoy por empezar las pruebas. Los led RGB todavía no salieron de china (jeje), pero hasta que lleguen tengo tiempo de sobra para hacer las primeras pruebas de los TLC.
Por lo que me comentas y estuve viendo lo de procesar señales VGA no es nada simple. Creo que en principio podría suponer que la informacion está almacenada en forma digital en una memoria, quizá ya extraidos los frames.
Lo cual me lleva a enunciar nuevas preguntas. Cuales son los tipos de memorías que podrían funcionar (dado el flujo de informacion requerida) para una aplicacion de este tipo? quizá la memoria no sea el cuello de botella y la pregunta no tenga sentido, pero desconozco esta parte (como casi todo, ja) Algún documento de como se almacena un video en algún formato simple en memoria y como extraer los frames?
Lo cual me lleva a enunciar nuevas preguntas. Cuales son los tipos de memorías que podrían funcionar (dado el flujo de informacion requerida) para una aplicacion de este tipo? quizá la memoria no sea el cuello de botella y la pregunta no tenga sentido, pero desconozco esta parte (como casi todo, ja) Algún documento de como se almacena un video en algún formato simple en memoria y como extraer los frames?
Eso dependerá mucho de la resolución de pantalla que pienses hacer. Una controlador de memoria SD puede transferir varios MB/s de información utilizando protocolo SPI, y bastante más utilizando el protocolo SD. Si bien AVI es un contenedor de video y no un formato de video en si, los formatos que menos procesado requieren(sin compresión) suelen contenerse en archivos AVI. Esos son los que pueden resultar más interesantes porque si bien el tamaño del archivo es grande en comparacion a otros formatos, es menor el procesado requerido para poder utilizar su información gráfica contenida.
Si es para meros experimentos, debe haber alguna aplicación dando vueltas en la web que pueda tomar un video y extraer/guardar la información grafica RAW. No es muy complejo tampoco hacer una aplicación de PC que convierta los frames de un video a un formato propio, que sirva directamente para el propósito.
Creo que si exíste, no hay que ponerse a lidiar con ello. Incluso vendían por ebay placas PCI (conexión interna) o bien módulos independientes(por Ethernet/VGA) que directamente recibían la trama desde un soft de PC que lo único que hace es capturar toda/parte de la pantalla y enviarla.
Ah, entiendo. Yo pensaba manejar las filas con 1 salida para cada una. Pero es cierto que si son muchas filas hay que multiplexar, en cuyo caso solo hay un led por vez encendido... Bueno, esto complica más aún los tiempos imagino...
saludos
Ah, entiendo. Yo pensaba manejar las filas con 1 salida para cada una. Pero es cierto que si son muchas filas hay que multiplexar, en cuyo caso solo hay un led por vez encendido... Bueno, esto complica más aún los tiempos imagino...
saludos
Claro, cuando decía que se complicaban más los tiempos es por que suponía que al multiplexar debería refrescar la pantalla muchas más veces por segundo para no perder brillo. Esto es así? O sea, para 7 filas el duty ya es de 14% y eso no lo puedo cambiar, pero si pinto más imagenes por segundo.... no, es lo mismo, refresque a lo que refresque siempre va a estar el 14% del tiempo encendido y el resto apagado, aunque quizás halla algún efecto como de persistencia que me haga ganar brillo pintando más rápido?
Saludos
El ciclo de trabajo va a ser el mismo, sea cual fuere la frecuencia de refresco de la pantalla. Después al aumentar la frecuencia no se nota cambio en el brillo de los leds, hice la prueba (imagen de izq. a der., 60Hz, 120Hz, 240Hz), pero al aumentar la frecuencia se disminuye el tiempo que tienes para cargar los datos a cada fila y te quita tiempo para hacer otras cosas.
Saludos!
Personalmente, las matrices que hice y hago siempre están encima de los 100Hz. Idealmente arriba de los 200. Si bien a 60Hz es prácticamente imperceptible para el humano, hay cámaras donde la imágen del cartel puede grabarse mal si la velocidad de refresco es baja.
Lo que se suele hacer como remedio parcial para el problema del duty, es incrementar la potencia con que se aplica a los LEDs. Esto hace que el LED brille más, y como en este caso el LED trabaja 1/7 partes de segundo, en teoria se le da suficiente tiempo para que enfríe y no se destruya. Claro que en este caso el LED se sacrifica menos si los intervalos de encendido son menores(más Hz), hay que estar seguro que de ninguna manera una fila va a quedar permanentemente encendida (utilizando watchdog timer que resetee el uC por ejemplo en caso de que el código falle) y seguramente perdamos parte de la vida útil ideal de los LEDs.
Saludos.
Que pasión, siempre leo por aqui, me interesa mucho.
Al principio, debo reconocer que no me intersaba mucho el tema, lo leí y lo re leí, pero no le veía mucho el valor... Hasta que caí, se vincula con el tema de las resoluciones, ya que con un cartel pequeño puedo tener una resolucion tremenda... Ahora no me imagino si el pixel se forma por hardware, o software para combinar los 9 led para formar 4 pixeles... ya lo iremos desentrañando...
Otra buena noticia: TLC5947!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Con los 5940 estaba renegando para conseguir que el uC me genere la señal de clok para el pwm, la cual debía ser lo más alta posible. El 5947 ya trae el oscilador del PWM incorporado.... ni hablar de que es de 24 salidas con lo que permite 8 led rgb directos o 6 RRGB!!!!!.
Una consulta existencial, vean este módulo(ver la segunda imagen de la publicación)
Módulo en mercadolibre (http://articulo.mercadolibre.com.ar/MLA-434290547-pantalla-de-led-prontoled-outdoor-full-color-pitch12-mm-real-_JM)
Ese módulo es 1R1G1B y tiene una resolucion de 16x16 pixel. Aquí (http://www.cltchina.com/ProductView.asp?ID=28&ProSortID=1) el proveedor.
En la foto de la parte trasera hay 24 circuitos intgrados en la perisferia.... como controlan estos chinos ese módulo? Por lo que hablé con otro proveedor, se venden los gabinetes completos (5x5 = 25 módulos), por lo que cada gabinete tiene una resolucion de 80x80 pixeles, lo cuál no parece ser una cantidad complicada de manejar de forma local. Probablemente dividan (como me sugeriste Bruno) cada gabinete con su controlador (que no debe ser muy grande) y luego si, un procesador central....
En fin, como controlarán el módulo? por qué tantos integrados?
Una consulta existencial, vean este módulo(ver la segunda imagen de la publicación)
Módulo en mercadolibre (http://articulo.mercadolibre.com.ar/MLA-434290547-pantalla-de-led-prontoled-outdoor-full-color-pitch12-mm-real-_JM)
Ese módulo es 1R1G1B y tiene una resolucion de 16x16 pixel. Aquí (http://www.cltchina.com/ProductView.asp?ID=28&ProSortID=1) el proveedor.
En la foto de la parte trasera hay 24 circuitos intgrados en la perisferia.... como controlan estos chinos ese módulo? Por lo que hablé con otro proveedor, se venden los gabinetes completos (5x5 = 25 módulos), por lo que cada gabinete tiene una resolucion de 80x80 pixeles, lo cuál no parece ser una cantidad complicada de manejar de forma local. Probablemente dividan (como me sugeriste Bruno) cada gabinete con su controlador (que no debe ser muy grande) y luego si, un procesador central....
En fin, como controlarán el módulo? por qué tantos integrados?
Por aquí NANO muestra un equipo del estilo: http://www.todopic.com.ar/foros/index.php?topic=35800.0 y aquí indica que tiene cada módulo: http://www.todopic.com.ar/foros/index.php?topic=35800.msg298385#msg298385
Perfecto, bue, en alguna que otra cosita le pegué bien, je.
Confirmado lo del scan 1/2 en el módulo (http://www.cltchina.com/ProductView.asp?ID=28&ProSortID=1)que a mí me interesa.
Ahora, en cada gabinete hay 25 módulos que deben ser manejados desde el gabinete central. Si son 25 módulos sería como tener una matriz de 2 filas por 384*25=9600 LED. Si hay tres señales de datos (una para los led rojos, otra para los verdes y otra para los azules) cada "cable" debe conducir 9600/3 = 3200 "datos" para llenar un gabinete completo. Si cada "dato" está compuesto por 14bits (en las características dice "Color processing: 14bit, Display color: 4.4 trillion" estaríamos hablando de 3200*14 = 44800 bits para cada frame. En las características del panel dice: Refresh frequency: ≥ 2000Hz, Frame rate: ≥ 60Hz. El Refresh frequency sería la frecuencia del PWM de cada led?
en el caso del frame rate de 60Hz nos daría que debemos enviarle 44800bits * 60 1/seg = 2,68Mbps desde la central hacia cada gabinete? o en realidad el doble, ya que primero irían los 44800 bits de una fila y luego los de la otra fila lo que nos daría 5,37Mbps....
Saqué bien las cuentas? El hecho de que dividan las señales una para cada color aumenta el cableado, pero baja muchísimo el ancho de banda requerido...
Bueno, me conformo con, por lo menos haber entendido como funcionan, como se fabrican y que se usa para cada parte del sistema y estar en condiciones de poder empezar a diseñar uno.... evidentemente no dan los números....
Me tendré que conformar con un POV RGB entonces como proyecto....
Sea que pienses usar un PIC32 o un ARM, cualquiera te puede generar sin problemas por hardware un PWM digital de 1bit o 1.5bit de profundidad a alta velocidad. CREO que un 18F4550 podía generar, a lo sumo, un PWM de 4Mhz(12Mhz/3). Lo probé y hasta vi en el osciloscopio pero ahora no recuerdo bien. Un LPC1114 puede generar un PWM de 25Mhz máximo. En cualquier caso lo dejás corriendo, y si configuras el TLC para que autogenere el pulso de XBLANK, podés desligarte prácticamente por completo del problema. Personalmente estoy utilizando LPC1343 con 24Mhz de clock. El máximo de este micro es de 36Mhz, pero excede las características máximas de 33Mhz de clock permitido por el driver TLC.