Libreria CCS para controlar LEDs WS2811/WS2812

[migsantiago]

Gracias 

La idea es que vaya dibujando video desde la SD card. Por ahora eso está fallando. Le estoy mandando el video temporalmente por UART a 115200bps en lo que vemos cómo sacar video sin depender de la compu, ya sea de la SD o desde una memoria ROM paralela que no necesite SPI.

Ya después podríamos enviarle video en tiempo real pero habría que implementar algo como Ethernet o USB (en otro PIC que sí funcione) para soportarlo. 

[Marttyn]

Estas usando la libreria que puse yo? O una propia/adaptacion?
Lo que he notado es que tiene cierto retardo estos leds, por lo sacar video en tiempo real es algo imposible.
Hace unos meses hicimos una pantalla de casi 800 leds de estos,  y mover un punto de color por cada uno de todos los leds podia llevar unos 18 segundos creo!

[migsantiago]

Hola Marttyn, es un código propio. Hasta ahora sólo hemos dibujado 274 LEDs a 30 cuadros por segundo. Se han comportado bien. En unos días tendremos la oportunidad de dibujar más, ya te contaré qué tal. Saludos. 

[Marttyn]

Esa es una buena cantidad de LEDs, y con un refresco de 30 veces por segundo esta GENIAL!
Yo estaba planteandome armar un dispositivo POV con estos LEDs, pero lo descarte.
Podrias compartir de que manera envias los datos, o la libreria que usas para controlar los LEDs?
A que velocidad corre tu micro? Entiendo que el protocolo de comunicacion no se puede acelerar, aunque quizas lo que demora tanto el refresco son las operaciones que hago antes de enviar los datos...
Cuando maneje 800-1000 leds fue con un arduino mega, y notaba bastante demora.

[migsantiago]

Pues utilizo el SPI en modo enhanced a 12.5MHz en modo de 16 bits. Escribo los siguientes valores para denotar un 1 o un 0 lógicos...

/**
 * Logical 0 and logical 1 for the WS2812B LEDs with a 12.5MHz SPI
 */
#define SPI_BIT_0                       (0xF800)
#define SPI_BIT_1                       (0xFFC0)

El ancho de pulso se modula automáticamente con el SPI.

El modo enhanced te da oportunidad de guardar 8 palabras de 16 bits... lo que equivale a 8 bits en modo WS2812B... lo que equivale a mandar un byte WS2812B por cada enhanced buffer.

Trabajando con tal SPI y a tal velocidad, el ancho de cada bit en total mide 1.28us, que entran en los tiempos permitidos del WS2812B.

El truco está en no perder interrupciones y siempre tener los datos a la mano. Esto es posible con los 200MHz del PIC32MZ y con su fantástica memoria de 512kB en la que puedo almacenar buffers a modo ping-pong.

Actualmente nos faltan pruebas finales. La conversión de videos, GIFs e imágenes de cualquier tipo fue un dolor de cabeza... sobre todo por el que hay pixeles "muertos" en la matriz y por estar ordenando el dibujado de todos los pixeles en modo serpiente.

Toda la conversión la hago en C# y genero una imagen raw para la SD card, sin file system, para agilizar el despacho de pixeles muy rápidamente.

Cuando quede listo espero que Akenafab pueda compartirlo. Es para un cliente y debemos mantener la confidencialidad hasta cierto punto. 

[Marttyn]

Yo hice pruebas por SPI, y no consegui los resultados que esperaba. Estaba utilizando un PIC12F1840 con 32MHz internos. Pero midiendo con osciloscopio creo recordar que los tiempos de SPI eran mas amplios que lo que deberian ser. Quizas fue que no supe configurar bien el SPI y por eso los tiempos no se correspondian. Por otro lado, creo que ese pic no tenia buffer, y tenia que estar pendiente de escribirle el byte a enviar cada vez, lo que me hacia perder tiempo entre byte y byte. Y quizas era por esto que los tiempos eran mas largos de lo esperado

Como se carga el SPI sin perder tiempo entre byte y byte?

Concuerdo en que debes guardar confidencialidad sobre el proyecto de tu cliente, pero supongo que no tendra los derechos sobre la libreria de WS2812, no? 

[migsantiago]

Como se carga el SPI sin perder tiempo entre byte y byte?

Concuerdo en que debes guardar confidencialidad sobre el proyecto de tu cliente, pero supongo que no tendra los derechos sobre la libreria de WS2812, no? 

Los cargo en la interrupción del enhanced buffer. La activo cuando las 8 palabras del buffer ya se enviaron, y cuando ya puedo depositar otras 8 palabras nuevas.

Es que no hay librería como tal Marttyn, sólo es depositar los datos en el enhanced buffer como te menciono. El orden de los bytes y pixeles lo determina tu matriz. 

Le di un vistazo a la librería que publicas al principio y me doy cuenta de que le dejas mucha tarea de procesamiento al PIC... yo lo hice al revés... C# prepara los datos en RAW en la SD card y lo que lee el PIC es lo que manda... casi no le hace procesamiento, sólo se encarga de saber cuántos datos ya mandó.

El orden de los bytes es igual al que pide el WS2812B, GRB.

Se necesita un micro potente para esto, aún sin procesamiento, ya que el mover datos a tan alta velocidad es primordial.

Sería ideal usar DMA como un post en Hackaday, pero Harmony no compila DMA bien y pues por ahora estoy bien sin DMA.

[Marttyn]

No me extraña... Acabo de ver que tu micro correa 200MHz!  Mi primer PC era de 200Mhz...
La primera vez lei 20 mhz, y por eso me estrañaba que funcionara tan bien, y el mio va a 32mhz fuera mal.

Tienes (tu o algun otro usuario del foro) experiencia con SPI?
Porque el problema que veo es que cada vez que cargo un dato a enviar pierdo tiempo. Los enhanced mid range, al menos los que yo uso (12F1840, 16f1824, etc) creo que hay que cargarle cada dato, UNO A UNO....

Lo que no entiendo es como no hay un buffer o algo, ya que si hay un hardware dedicado, pero hay que cargar los valores uno a uno, casi no tiene ventaja sobre hacerlo por software.

Creo que me estoy perdiendo algo, sino como lees o escribes una tarjeta SD? Hay que detener la transmision luego de enviar o recibir cada byte para leer o escribir en el registro de salida/entrada?

[migsantiago]

jejej Sí, son 200MHz, es rápido el condenado PIC 

Sí, ya usé el SPI de este micro, y me resbalé, tropecé y corregí:

http://www.todopic.com.ar/foros/index.php?topic=44054.msg365076#msg365076

Sí, no te conté la maravilla de este micro, tiene 6 SPIs independientes. Sí... 6.

Entonces... con un SPI estoy leyendo la SD Card mientras que con los otros dibujo LEDs.

Dinos que PIC usaste y podemos ver que SPI tiene... veremos si es SPI viejito o si ya trae el enhanced mode con buffers integrados (FIFO).

Es importante notar que un byte WS2812B equivale a 8 palabras de 16 bits de SPI. El tiempo entre interrupción e interrupción de esos 8 bits WS2812B es de 10us... cosa que un PIC normal no puede manejar.

Saludos.

[KILLERJC]

Conseguite uno con QSPI y serias aun mas feliz , las tasas de refresco se dispararian en x4 a comparacion de un SPI. Aunque seguiria siendo limitante el tema de la lectura SD , a no ser que exista una RAM externa (QSPI tambien)que se pueda pasar los datos ahi y de alli actualizar

Y si haces lo que dice mig de tener los datos RAW directamente en la SD, no deberia haber problema para crear la salida binaria con un programita de una PC.

[Marttyn]

Dinos que PIC usaste y podemos ver que SPI tiene... veremos si es SPI viejito o si ya trae el enhanced mode con buffers integrados (FIFO).

Estuve usando un PIC12F1840. Con sus 32Mhz consigo que los tiempos vayan bien por sofware, incluso creo que con 8Mhz tambien iba si usaba el protocolo a 400KHz.

[KILLERJC]

Con 32Mhz el clock del SPI podria ir a un maximo de 3.3Mhz ( 3Mhz para estar seguro )

Tomando los limites:
Tcy = Fosc/4 =125ns
el tiempo en alto del clk ( Tcy + 20ns ) + tiempo en bajo ( Tcy + 20ns ), estariamos aproximadamente en 290ns siendo el limite. T = 300ns si contamos algo la subida y bajadas.

2.4us para enviar un byte completo + imagino que tendra un tiempo muerto entre esto de un ciclo

si tomo lo que migsantiago dijo sobre que son 8 palabras de 16bits o 16 de 8 bits. 16 * 2.4us = 38.4us

casi 4 veces mas de lo que migsantiago maneja... :/

[migsantiago]

Sí, con ese PIC no puede hacerse nada por SPI con los LEDs. No sabía que existiera el modo de 400kHz, supongo que sólo es para los WS2811.

Necesitas algo más rápido Marttyn.

[Marttyn]

Me pico la curiosidad, y he visto que hay un loco por ahi que saca video a 30 frames por segundo con un arduino. Lleva los PWM a sus minimos y maximos, aprovechando que los WS2812 no son muy estrictos con el timing y parece que lo consigue. Ademas no utiliza 3 bytes de memoria por cada pixel, por lo visto lo genera al vuelo: http://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/

[KILLERJC]

Me pico la curiosidad, y he visto que hay un loco por ahi que saca video a 30 frames por segundo con un arduino. Lleva los PWM a sus minimos y maximos, aprovechando que los WS2812 no son muy estrictos con el timing y parece que lo consigue. Ademas no utiliza 3 bytes de memoria por cada pixel, por lo visto lo genera al vuelo: http://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/

utiliza delays, envia 3 bytes ( 1 por cada color ) y esta seria la clave de todo ( el envio del bit, que como mirando el codigo esta usando los valores "tipicos" y no minimos ):

Código: [Seleccionar]

void sendBit( bool bitVal ) {
 
    if ( bitVal ) {      // 1-bit
 
      bitSet( PIXEL_PORT , PIXEL_BIT );
 
      DELAY_CYCLES( NS_TO_CYCLES( T1H ) - 2 ); // 1-bit width less overhead for the actual bit setting
                                                     // Note that this delay could be longer and everything would still work
      bitClear( PIXEL_PORT , PIXEL_BIT );
 
      DELAY_CYCLES( NS_TO_CYCLES( T1L ) - 10 ); // 1-bit gap less the overhead of the loop
 
    } else {             // 0-bit
 
      cli();                                       // We need to protect this bit from being made wider by an interrupt
 
      bitSet( PIXEL_PORT , PIXEL_BIT );
 
      DELAY_CYCLES( NS_TO_CYCLES( T0H ) - 2 ); // 0-bit width less overhead
                                                    // **************************************************************************
                                                    // This line is really the only tight goldilocks timing in the whole program!
                                                    // **************************************************************************
      bitClear( PIXEL_PORT , PIXEL_BIT );
 
      sei();
 
      DELAY_CYCLES( NS_TO_CYCLES( T0L ) - 10 ); // 0-bit gap less overhead of the loop
 
    }Otra diferencia esto:

the AVR in an Arduino can toggle a bit from low to high and back again in 4 cycles if you are careful, so we have time.

Habla de 16Mhz y con eso puede hacer que la señal suba y baje en 4 ciclos , cuando tiene que lograr 500ns donde estos serian 8 ciclos.
Mientras que si vamos a un PIC 16Mhz da un Tcy=250ns , solo hariamos la mitad. Mientras uno sube y baja 2 veces en el PIC solo lo hariamos 1 vez.

La diferencia entre lo que dice migsantiago es que en este codigo esta enviando 8 bits por cada color ( 3 bytes a cada led) que es lo justo y necesario. A mig tal ves se le triplica por el hecho de usar el SPI con un duty de 50% (no puede modificarlo ) haciendo que el 1 sean ( 2 unos y un 0) y el 0 ( 1 uno y 2 ceros ). Lo que dije antes es un supuesto ya que habria que ver los timing si dan.
El tema que esto te deja solamente dedicarte a eso para tener un ratio constante de actualizacion, mientras que con SPI te liberas muchisimo y se lo dejas unicamente al modulo. Podrias tranquilamente enviar mas rapido hasta que el led lo permita

Recien leo tu pregunta:

Como se carga el SPI sin perder tiempo entre byte y byte?

Y estuve viendo el PIC que nombraste y tiene un solo buffer para envio y recepcion, pero incluso el 16F887/16f628 poseen el buff separado, entonces vos cargas el buffer este se carga en otro registro que lo va dezplazando y ya te permite cargar otro dato mas sin perder tiempo entre bytes ( ya que tendrias uno en el buff + 1 en el registro de dezplazamiento )