Driver MBI6023 y Arduino Nano

[Faquir]

Hola a todos. Tengo una barra LED de 24 canales y uno de intensidadncontrolada por DMX a la cual se le dañó el microprocesador y cuento con un Arduino Nano con el cual quiero sustituir el micro antes mencionado. Tengo la hoja de datos del Driver de LED MBI6023 que es el que controla las salidas RGB. Tengo un proyecto que le grabé al micro y no me funcionó y quería saber si alguien me puede ayudar respecto al tema. Aquí les dejo el proyecto y la hoja de datos del driver MBI6023.
Ya tengo un proyecto DMX funcionando, el cual vincularía a este proyecto y quedaría la barra LED funcionando como vino originalmente.
Gracias de antemano.

 

[Nuyel]

La función prefix no debe enviar nada, ni siquiera el ciclo de reloj, según la hoja de datos, el inicio del paquete se detecta por timeout de los datos ingresados por un periodo que debe ser superior al equivalente de 172 ciclos, sin embargo, en tu código estas enviando pulsos de reloj y eso se interpreta como datos en 0, en el grafico la línea de reloj se mantiene baja durante el prefix.
Prueba corregir esa parte primero, ya sea que el bucle se mantenga en 0 o solo introduzcas un delayMicroseconds(25); por ejemplo, desconozco de cuál sería la frecuencia de reloj que realmente esté aplicando el controlador al procesar todo, honestamente recomendaría más procesar todo primero y luego mandarlo usando el SPI directamente para que el reloj sea más consistente y podrías aprovechar el tiempo del procesamiento como el tiempo muerto necesario para el prefix.

 

[Faquir]

Ahí es donde tengo la duda. Es que si envío por i2c no estaría enviando los datos correctamente. La forma d enviar datos según el datasheet, no es de 8 bits, es un poco extraña. Es una transferencia d datos específica. Tengo dudas al respecto y me gusta mucho la programación pero este proyecto está un poco complicado.

 

[Nuyel]

Por eso, se puede enviar solo que necesitas formatear primero, o sea, tomas los 6 bits de la primera parte y los 2 de la segunda y la mandas, luego cuando se completa envias los 8 restantes, como indica el chip, es necesario un tiempo muerto para que comience a detectar el siguiente paquete, si los datos no llegan completos en ese periodo pues se ignora por lo que incluso si te sobra bits al usar el SPI, no debería pasar nada al final. Recuerda que no es I2C, esa es distinta y el controlador espera un ACK que no va a recibir por lo que la comunicación se cancela.

 

[Faquir]

Tienes toda la razón, es SPI y no i2C. Ahora estoy estudiando para una nueva versión del proyecto. En lo que aún tengo duda es en la forma de enviar los datos, el datasheet especifica una trama y por el protocolo sería en otra forma. Tengo que crear el nuevo proyecto y ponerlo a prueba a ver que resultados obtengo.

 

[Nuyel]

Crea un buffer con un array y luego lo vas llenando según los requisitos del protocolo, una vez que tengas todo el array listo lo pasas con SPI.transfer(buffer, size) y ya la API se encarga de mandar todos los bytes en serie.
Revisaba las cuentas y son en modo de 16 bits 6 bytes para el header y 24 para los datos, en el de 10 bits son 30 bit del header y 15 bytes de datos, aquí habría 2 bits extra, habría que probar si causa afectación, pero una forma en la que puedes evitar problemas es ocupar los 32 bits(4bytes) con los primeros 2 bits en 0, según la hoja de datos, chip comienza a reconocer el comando desde que recibe el primer 1 en SDI por lo que probablemente ignorará esos dos bits en 0 y puedes pasar el comando en los siguientes 6 del mismo byte.