Opciones de interfaz de computadora a Arduino

¿Qué hay de enviar solo bytes modificados cada 20 ms? Necesitaría 9 bits adicionales para el direccionamiento, pero si metiera 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 qué tan rápido su pantalla cambie de color, eso podría funcionar bien. Podría hacer un umbral, de modo que si el color cambia menos de X, espere a la siguiente ronda para enviar esos datos.

¿O tal vez intentar entrelazar los datos? ¿Enviar filas pares e impares en secuencia alterna?

¿O usar 4 Arduinos en paralelo?

¿O 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 no recuerdo mal, el AVR UART puede subir a su frecuencia de reloj dividida por 8 o 16, y un chip FTDI puede tener velocidades de transmisión arbitrarias igualmente altas (3 Mbaudios 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 Arduino lo limita, no lo ayudarán.

Con el hardware adecuado, Windows puede manejar la comunicación en serie hasta 921600 bps (115200 x2, x4, x8). Hay tarjetas de comunicación PCI que admiten esta velocidad de transmisión, pero los convertidores USB<>RS232 son más populares. Si no recuerdo mal, todos los convertidores basados ​​en FTDI pueden manejarlo. El mayor problema 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. Probablemente también tendrá que sincronizar su AVR lo más alto que pueda (16 o 20MHz dependiendo del modelo, 14.746 Mhz si quiere tener 921600 exactamente). Luego, enviará desde la PC todo el paquete de comunicación, AVR hace el trabajo después de recibirlo y envía un byte de confirmación de que está listo para el próximo paquete. Cuando la PC recibe 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 malos para manejar una resolución de 10 ms y no son precisos en absoluto (excepto los temporizadores multimedia cuando se manejan correctamente), por lo que usar el byte de reconocimiento simple ya descrito es una opción mucho mejor.

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

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

Sin embargo, si solo necesita llegar a 300 kbaudios o incluso a 1 MBaud y está de acuerdo con UART, la línea de chips FTDI es el verdadero negocio .

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:

Velocidad de transferencia de datos UART RS232/RS422/RS485 de hasta 12 Mbaudios. (Velocidad de datos RS232 limitada por un cambiador de nivel externo).

Los Arduinos son geniales, pero tienen sus limitaciones. A menos que esté programando en C y solo esté utilizando el cargador de arranque arduino, tenderán a funcionar mucho más lento. No soy un gran gurú de las tasas de datos, etc., pero esperaría que a 50 Hz estés chocando contra la pared por las capacidades de 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.