Opciones de interfaz de computadora a Arduino

¿Qué tal si solo enviamos bytes cambiados cada 20 ms? Necesitaría 9 bits adicionales para el direccionamiento, pero si rellenara ese bit en el bit vacío en sus datos de color de 15 bits, podría hacerlo con solo un byte adicional por LED. Dependiendo de la rapidez con la que la pantalla cambia de color, eso podría funcionar bien. Podría hacer un umbral, por lo que si el color cambia en menos de X, espere a que la próxima ronda envíe esos datos.

¿O tal vez intente entrelazar los datos? ¿Enviar filas iguales y filas impares en secuencia alterna?

¿O usar 4 Arduinos en paralelo?

¿O puede controlar los LED a través de un registro de desplazamiento y luego enviar 15 bits a 15 pines Arduino a través de un puerto paralelo (suponiendo que pueda encontrar una PC con un puerto paralelo)?

El factor limitante es probablemente el puerto serie de su computadora, los controladores y / o la biblioteca Arduino. Si recuerdo correctamente, el AVR UART puede subir a su velocidad de reloj dividido por 8 o 16, y un chip FTDI puede tener velocidades de transmisión arbitrarias igualmente altas (3 Mbaud para este FT232RL en mi escritorio).

La mayoría de los escudos se comunicarán a través del AVR UART, por lo que si la biblioteca de Arduino te limita, no te ayudarán.

Con el hardware adecuado, Windows puede manejar la comunicación en serie hasta 921600bps (115200 x2, x4, x8). Hay tarjetas de comunicación PCI que admiten esta velocidad en baudios, pero las más populares son los convertidores USB < > RS232. Si recuerdo bien, todos los convertidores basados en FTDI pueden manejarlo. El problema más grande es el lado AVR, donde no podrá hacer nada más mientras se reciben los datos. RX debe ser la única interrupción permitida en el lado AVR. Es probable que también tenga que marcar su AVR tan alto como pueda (16 o 20MHz según el modelo, 14.746 Mhz si desea tener 921600 exactamente ). Luego, enviará desde la PC todo el paquete de comunicación, AVR hará el trabajo después de recibirlo y enviará el byte de confirmación de que está listo para el siguiente paquete. Cuando la PC recibe el reconocimiento, puede enviar otro paquete. Y así sucesivamente ... Los temporizadores simples en el lado de la PC son (debido a la multitarea en Windows) muy mal para manejar 10ms como la resolución y no son precisos en absoluto (excepto los temporizadores multimedia cuando se manejan adecuadamente), por lo que usar un byte de confirmación simple ya descrito Una opción mucho mejor.

No sé qué escudos están disponibles, solo soy un tipo de microcontrolador en general.

A medida que aumenta su velocidad de transmisión, un protocolo síncrono tiene mucho sentido. SPI es muy simple y permitirá velocidades de transmisión de más de 1Mbps muy fácilmente.

Sin embargo, si solo necesita llegar a 300kBaud o incluso 1MBaud y está de acuerdo con UART, la línea de chips FTDI es lo real. trato .

Uno de los chips que puede hacer esto específicamente es el FT2232H . Estos no son compatibles con SPI, pero pueden manejar UART muy rápido. De sus especificaciones:

  

Datos de transferencia UART RS232 / RS422 / RS485   Tasa hasta 12Mbaud. (RS232 Data Rate   limitado por el desplazador de nivel externo).

Los arduinos son impresionantes, pero tienen sus limitaciones. A menos que esté programando en C y simplemente haciendo uso del gestor de arranque arduino, tenderán a ejecutarse mucho más lento. No soy un gran gurú en cuanto a las tasas de datos, etc. pero esperaría que a 50 hz estuvieras en la pared por las capacidades de los arduinos. Sugeriría mirar la programación en C (hackaday.com acaba de hacer un gran conjunto de tutoriales sobre esto) o probar con otro microcontrolador, mi favorito para proyectos como este es el propulsor de paralaje esencialmente 8 microcontroladores en uno.