Proyecto: Cartel RGB 16x256px a 8 colores

[elgarbe]

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, 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!

[Suky]

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

[elgarbe]

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!

[planeta9999]

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

[KILLERJC]

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

[elgarbe]

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!

[KILLERJC]

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

[elgarbe]

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!

[Suky]

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

[elgarbe]

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!

[elgarbe]

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!

[BrunoF]

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!

[elgarbe]

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:





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  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!

[planeta9999]

.

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.

[KILLERJC]

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.