TODOPIC

Otros Microcontroladores / Dispositivos programables => ** PROYECTOS ** => Mensaje iniciado por: elgarbe en 30 de Octubre de 2014, 14:07:39

Título: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 30 de Octubre de 2014, 14:07:39
Bueno, quería compartir uno de los proyectos en los que estoy trabajando. Si bien el mismo es con fines comerciales y alguna que otra parte no voy a poder publicar, creo que la base electrónica puedo presentarla por completo y puede servirle a otro de base para su proyecto.

Estoy diseñando y tengo que fabricar unos carteles de led RGB de 256 columnas x 16 filas, pitch 10. El mismo NO es FULL COLOR, es decir, no controlo con PWM cada color de cada led. Puedo obtener solo 8 colores (acorde a las especificaciones que me pidieron) R, G, B, RG, RB, BG, W y B.

El proyecto lo estoy armando y aprendiendo sobre la marcha, fundamentalmente guiado (por no decir empujado) por BrunoF y tomando partes de otros proyectos (como los drive de mosfet P de Picuino). En retribucion a ellos y las demás personas que me han estado ayudando en este y otros proyectos, es que he decidido tomarme el tiempo de ir subiendo los avances.

El control de la matriz estará resuelta en un micro ARM, muy probablemente el nuevo Cortex M0+ de NXP LPC11U67 (http://www.nxp.com/documents/data_sheet/LPC11U6X.pdf). Las características que me llevan hacia este micro es la memoria flash que trae 128K, los canales DMA aplicables al SPI, el módulo USB, con drivers y API en ROM, el DFU por USB tambien en ROM y alguna que otra caracteristica más. No quiero usar un PIC ya que he decidido no pasar a ARM cualquier proyecto que normalmente resolvería con un 18F o más.

Bien, sin más paso a mostrar algunas cosas que ya tengo en esquemático.

Arranquemos por la matriz de led. He decidido hacer PCB de 16x16 LED's. Para manejar las filas me he decidido por los TLC5952 (http://www.ti.com/product/tlc5952). no conozco la linea de Linear, ni de maxim ni de otro fabricante, solo conozco los de TI y aprovechando las muestras gratis puedo testearlos y por eso me vuelco a TI. Cada TLC maneja 24 salidas en 3 grupos de 8. Cada grupo esta pensado para ser un color, por lo que podríamos manejar hasta 8 LED por TLC y en el módulo que estoy diseñando tendré 2 TLC.
Estas son imágenes del esquemático del modulo LED:

los 256 LED del módulo:

(https://farm4.staticflickr.com/3944/15667758915_29380a1ced_z.jpg) (https://flic.kr/p/pSvmSp)

detalles del conexionado matricial:

(https://farm6.staticflickr.com/5607/15481101509_facc855cb5_z.jpg) (https://flic.kr/p/pA1G8g)

drive de los LED:

(https://farm8.staticflickr.com/7565/15481788987_6752d109e2_z.jpg) (https://flic.kr/p/pA5duk)

PCB:

(https://farm6.staticflickr.com/5598/15668567132_ba6ccc32f2_z.jpg) (https://flic.kr/p/pSzv8b)

El esquemático de los LED es inmanejable. Estoy viendo de hacerme un ratito para transformarlo en estructura jerárquica con los Sheet Symbol y demás, pero por ahora es lo que hay y está bien.

El PCB intentaré hacerlo simple faz, reemplazando los típicos puentes por resistencias de 0ohm TH, las cuales puedo preformar (doblar y cortar "patas") con una máquina.

Como el cartel es de 2.5 mts y la señal de del SPI rondará los 1.5MHz, he decidido (por sugerencia de Bruno) colocar inversores schmitt en las señales CLK, DATA y LATCH para reacondicionar las mismas. La idea es hacer los módulos standar, por lo que en el módulo habrá lugar para los inversores y estará la posibilidad de bypass de ellos, para colocarlos en 4 o 5 módulos.

Ahora estoy trabajando en el sistema de control de las filas, luego subiré lo que voy diseñando.

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 30 de Octubre de 2014, 15:02:10



Toda esa tremenda complejidad, se queda en nada, si usas leds digitales, solo necesitas el micro y los leds, eso es todo, ni chips controladores, ni transistores, ni mosfet.

Yo antes también usaba chips de ese tipo, en concreto el TLC5940, pero ya hace tiempo que rediseñé todas mis placas, y son unas cuantas, para usar leds digitales, lo simples que se me han quedado todos los diseños es espectacular, además con los leds digitales puedes controlar individualmente cada led tanto su brillo como su color (más de 16 millones de colores), sin necesidad de refrescar constantemente todos los leds, salvo que alguno cambie su estado.

Lo interesante es que no hace falta ninguna electrónica de potencia, y todo se controla con un solo hilo para datos, más masa y positivo. Si necesitas añadir más leds, simplemente los conectas en cadena al último y a funcionar.

Supongo que el problema será la dificultad para conseguir este tipo de leds en Argentina, creo que ya lo comentaste una vez, pero si los puedes conseguir vale la pena, yo hace ya tiempo que dejé de usar la configuración típica de TLC + transistores de potencia, para controlar leds en matriz, y te ahorras mucho tiempo en los diseños, ensamblaje y programación.



Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 30 de Octubre de 2014, 15:38:21



Toda esa tremenda complejidad, se queda en nada, si usas leds digitales, solo necesitas el micro y los leds, eso es todo, ni chips controladores, ni transistores, ni mosfet.

Yo antes también usaba chips de ese tipo, en concreto el TLC5940, pero ya hace tiempo que rediseñé todas mis placas, y son unas cuantas, para usar leds digitales, lo simples que se me han quedado todos los diseños es espectacular, además con los leds digitales puedes controlar individualmente cada led tanto su brillo como su color (más de 16 millones de colores), sin necesidad de refrescar constantemente todos los leds, salvo que alguno cambie su estado.

Lo interesante es que no hace falta ninguna electrónica de potencia, y todo se controla con un solo hilo para datos, más masa y positivo. Si necesitas añadir más leds, simplemente los conectas en cadena al último y a funcionar.

Supongo que el problema será la dificultad para conseguir este tipo de leds en Argentina, creo que ya lo comentaste una vez, pero si los puedes conseguir vale la pena, yo hace ya tiempo que dejé de usar la configuración típica de TLC + transistores de potencia, para controlar leds en matriz, y te ahorras mucho tiempo en los diseños, ensamblaje y programación.


Si, son muy dificiles de conseguir por acá. Tambien tengo entendido que solo los hay en formato 5050, con 120º de apertura. En este caso, el cartel debe poder ser visto desde unos 30-50mts en un ambiente industrial (con polucion) por lo que usamos led bastante cerrados.
Desde que me comentaste de esos led (en el post del POV) que estoy tratando de conseguir algunos para testearlos y no lo estoy consiguiendo...

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 30 de Octubre de 2014, 15:41:54
Una pregunta que me causa curiosidad y viene de mi ignorancia, el otro dia estaba viendo estos integrados TLC, y me encontre  con que exactamente eran 8 canales RGB o 16 canales on/off o habia mas y me ponia a pensar la cantidad inmensa de esos necesario para hacer algo, ahora veo y creo que lo multiplexa linea a linea. No baja demasiado el brillo del led ?, Ya que el controlador lo hace a traves de un PWM + el barrido de filas debe quedar bajito :/.

Y a los leds digitales te referis a estos ?
http://www.mikrocontroller.net/attachment/180459/WS2812B_preliminary.pdf
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 30 de Octubre de 2014, 16:09:10
Una pregunta que me causa curiosidad y viene de mi ignorancia, el otro dia estaba viendo estos integrados TLC, y me encontre  con que exactamente eran 8 canales RGB o 16 canales on/off o habia mas y me ponia a pensar la cantidad inmensa de esos necesario para hacer algo, ahora veo y creo que lo multiplexa linea a linea. No baja demasiado el brillo del led ?, Ya que el controlador lo hace a traves de un PWM + el barrido de filas debe quedar bajito :/.

Y a los leds digitales te referis a estos ?
http://www.mikrocontroller.net/attachment/180459/WS2812B_preliminary.pdf

El multiplexado es 1 en 16 por lo que el brillo baja un poco. En este caso no hay PWM, como dije al principio solo 8 colores.

Esos son los led digitales.
No comprendo bien el tema de las velocidades. En mi caso son 4096 LED, que refresco se consigue con estos led's? porque veo que dice 800Kbps, en mi caso serían 72bits por led * 256 LED por fila = 18432bits. Si 800.000 bits necesitan 1seg, 18.432 necesitan 23mseg o sea 43Hz. Saco bien las cuentas?

Saludos
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 30 de Octubre de 2014, 16:24:18
Son 24 bits por led en el caso ese , en esos 24 bits estan los 8bit de cada color.
Para tus 256 leds = 6144 bits

7.68mS por fila  ( 6144 bits / 800000 bits/s ). Taza de refrezco (1/7.68mS ) = 130.2Hz por fila

o

0.12s (7.68mS * 16) todo el cartel. Taza de refrezco (1/0.12s) 8.1Hz ?

Estaba pensando que depende el tema ese de la tasa de refresco, depende si mandas por un solo canal o por mas, la placa de desarrollo que compre de TI tiene un TM4C1294NCDPT (no recuerdo los ultimas letras muy bien) y hay una opcion SPI que te permite mandar de a 4 datos al mismo tiempo si son todos configurados como salidas (QSSI creo q le llaman). Con lo cual la taza de refresco del cartel/tablero se multiplicaria por 4 con un solo modulo SSI (SPI), si usas mas modulos se vuelve aun mas rapido. + DMA y entonces tenes el micro libre para hacer mas nada xD

Ahora si se quema un solo led te deja toda la linea sin leds ? xD

Con el TLC vi que tiene una velocidad maxima de 35Mhz  (Data shift clock frequency).
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 30 de Octubre de 2014, 16:41:17
Son 24 bits por led en el caso ese , en esos 24 bits estan los 8bit de cada color.
Para tus 256 leds = 6144 bits

7.68mS por fila  ( 6144 bits / 800000 bits/s ). Taza de refrezco (1/7.68mS ) = 130.2Hz por fila

o

0.12s (7.68mS * 16) todo el cartel. Taza de refrezco (1/0.12s) 8.1Hz ?

Bien, por eso digo, es una frecuencia muy pero muy pobre....

Ahora si se quema un solo led te deja toda la linea sin leds ? xD

ese es el talon de aquiles, se quema un chip y fuiste, a no ser que sean chips de marca no sé si los pondría en un producto final.

Abría que ver que resultados les dio a Planeta99999999999 y en que ambiente los usó....

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 30 de Octubre de 2014, 20:18:53
Bueno, sigamos con el cartel "tradicional".
Estos son los cálculos de velocidad y ancho de banda necesarios:
El tlc5925 tiene 24 salidas para manejar 8 led rgb sin pwm. Entonces son 8led x tlc. Son 256 led, con lo que necesito 32 tlc. Cada tlc necesita 25 bits de datos (1 bit indica si es dato o control). Por lo que tengo 800bits por fila. Son 16 filas por lo que necesitamos 12800 bits para llenar el cartel. Si quiero un refresco de 100hz serán 1.280.000 bits por segundo. Poniendo el spi a 1.28MHz tendria los tiempos bien.

Veamos que pasa con la activacion de las filas. Como los TLC son sink, los led tienen que ser de ánodo común y necesitamos un mosfet P para cada fila. En el peor de los casos, si todos los led de la fila estan encendidos tendremos 256 x 3 x 0.02mA = 15.36A. Por lo que el mosfet debe poder manejar esa corriente. En cuanto a la potencia, cada mosfet estará encendido 1/16 del tiempo total. Si elijo un IRF9540, que tiene una Rds=0.117 ohm, tendremos una potencia de 15.36 * 15.36 * 0.117 / 16 = 1.72W El encapsulado TO-220 generalmente llega a 2W con un pequeño disipador, por lo que estaríamos bien. Pondremos una tira de aluminio a modo de disipador uniendo todos los mosfet.

El circuito del drive del gate de cada mosfet es el sugerido por picuino, con el agregado de la R de gate para probar la mejor condicion, con R=0 o con R=a algun valor bajo.
Este es el esquema:

(https://farm6.staticflickr.com/5601/15669941375_7c7aaa183f_z.jpg) (https://flic.kr/p/pSGxD2)

Ese esquema es el nivel bajo de un sistema jerárquico. Ver que tiene 3 ports, los cuales permitiran conexiones individuales al momento de repetir el circuito.

La idea para barrer las filas es usar otro registro de desplazamiento, un 74hc595 para usar solo 3 pines del micro y no 16 para encender uno a uno los mosfet.
Entonces esa parte del circuito quedará de la siguiente forma:

(https://farm8.staticflickr.com/7563/15483808878_81f92d60ce_z.jpg) (https://flic.kr/p/pAfyW3)

Aqui, entonces, he usado la funcion Place -> Sheet symbol y eligiendo la hoja donde esta el drive. Luego usando el comando REPEAT en los port podemos definir la cantidad de repeticiones que queremos del drive, en este caso 16.
En este esqumático tengo los 595, cada salida conectada a una entrada de un drive. Ambos estan conectados en cascada y con las señales CLK, DATA y LATCH los podemos manejar.

En el nivel superior de la estructura tengo el esquemático donde está el uC, en este caso un LPC11U67 (aunque no descarto usar un 1347). El esquemático de esta parte la estoy trabajando, y hasta ahora es esto:

(https://farm8.staticflickr.com/7509/15646327406_6d3a278d60_z.jpg) (https://flic.kr/p/pQBw2C)

Bueno, veamos un poco la parte de ruteo. Un punto importante de usar sheet symbol es que en el PCB se agrega un room por cada repeticion que hayamos configurado y acomodando y ruteando 1 solo room luego podemos copiar las propiedades y pegarlas en cada uno de los otros room:

(https://farm4.staticflickr.com/3953/15670941452_b5b1bf91cd_z.jpg) (https://flic.kr/p/pSMEVJ)

Bueno, por ahora eso es lo que tengo.

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 30 de Octubre de 2014, 20:54:25
En los 74hc595

Pense que ibas a unir ambos clocks, tendrias el dato retrasado en 1, es decir mostrarias en el pulso de reloj 17 y de ahi en adelante en 16, o si mandas un 0 y luego en 16.
Asi tenes 2 pines nomas:

1pin para la señal de CLK (ambos)
1pin para Datos

A no ser que quieras que sea posible el mantener fija la salida. igual sigo atento al proyecto :)
Y solo aporto dudas xD
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 30 de Octubre de 2014, 21:10:59
Esa parte no la pense demaciado aún. Lo del latch lo pense por que al dar energía no sé si el estado de los registros de deslpazamiento estan bien determinados o pueden tomar cualquier valor. Si al arrancar son siempre 0, entonces podría dejar activada LATCH. Tambien podría dejarla activada y lo más rápido posible llenar de 0's los registros. Luego meto un 1 en data, doy un clk y ahi ya solo manejo la señal de clk 16 veces... El LATCH me da un poco más de seguridad al manejarlo yo.

Toda duda, crítica y aporte es bien venida, ya que es el primer cartel que diseño.

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 31 de Octubre de 2014, 12:13:57
Ahora si se quema un solo led te deja toda la linea sin leds ? xD

ese es el talon de aquiles, se quema un chip y fuiste, a no ser que sean chips de marca no sé si los pondría en un producto final.
Abría que ver que resultados les dio a Planeta99999999999 y en que ambiente los usó....
Saludos!


A mi me han funcionado bien, no he tenido ningún problema, solo es recomendable conectar una resistencia de 1K entre el PIC y el primer led, y colocar los condensadores de desacoplo, al menos uno cada 3-4 leds, no es necesario conectar uno por led, salvo que estuvieran muy alejados entre si.

Obviamente, como van conectados en cascada, si cae un led, todos los que van a continuación dejan de funcionar.


Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 31 de Octubre de 2014, 13:13:50
A mi me han funcionado bien, no he tenido ningún problema, solo es recomendable conectar una resistencia de 1K entre el PIC y el primer led, y colocar los condensadores de desacoplo, al menos uno cada 3-4 leds, no es necesario conectar uno por led, salvo que estuvieran muy alejados entre si.

Y con el tema del resfrezco de los leds ? es aceptable ?
Al menos veo que con el micro que tengo si uso las 4 salidas de cada uno de los 4 modulos SPI, estaria refrescandolos a 130Hz el tablero, pero si voy a un solo SPI de los que tienen 1 salida ya cae a 8.1Hz :/
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 31 de Octubre de 2014, 14:03:49
A mi me han funcionado bien, no he tenido ningún problema, solo es recomendable conectar una resistencia de 1K entre el PIC y el primer led, y colocar los condensadores de desacoplo, al menos uno cada 3-4 leds, no es necesario conectar uno por led, salvo que estuvieran muy alejados entre si.

Y con el tema del resfrezco de los leds ? es aceptable ?
Al menos veo que con el micro que tengo si uso las 4 salidas de cada uno de los 4 modulos SPI, estaria refrescandolos a 130Hz el tablero, pero si voy a un solo SPI de los que tienen 1 salida ya cae a 8.1Hz :/

130HZ es mas que aceptable. 8.1Hz no sirve.
No se bien como hace para sacar diferentes datos por los 4 pines del SPI... abría que ver qué se puede hacer con pines comunes. Porque fijate que no son datos de SPI (clock + dato) son datos series de 1 wire, habria que ver si el micro se puede configurar para tener varias salidas con ese protocolo...
Quien sabe planeta como los ha manejado y que cantidad ha puesto...

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 31 de Octubre de 2014, 14:21:21
A mi me han funcionado bien, no he tenido ningún problema, solo es recomendable conectar una resistencia de 1K entre el PIC y el primer led, y colocar los condensadores de desacoplo, al menos uno cada 3-4 leds, no es necesario conectar uno por led, salvo que estuvieran muy alejados entre si.

Y con el tema del resfrezco de los leds ? es aceptable ?
Al menos veo que con el micro que tengo si uso las 4 salidas de cada uno de los 4 modulos SPI, estaria refrescandolos a 130Hz el tablero, pero si voy a un solo SPI de los que tienen 1 salida ya cae a 8.1Hz :/


Depende de lo que entiendas por refresco, estos leds mantienen su estado sin necesidad de refrescarlos cada x tiempo, a diferencia de las matrices que si tienes que refrescar a cierta velocidad para que no parpadeen y se mantenga el efecto de persistencia. Los leds digitales SOLO tienes que recargarlos cuando necesites que alguno de ellos cambie su estado, mientras se mantienen encendidos con los niveles RGB que les hayas cargado.

No he tenido necesidad de gestionar miles de leds, tengo placas con 49 y 132 leds, y otro diseño con leds montados en placa cada una con su controlador WS2811 (que es el mismo que llevan los WS2812B dentro). Con esta cantidad de leds y un solo puerto SPI no hay problemas para generar efectos a una velocidad razonable, no he calculado cuantos frames por segundo porque no he visto que me den problemas en ese aspecto.

En mi placa controladora tengo 2 salidas SPI y una tercera con puertos normales que se podrían usar con leds de 4 hilos, que requieren señal de reloj.



Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 31 de Octubre de 2014, 14:28:02
No se bien como hace para sacar diferentes datos por los 4 pines del SPI... abría que ver qué se puede hacer con pines comunes. Porque fijate que no son datos de SPI (clock + dato) son datos series de 1 wire, habria que ver si el micro se puede configurar para tener varias salidas con ese protocolo...
Quien sabe planeta como los ha manejado y que cantidad ha puesto...

Saludos!


No he probado todavía con varios puertos SPI, pero toda la gestión de los datos la hace DMA, el micro queda libre para otras tareas, en mi caso para leer más datos de una tarjeta micro SD. Apenas tengo experiencia con DMA, supongo que se podran configurar varios SPI+DMA, pero no lo se.



Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 31 de Octubre de 2014, 14:29:58
Yo pense SPI para que fuera de una manera serial y ya tenia salida de clk.

En el DMA estarias mandando el dato a los puertos directamente desde una memoria ?
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 31 de Octubre de 2014, 14:39:54

Los WS2812B no utilizan señal de reloj, solo tienen 1 hilo de datos. Hay otros leds a 4 hilos que si precisan señal de reloj, tengo algunos que les compré a los chinos, pero no los he probado todavía con mi placa, si los probé con una controladora china.

Me he basado en las rutinas de Henriks, están muy bien documentadas, ahí puedes ver exactamente como funciona la gestión SPI+DMA: http://blog.gitmi.com/interfacing-ws2812b-ws2811-rgb-leds-with-a-pic32mx-250f128b-micro-controller-spi-700-khz-update-3/

La ventaja de usar DMA, es que te libera el PIC para que pueda hacer otras tareas, mientras el envío de datos por SPI se gestiona por si solo. Yo los datos no los guardo ni en RAM ni en Flash, los tengo en archivos almacenados en tarjetas micro SD, que lee el PIC según los efectos que necesite sacar, así además es muy fácil de actualizar y añadir nuevos efectos, y dispones de gigas de espacio para datos (32GB en FAT32).

Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 31 de Octubre de 2014, 15:13:52
Si entiendo. Lo que no me queda claro por que todavia no me puse a jugar nunca con DMA es si vos, lees la SD esa lectura queda en tu RAM y de alli va cargando el DMA. Al menos creo que asi funcionaria. DMA vs yo , no nos llevamos muy bien xD por que nunca me maneje con eso :/

Si vi que algunos hacen lo contrario, por ejemplo del ADC a una posicion de memoria.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 31 de Octubre de 2014, 15:39:42


Si claro, cuando lees un registro de un archivo de la SD, tiene que ir a parar a una variable en RAM. En mi caso, leo varios registros del archivo, los cargo en una matriz y de ahí se alimenta la rutina que gestiona DMA+SPI para controlar los led.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 31 de Octubre de 2014, 16:12:08
Si entiendo. Lo que no me queda claro por que todavia no me puse a jugar nunca con DMA es si vos, lees la SD esa lectura queda en tu RAM y de alli va cargando el DMA. Al menos creo que asi funcionaria. DMA vs yo , no nos llevamos muy bien xD por que nunca me maneje con eso :/

Si vi que algunos hacen lo contrario, por ejemplo del ADC a una posicion de memoria.

Depende del micro. Hay micros que permite DMA entre periféricos, sin pasar por RAM (LPC1769, um10360.pdf, p588, s 34.1.1)

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 31 de Octubre de 2014, 16:31:18
Depende del micro. Hay micros que permite DMA entre periféricos, sin pasar por RAM (LPC1769, um10360.pdf, p588, s 34.1.1)

Saludos!

Vi el datasheet, lo que si:
The DMA controller allows peripheral-to memory, memory-to-peripheral, and memory-to-memory transactions.

el peripheral-to peripheral , imagino que lo hace  peripheral-to memory y memory-to-peripheral como en un solo paso :P
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 31 de Octubre de 2014, 16:55:58
Depende del micro. Hay micros que permite DMA entre periféricos, sin pasar por RAM (LPC1769, um10360.pdf, p588, s 34.1.1)

Saludos!

Vi el datasheet, lo que si:
The DMA controller allows peripheral-to memory, memory-to-peripheral, and memory-to-memory transactions.

el peripheral-to peripheral , imagino que lo hace  peripheral-to memory y memory-to-peripheral como en un solo paso :P


31.4.1 DMA controller functional description
The DMA Controller enables peripheral-to-memory, memory-to-peripheral,
peripheral-to-peripheral, and memory-to-memory transactions. Each DMA stream
provides unidirectional serial DMA transfers for a single source and destination. For
example, a bidirectional port requires one stream for transmit and one for receive. The
source and destination areas can each be either a memory region or a peripheral, and
can be accessed through the AHB master. Figure 134 shows a block diagram of the DMA
Controller.

"User manual Rev. 3 — 19 December 2013"

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 31 de Octubre de 2014, 17:26:36
Ahi lo encontre que raro recien lo busque y no hubo forma de encontrarlo :/.
Exactamente en la pagina anterior dice lo que puse, por eso mi confusion.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 01 de Noviembre de 2014, 10:33:07
Bueno, seguimos avanzando con el ruteo y buscando la mejor posicion para los componentes.
Los mosfet los puse en doble hilera de a 8 y la idea es salir con conectores tipo los de las viejas fuentes de PC's. Cada conductor debe soportar picos de 16A.
La parte problemática es el Vcc que viene desde la fuente y alimenta los D de los MOSFET, ya que esa pista debe soportar 16A. Por lo que he decidido hacerla con un buen polygon plane y seguramente dejare la parte del polígono que va a los bornes descubiertos para completar con estaño.

Bueno, va quedando mas o menos así:

(https://farm6.staticflickr.com/5607/15679084071_2d43572a5d_z.jpg) (https://flic.kr/p/pTvprH)

Abajo se ven los registros de desplazamiento que activarán secuencialmente cada Fila.

Unos render:

(https://farm9.staticflickr.com/8405/15495841518_2e26cb285f_z.jpg) (https://flic.kr/p/pBjePm)

(https://farm8.staticflickr.com/7553/15682822342_25d5be85d5_z.jpg) (https://flic.kr/p/pTQyGE)

Esa placa por ahora mide 100x150 por lo que creo vengo bien con el tamaño.

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: BrunoF en 01 de Noviembre de 2014, 14:04:00
Una pregunta que me causa curiosidad y viene de mi ignorancia, el otro dia estaba viendo estos integrados TLC, y me encontre  con que exactamente eran 8 canales RGB o 16 canales on/off o habia mas y me ponia a pensar la cantidad inmensa de esos necesario para hacer algo, ahora veo y creo que lo multiplexa linea a linea. No baja demasiado el brillo del led ?, Ya que el controlador lo hace a traves de un PWM + el barrido de filas debe quedar bajito :/.

Y a los leds digitales te referis a estos ?
http://www.mikrocontroller.net/attachment/180459/WS2812B_preliminary.pdf

Por eso se "castiga"al LED y se usa un voltaje superior al que el LED normalmente soportaría. Yo uso 12V con LEDs que son de 2V. Si el refresco es rápido, y se tiene en cuenta algunas medidas de seguridad (WatchDog Timer, etc) para que no quede nunca encendido siempre un LED, podés castigarlo ya que el LED enciende por sólo un breve instante de tiempo, y luego tiene tiempo de enfriarse durante el encendido de las otras filas. Esto se puede realizar especialmente cuando el controlador es por corriente, como los TLC.

Esa parte no la pense demaciado aún. Lo del latch lo pense por que al dar energía no sé si el estado de los registros de deslpazamiento estan bien determinados o pueden tomar cualquier valor. Si al arrancar son siempre 0, entonces podría dejar activada LATCH. Tambien podría dejarla activada y lo más rápido posible llenar de 0's los registros. Luego meto un 1 en data, doy un clk y ahi ya solo manejo la señal de clk 16 veces... El LATCH me da un poco más de seguridad al manejarlo yo.

Toda duda, crítica y aporte es bien venida, ya que es el primer cartel que diseño.

Saludos!

Sinceramente no me preocupo por el estado inicial de los controladores en cascada, ya que apagando todas las filas al inicio del encendido, hace que el valor inicial de la cascada no sea relevante.

Saludos.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: javieritone1 en 05 de Noviembre de 2014, 15:48:34
Hola! Vengo leyendo con mucha atención este post.


Por eso se "castiga"al LED y se usa un voltaje superior al que el LED normalmente soportaría. Yo uso 12V con LEDs que son de 2V. Si el refresco es rápido, y se tiene en cuenta algunas medidas de seguridad (WatchDog Timer, etc) para que no quede nunca encendido siempre un LED, podés castigarlo ya que el LED enciende por sólo un breve instante de tiempo, y luego tiene tiempo de enfriarse durante el encendido de las otras filas. Esto se puede realizar especialmente cuando el controlador es por corriente, como los TLC.


La pregunta que me surge es, ¿cómo saber en cuánto se incrementa la luminosidad del led aplicando más tensión? En las hojas de datos de los leds (al menos los que he mirado) no viene cómo calcularlo...

Por otro lado,
 

Como el cartel es de 2.5 mts y la señal de del SPI rondará los 1.5MHz, .... (...)


No logro entender por qué el SPI rondará los 1.5 MHz. Según las especificaciones de la LPC11U6x: "SPI master (in SPI mode) Tcy(clk) when only transmitting = 40 ns". Eso nos daria un SPI de 25 MHz, ¿no? Aquí hay algo que se me escapa.

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 05 de Noviembre de 2014, 16:45:01

No logro entender por qué el SPI rondará los 1.5 MHz. Según las especificaciones de la LPC11U6x: "SPI master (in SPI mode) Tcy(clk) when only transmitting = 40 ns". Eso nos daria un SPI de 25 MHz, ¿no? Aquí hay algo que se me escapa.

Saludos!

http://www.todopic.com.ar/foros/index.php?topic=43643.msg361598#msg361598

Ahi al comienzo hace los calculos para una taza de refresco de 100Hz dandole unos 1.28Mhz, puede usarlo mas rapido pero no lo necesita, y de usarlo mas rapido me imagino ya con el tema del ruteo/impedancias ademas de ser tan largo. No se exactamente a que punto de la frencuencia empieza a importar esto. Nunca tuve problemas hasta ahora ya que no trabaje con tanta frecuencia xD
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 07 de Noviembre de 2014, 15:35:01
Hola! Vengo leyendo con mucha atención este post.


Por eso se "castiga"al LED y se usa un voltaje superior al que el LED normalmente soportaría. Yo uso 12V con LEDs que son de 2V. Si el refresco es rápido, y se tiene en cuenta algunas medidas de seguridad (WatchDog Timer, etc) para que no quede nunca encendido siempre un LED, podés castigarlo ya que el LED enciende por sólo un breve instante de tiempo, y luego tiene tiempo de enfriarse durante el encendido de las otras filas. Esto se puede realizar especialmente cuando el controlador es por corriente, como los TLC.


La pregunta que me surge es, ¿cómo saber en cuánto se incrementa la luminosidad del led aplicando más tensión? En las hojas de datos de los leds (al menos los que he mirado) no viene cómo calcularlo...



El led no funciona por tension, funciona por corriente. Es un diodo, por lo que la tension Vf se establece según la corriente que le hagas pasar. El problema es que en los led, tipicamente, la corriente nominal es de 20mA y el absolute maximum rating es 25mA, por lo que no hay mucho para jugar...

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 18 de Noviembre de 2014, 11:31:31
Estoy terminando el harware alrededor del micro y me surge una duda medio software medio hardware.
Cual sería la forma "standar" de cargar el texto a mostrar en el cartel?
Yo tengo previsto una conexion USB y un pequeño programita en .net para crear el texto y efecto. Pero una vez que tengo los datos, como podría cargarlos al cartel? tendria que implementar usb cdc en el micro? de USB nunca hice nada de nada... cuando la pc quiere mandar info, el micro detecta ese evento? si consigo hacer esto, luego quedaría almacenar la info que voy reciviendo en la flash del micro o en una memoria tipo i2c externa... ahora, no logro imaginarme la mejor forma de implementar esta parte del proyecto....

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 18 de Noviembre de 2014, 11:51:51
ahora, no logro imaginarme la mejor forma de implementar esta parte del proyecto....

Saludos!


Un zócalo para tarjetas micro SD.

Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 18 de Noviembre de 2014, 13:15:48
A mi gusto iria con USB y estaria en la misma que vos. Todo depende a donde apuntas
Si es para vender creo que seria mejor por USB, conectar un pendrive que cargue el programa y listo. Que sea simple para el cliente.

Las veo media fragiles a las SD xD y mas una micro SD donde cada ves que quieras cambiar el programa tenes que sacarla y volverla a poner(demasiado chiquitas para tanto manejo).

Pero bueno eso siguiendo tu logica de cargarlo a una EEPROM, pero si fueras a cargarlo directamente desde la SD entonces no queda otra xD.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 18 de Noviembre de 2014, 13:18:10
ahora, no logro imaginarme la mejor forma de implementar esta parte del proyecto....

Saludos!


Un zócalo para tarjetas micro SD.



aunque el archivo a levantar/leer pese 200kb?

sds!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 18 de Noviembre de 2014, 13:25:08
A mi gusto iria con USB y estaria en la misma que vos. Todo depende a donde apuntas
Si es para vender creo que seria mejor por USB, conectar un pendrive que cargue el programa y listo. Que sea simple para el cliente.

Las veo media fragiles a las SD xD y mas una micro SD donde cada ves que quieras cambiar el programa tenes que sacarla y volverla a poner(demasiado chiquitas para tanto manejo).

Pero bueno eso siguiendo tu logica de cargarlo a una EEPROM, pero si fueras a cargarlo directamente desde la SD entonces no queda otra xD.

el programa cambia muy de vez en cuando. es un desarrollo de un cartel para produccion hecho a medida. En principio estaba especificado ir con la PC y conectarse con el cable usb, pero si pudiese conectar un pendrive, que el cartel levante el archivo y luego lo extraiga electricamente sería interesante, aunque creo complejo, no? para eso el micro debería tener USB OTG, verdad?

lo de la SD no me termina de gustar por que es para la industria metalúrgica y en el lugar hay mucha polucion y no estoy muy seguro de quien va a encargarse de cargar la SD...

sds
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 18 de Noviembre de 2014, 13:30:00
ahora, no logro imaginarme la mejor forma de implementar esta parte del proyecto....

Saludos!


Un zócalo para tarjetas micro SD.



aunque el archivo a levantar/leer pese 200kb?

sds!


La tarjeta SD, puede tener múltiples aplicaciones, yo en mis placas la utilizo para actualizar el firmware y también como disco duro para almacenar configuraciones de arranque o guardar archivos de efectos si manejo leds. Con 32GB en FAT32, tienes una capacidad de almacenamiento tremenda, muy superior a cualquier memoria I2C o a la propia flash del micro.

En cuanto a los 200K que comentas, una cosa es que te refieras al firmware, y otra que utilices archivos de texto para guardar efectos que puedes reponer con mucha comodidad. En mis placas con LEDs, los archivos de efectos, no son binarios de ejecución directa, tienen lineas de texto que indican que rutinas ejecutar, en que orden, pasando parámetros sobre tiempos, colores, repeticiones. Las rutinas básicas, las tengo en la flash, solo si quiero crear algo completamente nuevo, actualizo el firmware añadiendo nuevas rutinas. Ten en cuenta que un efecto final, puede ser el encadenamiento de varios efectos básicos, con parámetros diferentes, para cambiar la velocidad de ejecución, los colores a utilizar, etc...

Con un tarjetero SD, nunca te quedarás corto, y cargarle nuevos archivos no requiere ningún hardware ni software especial.



Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 18 de Noviembre de 2014, 14:08:50
Yo tambien pense que era para efectos,etc pero no firmware.

Y planeta9999 tien razon, solo SPI y listo.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 18 de Noviembre de 2014, 14:50:44
no es para firmware, nunca dije eso. Sería para cambiar el texto a mostrar y unos bytes mas para configuracion de efecto. En realidad son muy pocos bytes, veo que exagere en los 200kb!!!

no sería lo mas facil de implementar una comunicacion CDC? porque son muy pocos datos los que hay que escribir, para que se den una idea, el cartel tiene 8 posibles colores. Como efecto hay 2 nada más y es poner un color desde el principio hasta un determinado columna y de ahi en adelante otro color y el segundo efecto es que una parte del cartel parpadee. El cliente lo quiere para poner, por ejemplo "Linea 1: " (eso en rojo y fijo) y luego "detenida" en, por ejemplo, verde y parpadeando. Con 2 entradas digitales cambia una parte del cartel y pasa, por ejemplo, de "detenida" en verde parpadeando a "en marcha" fija y rojo... se entiende? o sea que se configuran 2 mensajes (para cada entrada digital) y que parte va en que color y que parte va fijo/parpadeando. Una vez que se configura y se carga eso, muy pero muy de vez en cuando pueden querer cambiar el texto. Casi que se configura cuando se instala y luego no se toca.

Lo de ir con el pendrive me gustaba, pero para eso necesito micro con usb OTG, no?

Saludos y gracias por los consejos!!!!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 18 de Noviembre de 2014, 17:56:54
USB OTG, o que pueda actuar como Host MSD (Mass Storage Device).

Tu problema de polucion va a ser el mismo tanto para USB como para el SD dependiendo del grado de polucion los contactos se van a llenar igual de suciedad. Aunque veo mas desprotegido el SD.
Lo que yo me referia al elegir el USB era de la facilidad la persona que no se maneja con la tecnologia, poner un pendrive es mucho mas comun ( ya que USB hay por todos lados ) que hacerlo con una SD ( Donde tenes que tener el lector de tarjeta ). Ese fue mi punto de vista, por eso dije si era para venderlo. Y si haces como dice planeta9999 simplemente serian un par de lineas de texto.

Pero aca depende de vos, si tenes para hacer el USB o introducir un intemediario que pueda hacer de host/OTG USB y renegar con el mismo. O directamente ir por el SPI y la SD sin hardware extra.

Todo se puede hacer :P, es cuestion tuya que tanto queres renegar. Si vos lo queres de una forma entonces lo haces a pesar que te cueste ( Eso implica mas tiempo de desarrollo, tiempo para el cliente que por ahi espera y dice "Este no hace nada, para cuando llegara?" )
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 18 de Noviembre de 2014, 23:14:57
Yo quiero lo mas fácil de implementar. Si es la micro se lo mas fácil en cuanto a soft y hard, entonces voy por esa.
En ese caso, necesito implementar fat en el micro? O para leer un archivo no hace falta?

Sds.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 19 de Noviembre de 2014, 08:12:02


Si vas a almacenar archivos, tienes que particionar la tarjeta con FAT o FAT32.

Implementar un pendrive por USB tampoco es complicado, pero también tendrás que particionarlo y usar las librerías para gestionar volúmenes FAT, además de las librerías para USB, creo que el objeto será mayor que si trabajas con tarjetas SD. Importante, el tamaño de las librerías para tarjetas SD, se incrementa bastante, si quieres grabarlas, pero solo para lectura ocupan relativamente poco.

Yo en mis primeros diseños implementé el bootloader PC-USB, pero al final me decanté por tarjetas micro SD, creo que es lo más cómodo, si se dejan puestas se pueden usar además como un disco duro y ocupan menos espacio que un pendrive. Si solo es para actualizar firmware, da igual usar un pendrive o una SD.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 19 de Noviembre de 2014, 19:48:09
El cartel solo tiene que leer info de la SD/Pendrive o lo que sea.
En ese caso, a la SD la graba la PC. En la PC voy a tener una aplicacion .net que generará el archivo a poner en el dispositivo. En el lado de la PC, si o si el dispositivo tiene que estar formateado con fat, no puedo hacer grabacion RAW (desde .net a la SD) para luego leer con el uC los datos RAW, verdad?

Si es así, entones en el micro voy a tener que implementar rutinas de lecturas de volumenes FAT. Es simple eso?

Por otro lado, si voy por el lado del cable USB y CDC, tienen idea si es simple implementar el lado del uC para recivir los datos? En pic veo muchos ejemplos de CDC (usando las librerias de microchip o de CCS), pero ARM saben como viene la mano? Estoy buscando ejemplos de código de CDC en ARM y me esta costando un poco encontrar algo para mi micro...

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: Suky en 19 de Noviembre de 2014, 19:53:11
Hola! Lo mas sencillo es colocar una EEPROM que mediante la conexión USB (puede ser CDC o HID) y una aplicación de PC se pueda configurar el mensaje y los efectos, y luego almacenarlo en la memoria para su posterior utilización.
USB no es como una UART, que tenes interrupción para capturar los datos, generalmente se detecta cuando se conecta el equipo a la PC, y a partir de ahí se detecta cuando hay datos para leer y trabajar con ellos. USB device generalmente no resulta complicado de resolver.

Y ya que estas en fase de diseño podes usar una memoria SPI, así también de forma paralela agregas el zócalo para una uSD para una posible utilización. Generalmente es más sencillo usar uSD que USB Host, por ejemplo.

La uSD termina siendo muy útil, como dice planeta999, pero yo no la usaría en un ambiente industrial. Pero como la misma placa la podes utilizar para otras cosas lo agregaría. Sirve para las configuraciones y también puede servir para actualizar el firmware. Para resolver la implementación de archivos tienes FatFs by ChaN (http://elm-chan.org/fsw/ff/00index_e.html), solo tienes que implementar algunas funciones especificas de acceso al hardware que seguramente puedes encontrar algo hecho para el micro en particular que uses.


Saludos
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: Suky en 19 de Noviembre de 2014, 20:04:06
mmm... para USB y ese micro veo poca info, esto capaz sirva: http://www.lpcware.com/content/nxpfile/lpc-usb-serial-io-library.

Nosotros utilizamos los de ST, y en esos hay más info. Además ChibiOS los tiene portados y es más sencillo encarar alguna aplicación  :mrgreen:


Saludos.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: Suky en 19 de Noviembre de 2014, 22:18:40
Servirá? USB:

https://github.com/vanbwodonk/LPC11U_LPC13U_CDC


USB + FATFS:
https://github.com/microbuilder/LPC11U_LPC13U_CodeBase


Saludos
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 19 de Noviembre de 2014, 22:48:36
Gracias por todo suky! Mañana lo voy a revisar bien y veo si puedo sacar algo.

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 20 de Noviembre de 2014, 10:13:11
mmm... para USB y ese micro veo poca info, esto capaz sirva: http://www.lpcware.com/content/nxpfile/lpc-usb-serial-io-library.

Nosotros utilizamos los de ST, y en esos hay más info. Además ChibiOS los tiene portados y es más sencillo encarar alguna aplicación  :mrgreen:


Saludos.

por ahí viene la mano me parece, encontre este USB-Serial-IO (http://www.lpcware.com/content/project/lpc11u6x-usb-i2c-bridge-implementation) escrito para los 11U6x... ahi creo que esta todo resuelto, solo hay que estudiarlo. Ya que tengo la GUI para windows y el src para el micro. Permite comunicar la PC con un dispositivo I2C o SPI usando el USB en modo HID.... Excelente!

Saludos y gracias
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 20 de Noviembre de 2014, 10:16:41
Hola! Lo mas sencillo es colocar una EEPROM que mediante la conexión USB (puede ser CDC o HID) y una aplicación de PC se pueda configurar el mensaje y los efectos, y luego almacenarlo en la memoria para su posterior utilización.
USB no es como una UART, que tenes interrupción para capturar los datos, generalmente se detecta cuando se conecta el equipo a la PC, y a partir de ahí se detecta cuando hay datos para leer y trabajar con ellos. USB device generalmente no resulta complicado de resolver.

Y ya que estas en fase de diseño podes usar una memoria SPI, así también de forma paralela agregas el zócalo para una uSD para una posible utilización. Generalmente es más sencillo usar uSD que USB Host, por ejemplo.

La uSD termina siendo muy útil, como dice planeta999, pero yo no la usaría en un ambiente industrial. Pero como la misma placa la podes utilizar para otras cosas lo agregaría. Sirve para las configuraciones y también puede servir para actualizar el firmware. Para resolver la implementación de archivos tienes FatFs by ChaN (http://elm-chan.org/fsw/ff/00index_e.html), solo tienes que implementar algunas funciones especificas de acceso al hardware que seguramente puedes encontrar algo hecho para el micro en particular que uses.


Saludos

Bueno, me terminaron de convencer, la uSD formará parte del proyecto y quedará para futuros usos. Ahora tengo que ver un poco como es el hardware necesario alrededor de ella. La EEPROM donde se almacenará el texto y la configuracion a mostrar aun estoy en duda, pero evidentemente lo ideal sería una SPI en el mismo bus que la uSD, no? en ese caso, se elijen distintos pines GPIO para cada CS de cada dispositivo en el bus, verdad?

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: Suky en 20 de Noviembre de 2014, 23:51:20
La EEPROM donde se almacenará el texto y la configuracion a mostrar aun estoy en duda, pero evidentemente lo ideal sería una SPI en el mismo bus que la uSD, no? en ese caso, se elijen distintos pines GPIO para cada CS de cada dispositivo en el bus, verdad?

Exactamente, con el CS seleccionas con que esclavo comunicarte.

Saludos
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 21 de Noviembre de 2014, 09:48:11
Gente, me parece a mi o entender el USB aunque sea CDC es para meses de lectura? si es así entonces o trato de conseguir codigo y reniego probando y probando hasta que tenga algo funcionando, aunque no entienda como funciona del todo.... opcion 2 pongo un FTDI y en el micro uso un UART, opcion 3 uSD. Esta ultima opcion tiene un problemita y es que en las especificaciones dijimos que la conexion para cargar el programa iba a ser con un cable USB... tendría que ver si convenzo al cliente de cambiar a uSD... En el cartel podría hacer un compartimiento con tapa a tornillos donde este el zócalo de la SD así no se ensucia y queda protegida....
Por las dudas creo que voy a dejar todas las posibilidades en el PCB como para, una vez que tenga una placa, probar cual me da menos problemas....

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 21 de Noviembre de 2014, 11:25:59

Si es para cargar unos pocos datos de vez en cuando (un par de lineas de texto que va a mostrar el cartel), también puedes usar el ESP8266 por WIFI, y con un App en el móvil puedes cargar el texto, es una opción más chula todavía, seguro que a tu cliente le gusta más, sobre todo si el cartel va a estar ubicado en una zona de difícil acceso o acceso incómodo.

El ESP8266, se conecta al PIC por la UART, y se gestiona con comandos AT, no creo que sea complicado hacer algo en Java bajo Android para el móvil, puede incluso que ya exista algún aplicativo estandar para cosas básicas o algún generador de App que te cree el programa sin saber Java (algo creo haber visto).  

Aquí lo que llevo recopilado y probado del ESP8266 http://www.todopic.com.ar/foros/index.php?topic=43690.0

Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 21 de Noviembre de 2014, 11:33:10
Gente, me parece a mi o entender el USB aunque sea CDC es para meses de lectura?

Yo la unica cosa que hice con USB fue hace mucho en C, cuando no entendia NADA ( sigo sin entenderle del todo ) y fue ponerle y verlo funcionar, encima con Labview que tampoco entendia nada. Yo tambien pienso lo mismo..

Cada vez que intento leer algo de USB me quedo en la introduccion por que todos empiezan con lo mismo nodos/host y distintos tipos de dispositivos, comunicacion (CDC ) interrupcion ( HID ) pero nunca resumido o recalcando lo importante sino paginas y paginas de eso solo. Y me aburre xD
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 21 de Noviembre de 2014, 11:48:02

Si es para cargar unos pocos datos de vez en cuando (un par de lineas de texto que va a mostrar el cartel), también puedes usar el ESP8266 por WIFI, y con un App en el móvil puedes cargar el texto, es una opción más chula todavía, seguro que a tu cliente le gusta más, sobre todo si el cartel va a estar ubicado en una zona de difícil acceso o acceso incómodo.

El ESP8266, se conecta al PIC por la UART, y se gestiona con comandos AT, no creo que sea complicado hacer algo en Java bajo Android para el móvil, puede incluso que ya exista algún aplicativo estandar para cosas básicas o algún generador de App que te cree el programa sin saber Java (algo creo haber visto).  

Aquí lo que llevo recopilado y probado del ESP8266 http://www.todopic.com.ar/foros/index.php?topic=43690.0



la verdad que ese módulo es una joyita! el problema es que vivo en Argentina.... conseguir ese módulo a un precio razonable me demora 3 meses  :(... igual voy a hacer un intento de conseguir algunos... quizá si nos ponemos de acuerdo varios en argentina podemos traerlos por fedex a algun curier.... ya veré....

Saudos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 21 de Noviembre de 2014, 13:48:38
la verdad que ese módulo es una joyita! el problema es que vivo en Argentina.... conseguir ese módulo a un precio razonable me demora 3 meses  :(... igual voy a hacer un intento de conseguir algunos... quizá si nos ponemos de acuerdo varios en argentina podemos traerlos por fedex a algun curier.... ya veré....

Saudos!

Fedex te llegar rapido pero cuesta el envio y pasa por aduana si o si por que ellos presentan todos los papeles. Si el origen es chino entonces puede que pase como si nada pero tardaria 1 mes. Al menos es lo que me tarda lo que compro a "china" y marcado como Gift
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 21 de Noviembre de 2014, 14:12:47
la verdad que ese módulo es una joyita! el problema es que vivo en Argentina.... conseguir ese módulo a un precio razonable me demora 3 meses  :(... igual voy a hacer un intento de conseguir algunos... quizá si nos ponemos de acuerdo varios en argentina podemos traerlos por fedex a algun curier.... ya veré....

Saudos!

Fedex te llegar rapido pero cuesta el envio y pasa por aduana si o si por que ellos presentan todos los papeles. Si el origen es chino entonces puede que pase como si nada pero tardaria 1 mes. Al menos es lo que me tarda lo que compro a "china" y marcado como Gift

Si, si, yo traigo cosas por fedex. El tema es ese, el costo y los impuestos. A mi me llega en 10 días con ellos... por 3 módulos no se justifica, pero si por ahí hacemos un combo....

saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: Suky en 21 de Noviembre de 2014, 23:39:50
Hola, generalmente no es complicado sacar andando USB device, como mucho en un día tendría que salir. Salvo que haya muy poca información, pero siempre hay un ejemplito. Son cosas que hay que tener en cuenta cuando se elige un microcontrolador, así son menores los dolores de cabeza después  ;-)


Saludos
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 22 de Noviembre de 2014, 09:51:15
Hola, generalmente no es complicado sacar andando USB device, como mucho en un día tendría que salir. Salvo que haya muy poca información, pero siempre hay un ejemplito. Son cosas que hay que tener en cuenta cuando se elige un microcontrolador, así son menores los dolores de cabeza después  ;-)


Saludos

Si, es cierto, me deje llevar por el 11u67 por que es la nueva estrella de NXP, tiene USB certificado y te dan las herramientas para certificar tu producto... Encontre mucha info al final sobre USB con ese micro, todo a partir del link que pasaste del USBIO library. Lo único que no me gusta es que la base es LPCOpen y no las CMSIS. Lo poco que he visto las LPCOpen, son de "alto nivel" y código más standar y reutilizable. El problema es que para conseguir eso el código es, para mí, ilegible. Cuando me lleguen los micros, voy a armar una especie de plaquita de desarrollo para testear estas cosas...

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 02 de Diciembre de 2014, 21:39:08
Bueno, va tomando forma la parte de comunicacion con el cartel. Finalmente pude hacer andar un ejemplo de uso de la API que trae la ROM de estos micros para una comunicacion CDC. Las pruebas las estoy realizando con un LPC1347 ya que lo tengo en una LPCXpresso con todo soldado. Ya he conseguido la comunicacion entre el micro y el hyperterminal en un 90% (hay un tema que aún no resuelvo).
Entonces quería ir avanzando con la parte del GUI para programar el cartel y más puntualmente en la carga del texto y comandos al cartel.
Entonces en este punto la primer duda que me queda es, suponiendo que el cartel esta funcionando normalmente, vengo yo con la notebook y le enchufo el USB de la PC y me preparo para darle al supuesto botón de comandos "Download". Como se haría esa parte de la comunicacion en el lado del micro? digo, el micro debe detetar que se ha enchufado el USB? O que se ha abierto el puerto? suele haver alguna interrupcion para esto?
En el código de ejemplo que tengo se hace lo siguiente:

Código: [Seleccionar]
while (1) {
/* Check if host has connected and opened the VCOM port */
if ((vcom_connected() != 0) && (prompt == 0)) {
vcom_write((unsigned char *)"Hello World!!\r\n", 15);
prompt = 1;
}
/* If VCOM port is opened echo whatever we receive back to host. */
if (prompt) {
rdCnt = vcom_bread(&g_rxBuff[0], 256);
if (rdCnt) {
vcom_write(&g_rxBuff[0], rdCnt);
}
}
/* Sleep until next IRQ happens */
__WFI();
}

Entonces el micro se va a dormir y videntemente algún evento del USB lo despierta, luego en el bucle principal se verifica si el USB está conetado y si el puerto está abierto en el lado del host.... tambien tengo esta ISR:

Código: [Seleccionar]
void USB_IRQHandler(void)
{
uint32_t *addr = (uint32_t *) LPC_USB->EPLISTSTART;

/* WORKAROUND for artf32289 ROM driver BUG:
    As part of USB specification the device should respond
    with STALL condition for any unsupported setup packet. The host will send
    new setup packet/request on seeing STALL condition for EP0 instead of sending
    a clear STALL request. Current driver in ROM doesn't clear the STALL
    condition on new setup packet which should be fixed.
*/
if ( LPC_USB->DEVCMDSTAT & _BIT(8) ) { /* if setup packet is received */
addr[0] &= ~(_BIT(29)); /* clear EP0_OUT stall */
addr[2] &= ~(_BIT(29)); /* clear EP0_IN stall */
}
USBD_API->hw->ISR(g_hUsb);
}

Pero no estoy seguro a que atiende.... recien me estoy interiorizando un poco con esto del USB....

Bueno, ahora supongamos que en el micro detecto que me quieren enviar algo y lo espero... como debería ser la transmision? debo incluir algun chequeo como CRC o algo por el estilo?

En cuanto a la otra parte del proyecto, ya va más encaminado, ya estoy terminando el ruteado de las placas para fabricarlas y los led ya están en camino. Parte hardware es cuestion de semanas para que quede listo, por eso me quiero ir anticipando con tema software....

Saludos y gracias de ante mano!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: BrunoF en 05 de Diciembre de 2014, 18:54:19
Leo,

te conviene asumir a la comunicación CDC como si se tratase de un COM normal. Generá un buffer circular de recepción para ir recibiendo los datos seriales. Creá tu propio empaquetado de datos o utilizá algún estándar.

Por ej: (BOP) (Package Length)   (data[]...)       (checksum ( Package Length XOR data[0] XOR data[n] ))   (EOP)
           0xA3          0x02            0xAA, 0x11                                    0xB9                                                0xFE

e implementás un parseador, que vaya intepretando los paquetes y verificandolo. Importante también poner un timeout en el que si se tienen datos en el buffer pero no se recibe el EOP, descarte todo el contenido del buffer.

Otra implementación más sencilla es aprovechar que los datos seriales CDC se envían en realidad de a chunks. Supongamos que el tamaño del endpoint de recepción de datos seriales es de 32 bytes. Si desarrollás comandos que no excedan nunca los 32 bytes, podés olvidarte de requerir la complejidad del buffer ciclico y su intérprete. Sencillamente sabés que cada recepción de datos es a lo sumo un comando, y podés establecer la estructura de los datos de manera muy sencilla. La integridad de los datos está garantizada para este tipo de datos, pero si optás por la primera opción, te conviene agregar algún tipo de checksum para corroborar no haber perdido algún chunk de datos.

Saludos!

Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 13 de Agosto de 2015, 15:04:13
Buenas, este proyecto, lejos de haber muerto, a mutado en algo bastante más interesante.
Charlando con mi socio hemos decidido cambiar el enfoque de diseño, cambiando los driver de los LED para tener un módulo con mucho más futuro.
El proyecto original es un cartel (2 vendidos) de 16x256 px a 8 colores. O sea LED RGB, pero sin PWM. Originalmente iban a ir 2 TLC5925. Investigando un poco hemos encontrado el TLC5958, el cual posee salidas para manejar 16 led RGB (48 salidas con PWM) y el hermano menor, el TLC5954, el cual no posee PWM, pero que es practicamente pin compatible con el anterior. Por lo tanto con una sola placa controladora de modulo soldando uno u otro driver y una resistencia o un puente tenemos la posibilidad de modulo monocromatico (o hasta 8 colores) y RGB full color.
Otro cambio sustancia que decidimos incorporar es eliminar el control de fila unico, con toda la potencia que tiene que manejar y pasar a una solucion más modular. El diseño actual pasa por desarrollar un módulo de led de 16x32 led RGB y detras de cada módulo una placa de control (seleccion de fila y drivers de LED) para ese módulo. De este modo se abre la puerta al diseño de un panel RGB full color que puede, algún dia, terminar en una pantalla led como las que se ven hoy día...

Entonces el esquemático actual es más o menos el siguiente:

(https://farm6.staticflickr.com/5646/20551281031_905ac32bd3_z.jpg) (https://flic.kr/p/xj3FRz)

(https://farm6.staticflickr.com/5661/20356785290_02bd2588ba_z.jpg) (https://flic.kr/p/x1RR3J)

Tenemos los 2 driver, un buffer de entrada (el 74hc245), 2 decodificadores de línea (74HC138) y un doble monoestable para seguridad por harware. Si por algun motivo una fila queda encendida de forma continua, sin barrido vertical, este integrado se encarga de desabilitar los mosfet de las lineas y apagar el cartel.

De aquí veran algunas de las dudas que he estado consultando en estos días...

Bien, ahora hay 2 que estoy tatando de resolver. La primera es la alimentacion. A mi me gustaría alimentar el módulo entero con una entrada de 5V y usar esos 5V para los LED y para las compuertas. Será posible hacer esto? o el ruido en la línea de alimentacion (por la carga variable del barrido) será un problema complicado de resolver?
En el peor de los casos, creo que sería una fila completa blanca, una fila completa negra, una blanca y así sucesivamente. Cada línea estará formada por 32*3 = 96 LED. Los rojos usan 20mA, los verdes 8 y los azules 10. Entonces cada led consumiría 38mA * 32 LED = 1.21A. Entonces tendríamos en la línea de alimentacion una corriente de 1.2A / 0A / 1.2A / 0A.... esos picos se darán a un intervalo de unos 120Hz x 16 líneas = 1.9KHz. La duda es si esa corrientes meterán mucho ruido en la linea de alimentacion y producirá problemas en las compuertas... La alternativa es bajar la tension de las compuertas a 3.6V intercalando un buen LDO, esta alternativa es la que quiero evitar... como lo ven?

El otro tema es, pensando en un panel full color. El PWM del TLC5958 es de 16 bits y estoy intentando calcular la frecuencia del clock que debo enviar para dicho PWM.
Supongamos un frame rate de 120Hz y una multiplexacion de 1/16. Significaría que cada fila esta comandada por una frecuancia de 1.9KHz, o lo que es lo mismo, cada fila está encendida por unos 520.8 useg en ese tiempo, durante esos 520useg debo poder enviar como mínimo los 65535 pulsos para hacer un ciclo completo del PWM. Entonces tengo 520/65535 = 7.94 nseg = 125 MHz  :shock: es acá donde me entra la duda, ya que la F max del GCLK es de 33MHZ. Puedo estar errando en algo acá?
en esta nota de aplicacion hay algunos datos, pero cero cálculos... http://www.ti.com/lit/ug/tidu370/tidu370.pdf

Saludos y gracias!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 13 de Agosto de 2015, 18:22:48
.

Ya hay hoy en día soluciones infinitamente mejores y mucho más baratas para hacer carteles, que diseñarlo uno mismo desde cero. Yo en concreto ahora mismo estoy trabajando con estos paneles chinos de 64x32 RGB. Incorporan TODA la electrónica para gestionar el panel con señales que alimentan un shift register para las columnas y un código binario de 4 bits para las filas. Son sencillisimos de usar con cualquier microcontrolador.

Hasta incluyen el bastidor totalmente mecanizado para usar tornillería estandar de métrica M4 para anclarlo donde quieras. Tienen un conector de datos de entrada y otro de salida, para poder encadenar varios paneles y montar un cartel de la resolución y tamaño que quieras.

Este en concreto es de paso 2.5 y cuesta tan solo 23 dólares, una auténtica ganga, también los tienes de muchos otros pasos (P3, P6, P10, etc...) y de 64x64 pixels. Todos estos módulos se usan para montar pantallones gigantes de TV para los estadios y eventos varios, y los tienes en los chinos a precio de baratija, además listos para usar, sin necesidad de ensuciarte las manos. Seguro que cualquier cosa que puedas montar por ti mismo, te va a salir mucho más cara.


(http://i1322.photobucket.com/albums/u573/planeta9999/LED_panel_chino_zpsonaknall.jpg)

Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 13 de Agosto de 2015, 18:37:41
Y ese tiene buena imagen al menos la estructura, un compañero que tiene negocio compro unos de china y eran muy endebles, Y si, es mucho mas facil/barato comprarlos que fabricarlos, ya traen todo el plastico con el formato. como para ponerlo en el exterior y sellado.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 13 de Agosto de 2015, 20:02:33
.

Ya hay hoy en día soluciones infinitamente mejores y mucho más baratas para hacer carteles, que diseñarlo uno mismo desde cero. Yo en concreto ahora mismo estoy trabajando con estos paneles chinos de 64x32 RGB. Incorporan TODA la electrónica para gestionar el panel con señales que alimentan un shift register para las columnas y un código binario de 4 bits para las filas. Son sencillisimos de usar con cualquier microcontrolador.

Hasta incluyen el bastidor totalmente mecanizado para usar tornillería estandar de métrica M4 para anclarlo donde quieras. Tienen un conector de datos de entrada y otro de salida, para poder encadenar varios paneles y montar un cartel de la resolución y tamaño que quieras.

Este en concreto es de paso 2.5 y cuesta tan solo 23 dólares, una auténtica ganga, también los tienes de muchos otros pasos (P3, P6, P10, etc...) y de 64x64 pixels. Todos estos módulos se usan para montar pantallones gigantes de TV para los estadios y eventos varios, y los tienes en los chinos a precio de baratija, además listos para usar, sin necesidad de ensuciarte las manos. Seguro que cualquier cosa que puedas montar por ti mismo, te va a salir mucho más cara.


(http://i1322.photobucket.com/albums/u573/planeta9999/LED_panel_chino_zpsonaknall.jpg)



mi idea es fabricar ese tipo de modulos  ;-)
Por cierto, la solucion del cartel que estoy diseñando, estoy seguro que es mucho mejor que la solucion implementada en ese módulo chino.

en cuanto a que sea más caro podemos discutirlo un buen rato, por lo menos acá en Argentina....

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 13 de Agosto de 2015, 21:08:20
mi idea es fabricar ese tipo de modulos  ;-)
Por cierto, la solucion del cartel que estoy diseñando, estoy seguro que es mucho mejor que la solucion implementada en ese módulo chino.

en cuanto a que sea más caro podemos discutirlo un buen rato, por lo menos acá en Argentina....

Saludos!


Bueno, fenomenal, si eres capaz de hacer estos paneles por menos de 23 USD unidad, ya tienes un cliente, necesito 300 unidades.
¿ Para cuando los tendrás ?.


Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 13 de Agosto de 2015, 21:52:03
me pasarías el link de ese módulo.

PD: nunca dije que podía fabricar ese mismo módulo a ese mismo precio.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 13 de Agosto de 2015, 22:11:43
me pasarías el link de ese módulo.

PD: nunca dije que podía fabricar ese mismo módulo a ese mismo precio.


Jejeje, era una ironía, dudo que incluso puedas fabricarlo al doble o incluso al triple de ese precio. Ni siquiera en España se podría fabricar al triple de lo que piden los chinos. Estamos hablando de un panel Led RGB de 2048 leds de paso 2.5, más toda la electrónica de control, más un bastidor de plástico rígido mecanizado con tornillería, listo para ensamblar en rack con otros paneles para montar pantallas gigantes de TV.

En Aliexpress tienes infinidad de distribuidores chinos, que venden paneles de este tipo con varios pasos desde P2.5 hasta P10 ó más. También puedes encontrar información detallada de como controlarlos en la web de Adafruit, seguramente ellos importan de China los paneles que venden, lo bueno es que dan muchisima más información técnica que los chinos, en ese aspecto los chinos son muy parcos, apenas te cuentan nada, solo te dan el pinout del conector y búscate la vida.

Afortunadamente, para cualquiera que conozca como funcionan los paneles led, se ve de inmediato como están controlados por un registro de desplazamiento para las columnas y con un código binario de 4 bits para seleccionar la fila, aunque tienen un particularidad muy curiosa, las lineas se barren de DOS en DOS.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 13 de Agosto de 2015, 23:04:32
me pasarías el link de ese módulo.

PD: nunca dije que podía fabricar ese mismo módulo a ese mismo precio.


Jejeje, era una ironía, dudo que incluso puedas fabricarlo al doble o incluso al triple de ese precio. Ni siquiera en España se podría fabricar al triple de lo que piden los chinos. Estamos hablando de un panel Led RGB de 2048 leds de paso 2.5, más toda la electrónica de control, más un bastidor de plástico rígido mecanizado con tornillería, listo para ensamblar en rack con otros paneles para montar pantallas gigantes de TV.

En Aliexpress tienes infinidad de distribuidores chinos, que venden paneles de este tipo con varios pasos desde P2.5 hasta P10 ó más. También puedes encontrar información detallada de como controlarlos en la web de Adafruit, seguramente ellos importan de China los paneles que venden, lo bueno es que dan muchisima más información técnica que los chinos, en ese aspecto los chinos son muy parcos, apenas te cuentan nada, solo te dan el pinout del conector y búscate la vida.

Afortunadamente, para cualquiera que conozca como funcionan los paneles led, se ve de inmediato como están controlados por un registro de desplazamiento para las columnas y con un código binario de 4 bits para seleccionar la fila, aunque tienen un particularidad muy curiosa, las lineas se barren de DOS en DOS.

Dejemos el precio de lado si querés.
Si me pasas un link del módulo que usas te digo los defectos que tiene vs el diseño que estoy tratando de implementar. Hay muchos modelos y de muy diversa funcionalidad, hay un montón de cuestiones que desconoces de los paneles led evidentemente.
Eso de barrer de a dos filas, no es una curiosidad es simplemente que con 32 filas tendrías una multiplexación 1/32 que con los driver berretas que traen no verías nada. Le tenes que ingresar de a dos datos para conseguir multiplexación 1/16 o por eso 4 líneas para direccionar 16 filas.. Con 4 bits no podes direccionar 32 filas...
Recuerdo que tu primera respuesta en este proyecto fue que se podía resolver lo que estaba haciendo con led digitales.... Otro error...

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: planeta9999 en 13 de Agosto de 2015, 23:53:25
Si me pasas un link del módulo que usas te digo los defectos que tiene vs el diseño que estoy tratando de implementar. Hay muchos modelos y de muy diversa funcionalidad, hay un montón de
cuestiones que desconoces de los paneles led evidentemente.

https://learn.adafruit.com/32x16-32x32-rgb-led-matrix/


Citar
Eso de barrer de a dos filas, no es una curiosidad es simplemente que con 32 filas tendrías una multiplexación 1/32 que con los driver berretas que traen no verías nada.

Incorrecto, estoy trabajando con máquinas que se fabrican desde los años 90, y barren 32 lineas, una a una, y se ven perfectamente. Precisamente en uno de los proyectos en los que estoy trabajando ahora mismo es el reemplazo de pantallas de gas, por pantallas a led, y una de las cosas que tenía que resolver es como convertir el barrido de 32 lineas una a una (por registro de desplazamiento), a un barrido a dos lineas con un código binario de 4 bit (tema que ya he resuelto).


Citar
Le tenes que ingresar de a dos datos para conseguir multiplexación 1/16 o por eso 4 líneas para direccionar 16 filas.. Con 4 bits no podes direccionar 32 filas...

De eso ya me dí cuenta, pero no deja de ser curioso que las lineas se barran de dos en dos, no lo había visto hasta ahora en circuitos de carteleria led.


Citar
Recuerdo que tu primera respuesta en este proyecto fue que se podía resolver lo que estaba haciendo con led digitales.... Otro error...

Eso dependerá de la aplicación, error ninguno, cada caso se puede resolver de una o varias maneras, los leds digitales tienen múltiples aplicaciones, yo los estoy utilizando desde hace tiempo y son insustituibles en ciertas aplicaciones.

Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 14 de Agosto de 2015, 06:42:43
sacado del modulo chino que pasaste:

"Keep in mind that these displays are normally designed to be driven by FPGAs or other high speed processors; they do not have built in PWM control of any kind. Instead, you're supposed to redraw the screen over and over to 'manually' PWM the whole thing"

entre otras cosas esos módulos son tan baratos porqueno tienen nada de electrónica en los drive, usan chips clones chinos de los años 90. Ahora si lees el objetivo de mi proyecto verás que tu afirmacion:

"Ya hay hoy en día soluciones infinitamente mejores y mucho más baratas para hacer carteles, que diseñarlo uno mismo desde cero. Yo en concreto ahora mismo estoy trabajando con estos paneles chinos de 64x32 RGB. Incorporan TODA la electrónica para gestionar el panel con señales que alimentan un shift register para las columnas y un código binario de 4 bits para las filas. Son sencillisimos de usar con cualquier microcontrolador.

Este en concreto es de paso 2.5 y cuesta tan solo 23 dólares, una auténtica ganga, también los tienes de muchos otros pasos (P3, P6, P10, etc...) y de 64x64 pixels. Todos estos módulos se usan para montar pantallones gigantes de TV para los estadios y eventos varios, y los tienes en los chinos a precio de baratija, además listos para usar, sin necesidad de ensuciarte las manos. Seguro que cualquier cosa que puedas montar por ti mismo, te va a salir mucho más cara."

es incorrecta. La solucion que pones no es mejor a la que estoy tratando de implementar. No tiene PWM integrado y por lo tanto es casi imposible hacer FULL color. El error más grande lo tienes en "Todos estos módulos se usan para montar pantallones gigantes de TV para los estadios y eventos varios" ya que no son estos los módulos que se usan en ese tipo de carteles. Los módulos que se utilizan poseen drive's mucho más especializados.

Acá (http://www.todopic.com.ar/foros/index.php?topic=39290.msg328500#msg328500) podes ver el precio de una pantalla de 4x3mts. Cada mt2 cuesta USD1280. Necesitas 20 modulos como el tuyo para conseguir 1mt2 por lo que aquí cada modulito cuesta USD64.

bueno, ya perdi mucho tiempo. Si te parece quiero hacer este proyecto solo por gusto, no te preocupes que ya tengo la justificacion de porque perder el tiempo en él.
ahora lo que realmente me importa, podes ayudarme en algo de lo planteado acá? (http://www.todopic.com.ar/foros/index.php?topic=43643.msg373244#msg373244)

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: BrunoF en 15 de Agosto de 2015, 00:10:43
Hola leo,

¿Cuantos colores queres por Led? No me quedo claro si son 8 colores por salida o por led RGB.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 15 de Agosto de 2015, 08:28:20
Hola leo,

¿Cuantos colores queres por Led? No me quedo claro si son 8 colores por salida o por led RGB.


Bruno, como andas. 2 versiones. Sin PWM y 8 colores por led y cambiando el TLC y una resistencia pasa a ser FULL RGB....

Abrazo!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 18 de Agosto de 2015, 10:35:45
Quedó este tema dando vueltas, no sé si alguien se anima a tirar una idea:

De aquí veran algunas de las dudas que he estado consultando en estos días...

Bien, ahora hay 2 que estoy tatando de resolver. La primera es la alimentacion. A mi me gustaría alimentar el módulo entero con una entrada de 5V y usar esos 5V para los LED y para las compuertas. Será posible hacer esto? o el ruido en la línea de alimentacion (por la carga variable del barrido) será un problema complicado de resolver?
En el peor de los casos, creo que sería una fila completa blanca, una fila completa negra, una blanca y así sucesivamente. Cada línea estará formada por 32*3 = 96 LED. Los rojos usan 20mA, los verdes 8 y los azules 10. Entonces cada led consumiría 38mA * 32 LED = 1.21A. Entonces tendríamos en la línea de alimentacion una corriente de 1.2A / 0A / 1.2A / 0A.... esos picos se darán a un intervalo de unos 120Hz x 16 líneas = 1.9KHz. La duda es si esa corrientes meterán mucho ruido en la linea de alimentacion y producirá problemas en las compuertas... La alternativa es bajar la tension de las compuertas a 3.6V intercalando un buen LDO, esta alternativa es la que quiero evitar... como lo ven? Acá estoy pensando en colocar una inductancia en serie entre el +5V y los Vcc de las compuertas, buffer etc. y un capacitor grande (unos 100uF) a GND... el tema sería poder determinar si será suficiente filtro...

El otro tema es, pensando en un panel full color. El PWM del TLC5958 es de 16 bits y estoy intentando calcular la frecuencia del clock que debo enviar para dicho PWM.
Supongamos un frame rate de 120Hz y una multiplexacion de 1/16. Significaría que cada fila esta comandada por una frecuancia de 1.9KHz, o lo que es lo mismo, cada fila está encendida por unos 520.8 useg en ese tiempo, durante esos 520useg debo poder enviar como mínimo los 65535 pulsos para hacer un ciclo completo del PWM. Entonces tengo 520/65535 = 7.94 nseg = 125 MHz   :shock: es acá donde me entra la duda, ya que la F max del GCLK es de 33MHZ. Puedo estar errando en algo acá?
en esta nota de aplicacion hay algunos datos, pero cero cálculos... http://www.ti.com/lit/ug/tidu370/tidu370.pdf

saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: BrunoF en 19 de Agosto de 2015, 02:58:22
Hola Leo,

Lamentablemente tus cálculos son correctos. Con esas características de panel necesitarías un clock de 125 Mhz. Muy por encima del máximo de 33mhz.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 19 de Agosto de 2015, 09:36:48
Hola Leo,

Lamentablemente tus cálculos son correctos. Con esas características de panel necesitarías un clock de 125 Mhz. Muy por encima del máximo de 33mhz.

Bruno, como andas!
Estimo que la solucion es trabajar al driver con menos bits (estoy viendo si se puede y como se hace).
No sé si viste el TLC5958, el ultimo driver de TI, trae SRAM y promete multiplexado hasta 1/32... mirá este documento:
http://www.ti.com/lit/an/slva645/slva645.pdf
Tengo una duda con la figura 15. Si no entiendo mal, divide cada ciclo del PWM en 256 segmentos de 256 pulsos y lo que hace es sacar el segmento 0 de la linea 1, luego el segmento 0 de la linea 2, luego el segmento 0 de la linea 3. De este modo dice incrementar el visual refresh rate... lo que veo es que para hacer esto debería aumentar considerablemente la frecuencia del scan de las líneas.... o sea que los 125MHz no cambian...

saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 19 de Agosto de 2015, 09:43:49
algunas respuestas:
https://e2e.ti.com/support/power_management/led_driver/f/192/p/421471/1506064

sds.
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: BrunoF en 19 de Agosto de 2015, 14:53:00
Hmm...

Ese Datasheet tiene problemas de coherencia.

En el punto 3.6.2 te presenta al TLC5958 como un dispositivo diseñado para displays multiplexados, y te muestra los dos posibles modos ES PWM asociados: (8+8) y (9+7):

"TLC5958 is designed mainly for multiplexed display system. It uses an innovative Multiplexed ES PWM method to improve the visual refresh rate while maintain the best grayscale performance."

Luego, en la descripción de ambos modos dice:

"This is a good method for static display system, but not good for multiplexed (dynamic) display system. If one finished all the XXX segments of one scan line, then change to display another scan line, the refresh rate will be very low."

Lo que va completamente en contra de lo enunciado inicialmente. Describen ambos modos ES PWM como "malos" para displays multiplexados.

Más allá de eso, lo bueno del integrado es la capacidad nativa de trabajar multiplexando y tener memoria propia para almacenar todos los valores, incluso con double buffering. Lo malo es que como bien calcula el ponja en en el último link que pusiste, los Hertz son muy bajos, aún usando el modo 8 + 6 (no llega a 60Hz). La clara limitante es la velocidad máxima del GCLK. Aunque en los displays de este tipo 33Mhz es el valor más común (al menos lo era, no sé ahora). Si querés más Hertz, vas a tener que sacrificar grises, o bien agregar más integrados (aumentando el costo del producto).

Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 19 de Agosto de 2015, 15:22:23
Hmm...

Ese Datasheet tiene problemas de coherencia.

En el punto 3.6.2 te presenta al TLC5958 como un dispositivo diseñado para displays multiplexados, y te muestra los dos posibles modos ES PWM asociados: (8+8) y (9+7):

"TLC5958 is designed mainly for multiplexed display system. It uses an innovative Multiplexed ES PWM method to improve the visual refresh rate while maintain the best grayscale performance."

Luego, en la descripción de ambos modos dice:

"This is a good method for static display system, but not good for multiplexed (dynamic) display system. If one finished all the XXX segments of one scan line, then change to display another scan line, the refresh rate will be very low."

Lo que va completamente en contra de lo enunciado inicialmente. Describen ambos modos ES PWM como "malos" para displays multiplexados.

Más allá de eso, lo bueno del integrado es la capacidad nativa de trabajar multiplexando y tener memoria propia para almacenar todos los valores, incluso con double buffering. Lo malo es que como bien calcula el ponja en en el último link que pusiste, los Hertz son muy bajos, aún usando el modo 8 + 6 (no llega a 60Hz). La clara limitante es la velocidad máxima del GCLK. Aunque en los displays de este tipo 33Mhz es el valor más común (al menos lo era, no sé ahora). Si querés más Hertz, vas a tener que sacrificar grises, o bien agregar más integrados (aumentando el costo del producto).



Si, pero fijate que la explicacion continúa. Es como que dice primero que el modo ES PWM (que implementan muy pocos) es muy bueno, pero no lo mejor, luego dice que ahora ellos implementan esto:

In TLC5958’s multiplexed ES PWM control, one display period is divided into 256 sub-periods, which
corresponding to the 256 segments of the conventional ES-PWM. During one sub-period, all scan lines
will display their corresponding segment sequentially. When all scan lines finished their segment, this subperiod
ends, and next sub-period will start. Because each scan line has a chance to display in one subperiod,
thus the visual refresh rate is 256 time higher than that of the conventional ES-PWM control.


ahora, mi duda es, en donde entra un FPGA??? x q si el maximo del GCLK es 33MHz....
O se usan con chips que no integran PWM y hacen el PWM en la FPGA? ahora, esos chips que no integran PWM, el clock de los datos debe soportar igualmente 120MHz si queremos 1/16. Digo esto x q el TLC5954 no incorpora PWM, sin embargo el Data Clcok es de 30MHz...

saludos y gracias!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 09 de Septiembre de 2015, 14:53:34
Bueno, creo que ya casi esta listo para mandar a fabricar las placas:

Esta es la controladora de 16x32 pixeles RGB:

(https://farm1.staticflickr.com/606/20653560104_58b8fd9194_c.jpg) (https://flic.kr/p/xt5TRS)

(https://farm6.staticflickr.com/5818/21088368348_31310a8fc5_c.jpg) (https://flic.kr/p/y8vpcJ)

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

(https://farm1.staticflickr.com/644/21250005816_9204211110_c.jpg) (https://flic.kr/p/ynMQoC)

Panel de led:

(https://farm6.staticflickr.com/5727/21265720362_fc90fbbaf1_c.jpg) (https://flic.kr/p/ypbnM5)

(https://farm1.staticflickr.com/638/21088373618_23df343845_c.jpg) (https://flic.kr/p/y8vqLA)

(https://farm6.staticflickr.com/5638/21088374618_ae09229b04_c.jpg) (https://flic.kr/p/y8vr4Q)

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

Saludos!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 09 de Septiembre de 2015, 15:19:04
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 ;-)
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 09 de Septiembre de 2015, 15:40:18
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!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 09 de Septiembre de 2015, 15:50:31
Citar
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 :D :D.

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.

Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 07 de Octubre de 2015, 15:39:34
Bueno, finalmente me llegaron las placas de los chinos!
Dejo unas imágenes del panel de LED y de la controladora:

(https://farm1.staticflickr.com/662/22023590215_a268b31ea3_c.jpg) (https://flic.kr/p/zy9E5F)

(https://farm6.staticflickr.com/5690/21997360536_e4e62523ea_c.jpg) (https://flic.kr/p/zvQdUQ)

(https://farm1.staticflickr.com/652/22033375031_14a3afee03_c.jpg) (https://flic.kr/p/zz1NLp)

(https://farm1.staticflickr.com/672/22023522625_8671b2f08e_c.jpg) (https://flic.kr/p/zy9iZk)

(https://farm1.staticflickr.com/624/22023549515_0605ab2809_c.jpg) (https://flic.kr/p/zy9rYX)

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!
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 07 de Octubre de 2015, 16:06:58
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
Título: Re: Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 09 de Octubre de 2015, 09:37:46
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  :5]

Saludos!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 09 de Octubre de 2015, 15:24:08
Citar
Estoy con poco tiempo de escritorio así que las pruebas tendrán que esperar 1 semana más

pues a esperar para verlo  :(   :D :D
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 11 de Octubre de 2015, 15:17:09
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!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 11 de Octubre de 2015, 15:41:23
 ((:-)) ((:-)) 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

Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: Nocturno en 11 de Octubre de 2015, 15:47:00
Ahora empieza lo divertido  ((:-)) ((:-)) ((:-))
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 11 de Octubre de 2015, 19:06:44
((:-)) ((:-)) 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  :5] 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!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 11 de Octubre de 2015, 19:14:23
Citar
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  :D :D

un saludo y gran trabajo, espero seguir viendo los avances  ;-)
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 12 de Octubre de 2015, 14:04:59
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 (http://www.todopic.com.ar/foros/index.php?topic=45280.0)

Como ven la idea?

Saludos!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 12 de Octubre de 2015, 15:42:12
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.
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 12 de Octubre de 2015, 21:39:57
Te agradeco mucho la respuesta y es tal cual como vos decis Juanjo, no hay forma de que entiendan todo el funcionamiento y aconsejar se torna complicado.
Lo que voy a ir haciendo es poner las implementaciones de las diferentes partes como para que quede registrado y quizá en esas implemetaciones puntuales me puedan aconsejar.

El primer punto que resolví fue el barrido de las filas para que sea automático por interrupcion.
Lo que hice fue elegir 4 salidas (PC4-PC7) contiguas para que sea bien fácil el manejo del decoder. Como decoder y habilitacion del mosfet de cada fila tengo un 74HC138. Entonces con las 4 señales PC4-PC7 voy activando una a una las salidas (poniendo en estado bajo) y habilitando cada mosfet P (necesitan un 0 al ser P).

El código es mas o menos así:

Código: C
  1. #include "stm32f4xx.h"
  2. #include "stm32f4_discovery.h"
  3. #include "main.h"
  4.  
  5. /* TIMER handler declaration */
  6. TIM_HandleTypeDef TIM_Handle;
  7.  
  8. /* SPI handler declaration */
  9. SPI_HandleTypeDef SpiHandle;
  10.  
  11. volatile uint8_t ui8FilaActual=0;
  12.  
  13. int main(void)
  14. {
  15.         uint64_t MC = 0;
  16. //      uint8_t i;
  17.  
  18.         /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  19.         HAL_Init();
  20.  
  21.         /* Configure the system clock */
  22.         SystemClock_Config();
  23.  
  24.         GPIO_Init();
  25.         TIM4_Config();
  26.  
  27.         MC |= 0x03 << 00;                               // MC = 11.6-8.1 mA
  28.         MC |= 0x7F << 03;                               //BC Red = 100%
  29.         MC |= 0x7F << 10;                               //BC Green = 100%
  30.         MC |= 0x7F << 17;                               //BC Blue = 100%
  31.                                                                         //SID = 0; LODVLT=0; LSDVLT=0; PSMODE=0 (no PWS)
  32.         MC |= (uint64_t)0x96 << 40;             //WRITE_CMD: Bits 40 a 47 en 10010110b
  33.         MC |= (uint64_t)0x01 << 48;             //Data Select Bit = 1
  34.  
  35.         send_config(MC);
  36.         send_config(MC);
  37.  
  38.         while(1)
  39.         {
  40.                 efecto_02(500);
  41.         }
  42. }

La configuracion del timer:

Código: C
  1. /*
  2.  * Si quiero obtener 120Hz tengo que cambiar de línea 16x120 = 1920 Veces por segundo.
  3.  * Necesito interrupcion cada 520uSeg.
  4.  */
  5. void TIM4_Config()
  6. {
  7.     __TIM4_CLK_ENABLE();
  8.  
  9.     TIM_Handle.Init.Prescaler = 42 - 1;         //El Clk del timer está en 84MHz. Lo reduzco a 2MHz
  10.     TIM_Handle.Init.CounterMode = TIM_COUNTERMODE_UP;
  11.     TIM_Handle.Init.Period = 1040;                      //1040 cuentas hasta interrupcion. 520 uSeg
  12.     TIM_Handle.Instance = TIM4;                         //
  13.     HAL_TIM_Base_Init(&TIM_Handle);             // Init timer
  14.  
  15.     HAL_TIM_Base_Start_IT(&TIM_Handle);         // start timer interrupts
  16.  
  17.     HAL_NVIC_SetPriority(TIM4_IRQn, 0, 1);
  18.     HAL_NVIC_EnableIRQ(TIM4_IRQn);
  19. }

y en la interrupcion:

Código: C
  1. /*
  2.  * Si miro en el osciloscopio la señal Ade direccion (PC4) tengo que ver un período de 2x 520useg
  3.  * ya que en cada interrupcion esa señal cambia de valor. El periodo será entonces de 1.04 mseg y una F
  4.  * de 961.5 Hz
  5.  * VERIFICADO CON OSCILLOSCOPIO.
  6.  */
  7. void TIM4_IRQHandler(void)
  8. {
  9.     if (__HAL_TIM_GET_FLAG(&TIM_Handle, TIM_FLAG_UPDATE) != RESET)      //In case other interrupts are also running
  10.     {
  11.         if (__HAL_TIM_GET_ITSTATUS(&TIM_Handle, TIM_IT_UPDATE) != RESET)
  12.         {
  13.             __HAL_TIM_CLEAR_FLAG(&TIM_Handle, TIM_FLAG_UPDATE);
  14.  
  15.             GPIOC->ODR &= ~(0xF << OFFSET_VERT_PINS);           //Pongo en 0 los 4 bits del barrido Vertical
  16.             GPIOC->ODR |= ui8FilaActual<< OFFSET_VERT_PINS;
  17.             ui8FilaActual++;
  18.             if(ui8FilaActual == 16)
  19.                 ui8FilaActual=0;
  20.         }
  21.     }
  22. }

Con esto consigo que el panel esté constantemente barriendo de forma horizontal y en la variable ui8FilaActual tengo la fila actual (en realidad tengo la proxima fila a activar.

Entonces si quiero provar de encender el panel completo de colores tengo este efecto:

Código: C
  1. void efecto_02(uint16_t velocidad)
  2. {
  3.         uint8_t j;
  4.  
  5.         for(j=0;j<3;j++)
  6.         {
  7.                 HAL_Delay(velocidad);
  8.                 if(j==0)
  9.                 {
  10.                         all_R();
  11.                 }
  12.                 else if(j==1)
  13.                 {
  14.                         all_G();
  15.                 }
  16.                 else
  17.                 {
  18.                         all_B();
  19.                 }
  20.  
  21.         }
  22. }
  23.  
  24. void all_R(void)
  25. {
  26.         send_data(0x0000249249249249, 0x0000249249249249);
  27. }
  28.  
  29. void all_G(void)
  30. {
  31.         send_data(0x0000492492492492, 0x0000492492492492);
  32. }
  33.  
  34. void all_B(void)
  35. {
  36.         send_data(0x0000924924924924, 0x0000924924924924);
  37. }

De este modo cuando envío el dato para encender los 32 led de la fila en color rojo, al estar barriendo verticalmente obtengo el encendido del panel entero.

El paso siguiente sería poder sacar los datos por el SPI, paso previo para arar el buffer de video y habilitar el DMA.

Saludos!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 13 de Octubre de 2015, 04:30:57
Como que me perdi completamente. Estuve leyendo y por mas que lo lei despacio a los ultimos 2 post me perdi feo.

Hasta ahora lo que entendi fue:

- Crear un buffer de [16][98] El cual tenga todos los bits incorporados. Asi con el DMA enviarlo por el SPI. Y da justo el tamaño en bits.
- Al tema de las filas las activas con 2 74HC138, 3-to-8 decoder Necesitas 16 filas, asi que son 2, o tal ves estes usando uno solo y activas 2 filas a las ves.
- Las filas estan activadas por un temporizador, el cual dispararia el DMA para que envie todos los datos, tal ves con acceso a una memoria Externa. Sino son 1.6Kb de unicamente el buffer de video. ( Puede entrar tranquilamente tal ves en el micro y no necesitar esa memoria externa ).

Lo que no me quedo claro es... que intentas hacer con el buffer, queres cambiarlo "on-the-fly"? Creo haber leido que decias que eran 2 textos nomas. Queres generarlos cuando comienza el micro? o va a estar guardado en algun lugar? Solo es texto ? o imagen ?.
Por todo esto me encuentro muy perdido xD.
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 13 de Octubre de 2015, 07:19:16
Me recuerda un poco a la forma de refrescar un display de segmentos que hice, solo que lo hice de una forma un poco diferente, no trataba los display como digitos si no como led, es decir cada digito tenia 8 led, y tenia un total de 8x4=32 led, y la función era mas compleja de esta forma pero podía encender los segmentos como me daba la gana con una función que cambiaba los datos a representación a led, lo tuyo es mucho mas complejo pero en esencia es parecido.

te falta hacer esa función que cambie texto o imágenes a led.

un saludo
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 13 de Octubre de 2015, 08:55:28
Como que me perdi completamente. Estuve leyendo y por mas que lo lei despacio a los ultimos 2 post me perdi feo.

Hasta ahora lo que entendi fue:

- Crear un buffer de [16][98] El cual tenga todos los bits incorporados. Asi con el DMA enviarlo por el SPI. Y da justo el tamaño en bits.
- Al tema de las filas las activas con 2 74HC138, 3-to-8 decoder Necesitas 16 filas, asi que son 2, o tal ves estes usando uno solo y activas 2 filas a las ves.
- Las filas estan activadas por un temporizador, el cual dispararia el DMA para que envie todos los datos, tal ves con acceso a una memoria Externa. Sino son 1.6Kb de unicamente el buffer de video. ( Puede entrar tranquilamente tal ves en el micro y no necesitar esa memoria externa ).

Lo que no me quedo claro es... que intentas hacer con el buffer, queres cambiarlo "on-the-fly"? Creo haber leido que decias que eran 2 textos nomas. Queres generarlos cuando comienza el micro? o va a estar guardado en algun lugar? Solo es texto ? o imagen ?.
Por todo esto me encuentro muy perdido xD.

El problema no son ustedes, soy yo que digo una cosa y despues otra.
Los primeros 2 puntos son correctos, pero son 98bytes porque cada TLC necesita 49 bits (2*49 * 8)bits. De esos 49 bits, 48 son informacion de ON/OFF de cada salida y 1 bit para indicar si son datos o comando. Al ser 2*8 TLC's los bits adicionales me agregan 2byte a lo que sería un buffer de video con solo datos on/off (3 * 256bits = 96 byte)

Ahora bien, el cartel que vendimos, es bien sencillo, solo 2 textos, que entran se cargan por USB y entran en la RAM enteros los dos. Entonces podría resolver solo esta aplicacion haciendo que la aplicacion de la PC haga todos los cálculos a nivel de bit's y mande los 16x98 bytes listos para que lo tome el DMA.
Peeeero, siempre hay un pero, me gustaría hacer algo lo más genérico posible para resolver esta aplicacion y cualquiera otra que quiera, ya que estos paneles son "standar" y espero poder usarlos en varios proyectos o hasta venderlos como módulos de led RGB para terceros.

Entonces la respuesta es si, tengo que tratar de cambiar el texto on the fly.

Teniendo en cuenta eso hay 3 puntos claves que definen el proyecto:

Saludos!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 13 de Octubre de 2015, 20:28:53
Si Eso pensaba yo, la libreria grafica que hagas debe hacer ese "buffer" de [16][96]. Seria lo mas facil de crear, pero luego incorporarle el 0 a todo ese array es EL dolor de cabeza. Yo no entiendo al tipo que se le ocurrio hacerlo de esa forma... de usar 49 bits siendo que un SPI envia de a 8.  Entonces tenes que crear una funcion que transforme 48 bytes en 49bytes (2 de estos y tenes tus 98 bytes) Y esa parte es el dolor de cabeza y mas consumidor de tiempo del core. Obviamente todos punteros :P Por ahi estoy pensando en comenzar de atras, es decir desde el byte 49, un contador el cual su AND va a servir para ambos bytes trabajados, el que esta y el que le sigue,. Fiero fiero muy fiero por que feo es poco, muchos AND :P, Pero va a ser un loop pequeño, eso es lo bueno :P
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 13 de Octubre de 2015, 23:45:30
Si Eso pensaba yo, la libreria grafica que hagas debe hacer ese "buffer" de [16][96]. Seria lo mas facil de crear, pero luego incorporarle el 0 a todo ese array es EL dolor de cabeza. Yo no entiendo al tipo que se le ocurrio hacerlo de esa forma... de usar 49 bits siendo que un SPI envia de a 8.  Entonces tenes que crear una funcion que transforme 48 bytes en 49bytes (2 de estos y tenes tus 98 bytes) Y esa parte es el dolor de cabeza y mas consumidor de tiempo del core. Obviamente todos punteros :P Por ahi estoy pensando en comenzar de atras, es decir desde el byte 49, un contador el cual su AND va a servir para ambos bytes trabajados, el que esta y el que le sigue,. Fiero fiero muy fiero por que feo es poco, muchos AND :P, Pero va a ser un loop pequeño, eso es lo bueno :P

Podrían haver puesto un pin más para distinguir dato/comando, no?
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 14 de Octubre de 2015, 02:48:12
Exactamente lo que yo pensaba.. En que habran pensado cuando lo hicieron.... hasta las memorias vienen en bytes y estos tipos se complican asi. Tal ves era para eliminar otro pin de control. Pero gracias a eso destruyeron lo bueno del sistema de shift-registers.

Por otro lado mirando el datasheet de mi micro, posee la seleccion de distintos valores tamaño de datos a enviar en el SPI. En ves de ser de 8 SI o SI podria hacerlos de 4 a 16 bits en el modo comun, nada de QSPI o Bi-SPI. Tal ves jugando un poco con esto se podria hacer 5 de 8 bits + 1 de 9 bits. Raro, normalmente estoy acostumbrado a solo 8 bits xD, Y feo por que hay que estar cambiando el tamaño del envio lo cual lo hace horrible y no manejable por el DMA

Con lo cual!!!!!!! tambien es posible hacerlo de 7 bits, y no de 8. Entonces te llevaria a enviar 7 de 7 bits y tenes los 49 bits enviados. lo que si pasa a ser un buffer de [16][112] ( ya que desperdicias el LSB - 224 bytes mas )

Y por ultimo no se que es mas facil, si la libreria grafica genere los [16][96] y luego lo transforme en [16][98] o [16][112].

Ventajas y Desventajas:

a 7 bits (14 puede ser): Mas RAM necesario para el buffer de salida pero no importa cuantos TCL tengas, siempre siempre va a ser valido.

a 8 bits (Mejor 16 que es lo mismo :P): Menos RAM necesario para el buffer de salida, pero para que funcione debe haber un multiplo par de TCL. Lo cual tenes implementado :P

Cosas que se me ocurren xD
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 14 de Octubre de 2015, 09:30:20
El stm32f411 (un M4F) puede transmitir 8 o 16 bits por frame.
Pero el LPC11u67 (M0+) puede transmitir de 4 a 16 bits. Este micro es mucho más acorde para esta aplicacion. Estoy probando con el 411 por que tengo esa placa de evaluacion....

El tema de 7 bits u 8 bits.... lo tengo que pensar un poco más. Ahora lo que si creo que tengo que separar el buffer de video con el buffer que va a usar el DMA con el SPI para sacar los datos y hacer una funcion de acomodar los bits. Por que incluso los datos de los TLC pares tengo que invertir los 48bits por la cagada del conector alereves.

Otro tema es la codificacion del color del pixel y la codificacion de la fuente. Por cada pixel necesito 3 bits. Entiendo que en el buffer de video lo tengo que considerar así. Pero la fuente estimo que la tengo que hacer monocromática y la funcion que graba el texto en el buffer de video debería tener como parámetro el color y transformar cada bit de la fuente en los 3 bits que corresponden al color. Me explico?

Saludos!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 14 de Octubre de 2015, 09:43:46
oye leonardo y ¿si el color se lo pones en una matriz de 3 dimensiones? la 3 dimensión seria el color.

un saludo
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 14 de Octubre de 2015, 14:44:44
oye leonardo y ¿si el color se lo pones en una matriz de 3 dimensiones? la 3 dimensión seria el color.

un saludo

mmmm, tendría que pensarlo un poco a ver como implementarlo y las ventajas de trabajar así...
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 14 de Octubre de 2015, 15:11:48
Hace un tiempo estuve trabajando con un OSD para un estabilizador de vuelo (http://www.todopic.com.ar/foros/index.php?topic=42254.0 (http://www.todopic.com.ar/foros/index.php?topic=42254.0)) y tuve que trabajar con algo de video.

En ese momento, la idea era más o menos esta:

Definicion del buffer de video:
Código: C
  1. #define PIX_Y       16         //Reveer PIX_Y y LAST_LINE. Ver en extint.c
  2. #define PIX_16_X    2
  3. #define FNT3_H      14          //Pixel heigh for Font 3
  4.  
  5. extern const short fnt3[];
  6. uint16_t membuff1[PIX_Y][PIX_16_X];

parte de la fuente es esta:
Código: C
  1. // Character bitmaps for Berlin Sans FB Demi 12pt
  2. const uint16_t fnt3[] =
  3. {
  4.     // @0 ' ' (14 pixels wide)
  5.     0b0000000000000000, //
  6.     0b0000000000000000, //
  7.     0b0000000000000000, //
  8.     0b0000000000000000, //
  9.     0b0000000000000000, //
  10.     0b0000000000000000, //
  11.     0b0000000000000000, //
  12.     0b0000000000000000, //
  13.     0b0000000000000000, //
  14.     0b0000000000000000, //
  15.     0b0000000000000000, //
  16.     0b0000000000000000, //
  17.     0b0000000000000000, //
  18.     0b0000000000000000, //
  19.  
  20.     // @0 '!' (14 pixels wide)
  21.     0b0000000110000000, //        ##
  22.     0b0000000110000000, //        ##
  23.     0b0000000110000000, //        ##
  24.     0b0000000110000000, //        ##
  25.     0b0000000110000000, //        ##
  26.     0b0000000110000000, //        ##
  27.     0b0000000110000000, //        ##
  28.     0b0000000110000000, //        ##
  29.     0b0000000000000000, //
  30.     0b0000000110000000, //        ##
  31.     0b0000000110000000, //        ##
  32.     0b0000000000000000, //
  33.     0b0000000000000000, //
  34.     0b0000000000000000, //
  35.  
  36.     // @28 '"' (14 pixels wide)
  37.     0b0000011011000000, //      ## ##
  38.     0b0000011011000000, //      ## ##
  39.     0b0000011011000000, //      ## ##
  40.     0b0000011011000000, //      ## ##
  41.     0b0000000000000000, //
  42.     0b0000000000000000, //
  43.     0b0000000000000000, //
  44.     0b0000000000000000, //
  45.     0b0000000000000000, //
  46.     0b0000000000000000, //
  47.     0b0000000000000000, //
  48.     0b0000000000000000, //
  49.     0b0000000000000000, //
  50.     0b0000000000000000, //
  51. ......

Y tenía 2 funciones básicas para imprimir caracteres/texto en ek buffer:

Código: C
  1. void put_char(short X, short Y, char Car);
  2. void put_string(short X, short Y, char *pcString);
  3.  
  4. void put_char(uint16_t X, uint16_t Y, char Car){
  5.         uint16_t i;
  6.  
  7.         for(i=Y; i<(Y+FNT3_H); i++)
  8.                 membuff1[i][X] = fnt3[(Car - 32) * FNT3_H + (i-Y)];
  9. }
  10.  
  11. // ***********************
  12. // Funcion para enviar una cadena de caracteres
  13. void put_string(uint16_t X, uint16_t Y, char *pcString){
  14.         int i = 0;
  15.         // loop through until reach string's zero terminator
  16.         while (pcString[i] != 0) {
  17.                 put_char(X, Y, pcString[i]); // print each character
  18.                 X++;
  19.                 i++;
  20.         }
  21. }

como ven la funcion put_string es totalmente portable, de echo es copia de una funcion para LCD. Acá lo importante es la implementacion del put_char.
El secreto de put_char está la referenciación del código ASCII del caracter a escrivir con la posicion del primer uint16_t de dicho caracter.
Como la fuente arranca por el " " (ASCII 32) al código ascii del caracter a imprimir le restamos 32. Luego lo multiplicamos por la altura de la fuente. Esto es porque cada FNT3_H (14 en este caso) uint's16_t tenemos la primer fila del siguiente caracter. Luego hay un offset que tiene en cuenta la Fila actual y el lazo for que recorre las 14 filas que compone un caracter en la fuente que creamos.

Entonces si en el main hacemos:

Código: C
  1. put_string(0, 0, "elgarbe");

conseguiríamos que esos caracteres se almacenen en el buffer de video (membuff1). El problema de este método es que la coordenada X no es en pixeles, sino que es en caracteres y el ancho del caracter está puesto en la fuente elegida. En este caso era para imprimir en una pantalla de monitor y una fuente de 16x 14 era mas o menos linda (aunque la relacion no parece que quede linda, 16 de ancho por 14 de alto?). Para este cartel necesito una fuente de 8x12 más o menos... Como hacer las fuentes lo mostraré despues. Por ahora solo plantear la idea de llenado de buffer.

Dibujar un punto no es mucho más dificil:
Código: C
  1. //-----------------------------------------------------------------------
  2. // Dibuja un pixel
  3. //-----------------------------------------------------------------------
  4. void OSD_punto(unsigned short x, unsigned short y, char color){
  5.     short CarX;
  6.     char PosCar;
  7.  
  8.     CarX = x/16;                                //Calculo en que Short cae el pixel
  9.     PosCar = 15-( 16 * ((float)x/16 - CarX));   //Calculo la posicion dentro del Short del pixel
  10.     x = (unsigned short)(1<<(PosCar));            //Armo el Short con ese pixel encendido
  11.     membuff1[y][CarX] |= x;                     //Pongo el Short completo en el buffer
  12. }

En este caso hay que tener encuenta que el buffer almacena uint16_t por lo que un punto en X debe ser referenciado a un bit dentro de los uint16's_t que forman una fila del cartel.

Y dibujar una línea?
Pues implementaciones standares:

Código: C
  1. //-----------------------------------------------------------------------
  2. // Dibuja una linea desde (x1,y1) a (x2,y2) de color (0 o 1)
  3. //-----------------------------------------------------------------------
  4. void OSD_linea(unsigned short x1, unsigned short y1, unsigned short x2, unsigned short y2, char color)
  5. {
  6.    //Declaro variables-------------------
  7.    signed short  x, y, incremento_x, incremento_y, distancia_x, distancia_y;
  8.    signed short P;
  9.    short i;
  10.  
  11.    //Calculo las diferencias entre las coordenadas de origen y destino
  12.    distancia_x = fabs((signed short)(x2 - x1));
  13.    distancia_y = fabs((signed short)(y2 - y1));
  14.  
  15.    //Inicializo x e y con las coordenadas de origen
  16.    x = x1;
  17.    y = y1;
  18.  
  19.    //Calculo el sentido de los incrementos (positivos o negativos)
  20.    //en funcion de la posicion del origen y el destino
  21.    if(x1 > x2) incremento_x = -1; else incremento_x = 1;
  22.    if(y1 > y2) incremento_y = -1; else incremento_y = 1;
  23.  
  24.    //Si la distancia horizontal es mayor a la vertical...
  25.    if(distancia_x >= distancia_y)
  26.    { P = 2 * distancia_y - distancia_x;
  27.       for(i=0; i<=distancia_x; ++i)
  28.       {
  29.           OSD_punto(x, y, color);
  30.  
  31.          if(P < 0)
  32.          { P += 2 * distancia_y;
  33.             x += incremento_x; }
  34.          else
  35.          { P += 2*distancia_y - 2*distancia_x;
  36.             x += incremento_x;
  37.             y += incremento_y;}
  38.       }
  39.    }
  40.  
  41.    //Si la distancia vertical es mayor a la horizontal...
  42.    else
  43.    { P = 2 * distancia_x - distancia_y;
  44.       for(i=0; i<=distancia_y; ++i)
  45.       { OSD_punto(x, y, color);
  46.          if(P < 0)
  47.          {  P += 2 * distancia_x;
  48.             y += incremento_y; }
  49.          else
  50.          {  P += 2 * distancia_x - 2 * distancia_y;
  51.             x += incremento_x;
  52.             y += incremento_y; }
  53.       }
  54.    }
  55. }

Bien, con esto queda planteada la forma de trabajar con el buffer de video. Ahora quedaría la traduccion de color (3bit por cada bit del buffer de video), la inversion de los datos de los TLC impares y el envío por el SPI.

Saludos!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 14 de Octubre de 2015, 15:34:19
buen ejemplo de modularidad si señor
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 14 de Octubre de 2015, 15:46:50
Vi que leo escribio antes que yo :P. De todas formas esto es lo que habia escrito

Quedaria algo asi :

Asi:
Buffer Leds: [16][16] - Estos indican solo los leds que se encienden, nada de color
Buffer Color: [3][16][16] - 3 arrays con colores, podria haber resumido un color antes, pero eso implica que un color si o si va.

O asi:
Buffer Color: [3][16][16]

El primero permite un grafico mas simple. ya que solo creas monocromatico y luego le agregas el color como quieras.
El segundo estas olbigado a incluir el color en la parte de graficar.

Tambien en el caso de que no solo sea un bit, sino 8 para un PWM por ejemplo. la parte grafica del primero no cambiaria. solo cambiaria la del color. Esto suponiendo que agregas el color aparte (Lo cual no tenes distincion de si es texto o no lo realizado en el array monocromatico).
Pero si supongamos queres hacer un texto color rojo, por ahi conviene pasarle el color de entrada y tener el 2do caso, complicando un poco mas el tema de la escritura de color

Aun asi te manejarias como si fuera monocromatico cada uno. esto facilita pasar el proceso grafico -> buffer , pero complica lo de generar el buffer -> buffer para TCL , ya que le quitas la parte de juntar los 3 bits y se lo pasas al otro.
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 14 de Octubre de 2015, 16:02:06
Entiendo, entiendo... el tema es que me parece que para el buffer de los TLC debe ser una matriz de 2 dimensiones, para poder utilizar el DMA. O sea que cada fila del cartel tiene que ser una sucesion de bits (48 + 1 por TLC) de modo que el DMA los tome y sauqe la fila completa.
En cuanto al buffer de video o gráfico, tendría que ver como son las implementaciones standar. Como manejan por ejemplo las librerías graficas un bmp...

saludos!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 15 de Octubre de 2015, 03:22:59
Si, yo hablaba solo de la generacion de la parte grafica. es decir pasar de tener un string, pasarlo a un mapa de bits, y que tenga su color.
Luego necesitarias otro codigo que transforme eso en el array que va a usar el DMA. Como empaquetar de a 3 bits, y mas etc.

El bmp :P
https://en.wikipedia.org/wiki/BMP_file_format

Sino vas a tener que crearte o buscar uno que transforme de BMP a hex xD
La otra posibilidad es que todo lo que vaya a donde se guarda estas "imagenes" por ejemplo. sea generado afuera por una computadora, Y que el micro solo lo unico que haga es leer ( usa SD por ejemplo, o una EEPROM ) llevar a RAM solamente la imagen a mostrar ( se podrian tener 2 buffers, asi mientras se muestra una se llena la otra ) y nada mas. Todo lo demas lo haria el DMA..

Y con eso se podria realizar una muestra de varias imagenes, si hay texto tomarlo como una imagen completa tambien, me refiero no tener un escribir_panel("Hola"), si que directamente cargue la imagen. Si el cliente desea cargar nuevas imagenes o una SD o un USB (pendrive ) que se conecte y asi actualizar la EEPROM con los nuevos datos.

Podes tener en la flash las "imagenes" del menu de configuracion, si es que posee algun menu.
Si queres extenderlo a mas paneles solo agregas un salida/entrada de sincronismo ( suponiendo que pones un integrado cada X paneles)
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 15 de Octubre de 2015, 20:37:02
Esta ultima idea me gusta mucho. Incluso el micro de cada grupo de paneles podría ser "chico" ya que es medio "bobo", recive datos procesados y se encarga de manejar los paneles. Esta en la onda que siempre me ha sugerido BrunoF, "divide y conquistarás".
Pensando en un display gigante, habría grupos de paneles (64x64 led's por ejemplo) manejados por un micro chico, que solo se encargue de recivir datos procesados (por ethernet, si forma parte de un conjunto grande de modulos o desde una SD si es un grupo de paneles para un pequeño pasamensaje, etc). En el segundo caso que es el que tengo que resolver mápido, tendría una aplicacion en la PC donde se configuren los mensajes y se procesan de acuerdo a lo que necesita la memoria del buffer para hacer uso del DMA de forma directa y se almacenen en la SD, luego el micro del cartel solo lee datos de la SD y los saca por el SPI usando DMA sin procesar nada.... lindo lindo lindo....
muere el stm32f411, renace el lpc11u67!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 15 de Octubre de 2015, 23:33:07
Si, lo que tenes que ver bien es el tema de:

- Sincronismo, lo cual seguro que te lleve un Maestro, Que puede ser uno de los paneles, o un maestro aparte.
- Almacenamiento, si lo vas a hacer Extensible asi tenes que ver como vas a mandar la seccion de la imagen para cada panel,

Igual esto serviria para imagenes fijas. y no tanto para una imagen movil creo yo. Si es que tambien pensas hacerlo para esos casos
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 20 de Octubre de 2015, 13:25:32
Bueno, me ha llevado un par de días, pero ya he conseguido hacer el cambio de micro al LPC11u67 (M0+) y pude cambiar el manejo de los datos de GPIO a SPI. Este micro está corriendo a 48MHz y en principio estoy más que bien para el cartel de 8 paneles de 32 columnas.

La rutina para enviar los datos (2x49 bits), bastante fea por ahora, es esta:

Código: C
  1. void TLC_send_data(uint64_t data_0_15, uint64_t data_16_31)
  2. {
  3.         uint8_t  i;
  4.         uint8_t TLC_Data[13];
  5.         uint64_t tmp_data=data_0_15;
  6.         uint64_t inv_data=0;
  7.  
  8.         TLC_Data[12] = (tmp_data & 0xFF);
  9.         tmp_data >>= 8;
  10.         TLC_Data[11] = tmp_data & 0xFF;
  11.         tmp_data >>= 8;
  12.         TLC_Data[10] = tmp_data & 0xFF;
  13.         tmp_data >>= 8;
  14.         TLC_Data[9] = tmp_data & 0xFF;
  15.         tmp_data >>= 8;
  16.         TLC_Data[8] = tmp_data & 0xFF;
  17.         tmp_data >>= 8;
  18.         TLC_Data[7] = tmp_data & 0xFF;
  19.  
  20.         tmp_data = data_16_31;
  21.         for(i=0;i<63;i++)
  22.         {
  23.                 inv_data |= tmp_data&1;
  24.                 inv_data <<= 1;
  25.             tmp_data >>= 1;
  26.         }
  27.         inv_data >>= 16;
  28.         inv_data <<= 1;
  29.  
  30.         TLC_Data[6] = inv_data & 0xFF;
  31.         inv_data >>= 8;
  32.         TLC_Data[5] = inv_data & 0xFF;
  33.         inv_data >>= 8;
  34.         TLC_Data[4] = inv_data & 0xFF;
  35.         inv_data >>= 8;
  36.         TLC_Data[3] = inv_data & 0xFF;
  37.         inv_data >>= 8;
  38.         TLC_Data[2] = inv_data & 0xFF;
  39.         inv_data >>= 8;
  40.         TLC_Data[1] = inv_data & 0xFF;
  41.         inv_data >>= 8;
  42.         TLC_Data[0] = inv_data & 0xFF;
  43.  
  44.         Chip_SSP_WriteFrames_Blocking(LPC_SSP1, TLC_Data, 13);
  45.  
  46.         for(i=0;i<50;i++);
  47.         //una vez enviados los 49 datos hago un latch
  48.         Chip_GPIO_SetPinOutHigh(LPC_GPIO, LAT_PORT, LAT_PIN);
  49.         Chip_GPIO_SetPinOutLow(LPC_GPIO, LAT_PORT, LAT_PIN);
  50. }
Hay una inversion a nivel de bit (el lazo for) y despues hay inversiones a nivel de byte. Esto es debido a como codificamos los datos en memoria vs como envía los datos el SPI.

Seguramente se puede optimizar y mucho, es una primera prueba con el objeto de hacer el paso a SPI.

Ahora voy a ver un poco de crear el buffer gráfico para poder escribir o poner gráfico y luego su traduccion a buffer que pueda tomar el DMA.
En principio ayudaría un poco poder hacer una estructura de datos de 13 bytes que me permita hacer desplazamientos de bits entre ellos. es posible?

Saludos!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 23 de Octubre de 2015, 10:46:09
pongo link de este excelente programa para crear font's para carteles, LCD o lo que se necesite:

http://www.pavius.net/the-dot-factory-an-lcd-font-and-image-generator/

con este programa estoy armando la/s fuentes para el cartel y la verdad que se facilita enormemente el trabajo.

Saludos
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: KILLERJC en 24 de Octubre de 2015, 04:09:54
Citar
En principio ayudaría un poco poder hacer una estructura de datos de 13 bytes que me permita hacer desplazamientos de bits entre ellos. es posible?

No entiendo a que te referis con eso..
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: Jay Electric en 20 de Mayo de 2016, 00:09:46
Hola Gente muchas gracias por todo lo compartido aqui, me han sacado muchas dudas y metido otras hehe y espero que el proyecto usando pwm lo hayas terminado elgarbe. Saludos
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 11 de Mayo de 2017, 10:09:10
Hola leonardo, se que hace tiempo de esto, pero me podrías decir como has alimentado las filas finalmente? yo estoy liado con matrices de led, para las columnas he utilizado un 74hc595 en paralelo con un ULN2803:

 - Tienes que ingresar para ver archivos adjuntos -


la matriz es anodo comun, y estoy calentandome la cabeza para alimentar las filas, en cada fila hay 64 led de 20 ma por lo que necesitaria un transistor de al menos 2 amperios.

tenia pensado poner un npn para alimentar las filas de esta manera (los transistores y valores no son los finales es solo un ejemplo:

 - Tienes que ingresar para ver archivos adjuntos -

La fuente de 1 voltio es para simular la caida de tensión del UNL al activar las columnas, el problema es que no encuentro un NPN de 2 amperios smd(necesario) que pueda disipar sin problema, un DPAK por ejemplo estaría bien, pero no encuentro.

¿Como solucionaste la alimentación de las filas? ¿barajaste las distintas opcines? ¿te fuiste a los mosfet? trabajo con uc de 3V3 o podria ponerle un 74hc595 para tener los 5V, lo digo por el gate.

Un saludo y gracias

Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 11 de Mayo de 2017, 11:23:40
Este es el esquemático que utilicé:
http://www.todopic.com.ar/foros/index.php?topic=43643.msg373244#msg373244

En las columnas tengo los LED driver de TI. En las filas un decodificador 4 a 16 que activan Mosfet's integrados.
Te sirve?
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 11 de Mayo de 2017, 11:57:53
¿Los mosfet se activan con los 3,3V de salida de los sn74ls138?

Supongo que la velocidad de conmutacion es buena, ya que yo solo tengo 8 filas y tu 16 si a ti te va bien sin problemas para mi entonces, ¿no colocas una resistencia de gate pequeñita para los picos al cargar el mosfet?

un saludo y gracias

y otra cosita, supongo que tu VCC es de 5Voltios verdad?
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 11 de Mayo de 2017, 12:54:18
Ahora que lo mencionas, recuerdo que mi socio me dijo lo mismo cuando lo revisó asi que volvi a abrir el altium y veo que el esquematico lo habia actualizado.
Este es el esquemático final:

 - Tienes que ingresar para ver archivos adjuntos -

el 74ls123 es un temporizador cuya funcion era deshabilitar las salidas cuando no se detectara cambios en las lineas de barrido vertical. Eso nunca me funcionó y nunca le busque la falla. Ahora que esttoy cin ek vúmetro lo voy a revisar para dejarlo andando.

Los 138 puse HC, no LS. Cuando compré puse los HC por las dudas de que el LS no de la velocidad.

Vcc es 5V efectivamente. En este nuevo esquematico esta la fuente de alimentacion

Saludos!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 11 de Mayo de 2017, 14:57:01
Gracias leonardo, si si que me sirver, ahora si me cuadra mas todo, aunque sigo teniendo una duda, ¿el zener DzA que funcion tiene? no logro verle la función.

un saludo y muchas gracias
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 11 de Mayo de 2017, 15:58:48
Todo el esquemático lo saqué (copie  :?) de una nota de aplicacion de ti. Te la voy a enviar a tu mail.
Ese zenner es para algo que se llama efecto fantasma que se da al cambiar de filas. Yo no noté cambios y termine sacándolo.

https://www.maximintegrated.com/en/app-notes/index.mvp/id/4111

Saludos


Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 11 de Mayo de 2017, 16:33:05
Muchas gracias leonardo, no creas que estoy intentando sacar fallos ni nada de eso  :D :D solo intento comprenderlo para aprender.

No sabia eso del efecto fantasma, algo mas para el cajon de los conocimientos, aunque por lo que dices no parece notarse demasiado.

Muchas gracias  ;-) ;-)

un saludo

PD: no me ha llegado nada al correo.
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 11 de Mayo de 2017, 16:43:39
Muchas gracias leonardo, no creas que estoy intentando sacar fallos ni nada de eso  :D :D solo intento comprenderlo para aprender.
Tendrías para entreterte mucho buscando fallos por que esta lleno de fallos. Lo pude hacer andar a fuerza de software, porque el hardware me quedo bastante mal. Mas que nada un conector invertido y un error con la alimentacion del drive de TI.

PD: no me ha llegado nada al correo.

No pense que lo necesitaras con tanta urgencia  :D
Fijate ahora.

Saludos!

Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 11 de Mayo de 2017, 17:15:12
haha no no me corre prisa, es que pensaba que ya lo habías enviado y no se si tendrás el correo que uso ahora por que sigue sin llegarme nada  :D :D

no te preocupes pasamelo cuando puedas no hay problema, el correo lo he comprobado y es el que tengo el perfil, si tiene algun adjunto lo mismo tarda bastante.


Citar
Mas que nada un conector invertido y un error con la alimentacion del drive de TI.

Los tipicos fallos tontos que tenemos todos y nos da ganas de tirarnos de los pelos  :D :D

un saludo y gracias.
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 11 de Mayo de 2017, 19:59:37
haha no no me corre prisa, es que pensaba que ya lo habías enviado y no se si tendrás el correo que uso ahora por que sigue sin llegarme nada  :D :D

no te preocupes pasamelo cuando puedas no hay problema, el correo lo he comprobado y es el que tengo el perfil, si tiene algun adjunto lo mismo tarda bastante.


Citar
Mas que nada un conector invertido y un error con la alimentacion del drive de TI.

Los tipicos fallos tontos que tenemos todos y nos da ganas de tirarnos de los pelos  :D :D

un saludo y gracias.

no encuentro tu correo en el perfil  :oops: mandame un mail a leogarberoglio@hotmail.com así te re agendo y te lo envío.

Saludos!
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 12 de Mayo de 2017, 12:14:16
Hola leonardo gracias por los documentos, por cierto ya se cual es la función del zener.

Si no colocas el zener y dejas las resistencias de 100 pasarían unos 5/100 = 50mA (despreciando la caida del zener) eso quiere decir que las resistencias deberian de ser de 1/2 watios para que vayan sobradas (0,25W de consumo) si queremos bajar la intensidad debemos subir la resistencias a 250 que daria una intensidad de 20mA y una potencia consumida de 0,1W que esta demasiado cerca del estándar 1/8 Watio, así que tienes dos opciones, o colocar resistencia de 250oh 1/4 de watio (no es una estandar asi que sera 255) o poner un Zener de 3V y resistencias de 100oh lo cual daría la misma intensidad que con la de 250 ohm (el efecto fantasma se reduciría de la misma manera)

(5-3)/100=20mA consumo 0,04Watios.
Las dos soluciones dan el mismo resultado, ya depende de que solución te guste mas, tambien hay que tener en cuenta que la potencia del zener sera:

20mA*nº de filas * 3V.

te lo dejo por aquí por si te sirve de algo.

un saludo
Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: juaperser1 en 12 de Mayo de 2017, 12:31:16
Yo voy a subir las resistencia a 1K en el drenador y quitar el zener, esto hará hace que se descarguen las capacidades parasitas en unos 400ns mas que suficiente y la potencia disipada es de 0,025W. Ademas de quitar 45mA de carga a los mosfet.

un saludo.

Título: Re:Proyecto: Cartel RGB 16x256px a 8 colores
Publicado por: elgarbe en 14 de Mayo de 2017, 15:30:41
Yo eliminé las R10 a 25 junto con el zenner.
Ese pin que dice AF1 va a la fila 1 de los LED, serían los ánodos de la fila 1.
Los cátodos se conectan todos a la columna X. La columna X va a un TLC5954, el cual es drive de LED (Corriente constante) programable. Como el Zenner no me producía ningun efecto, lo saque junto a las R, que sin el Z no sirven de nada.

Si no colocas el zener y dejas las resistencias de 100 pasarían unos 5/100 = 50mA (despreciando la caida del zener) eso quiere decir que las resistencias deberian de ser de 1/2 watios para que vayan sobradas (0,25W de consumo) si queremos bajar la intensidad debemos subir la resistencias a 250 que daria una intensidad de 20mA y una potencia consumida de 0,1W que esta demasiado cerca del estándar 1/8 Watio, así que tienes dos opciones, o colocar resistencia de 250oh 1/4 de watio (no es una estandar asi que sera 255) o poner un Zener de 3V y resistencias de 100oh lo cual daría la misma intensidad que con la de 250 ohm (el efecto fantasma se reduciría de la misma manera)

Si no pongo el Z por las R10 a 25 no pasa corriente, porque el camino a GND está a travez de los led y los TLC. Esas resistencias quedan "al aire".

sds!