Diseño del protocolo de comunicación serie Arduino

Hago una interfaz de secuenciador de batería para música electrónica .

Utiliza un mega arduino como microprocesador, y actualmente se conecta a un programa de procesamiento que escribí para comunicación en serie. A partir de ahí, los mensajes OSC se envían a un programa Max / MSP que mi socio colaborador escribió para crear un flujo de datos midi.

Entonces:

Mi interfaz física -> Arduino Mega -> E / S en serie -> Procesamiento -> OSC -> Max / MSP -> Midi (-> aplicación de música)

Elegí este camino en parte por no ser lo suficientemente inteligente como para eliminar ninguno de los pasos todavía, pero también para poder actualizar la interfaz física de la manera que queremos, poder hacer que la interfaz física sea multipropósito (múltiples modos para faders, perillas y botones de selección de voz), y poder garantizar el tiempo crítico de la misión y la modificación del ritmo (también conocido como "swing").

Mis mensajes en serie se configuran así:

PL,1;        // transport control: play
PL,0;        // transport control: stop
SW,30;       // swing value 30
TM,130;      // tempo value 130
SD,1,8,04,0; // Step sequencer data, pattern 1, voice 8 (of 8), step 04 (of 16), off
MU,8,1;      // Mute, voice 8 (of 8), on
SO,4,0;      // Solo, voice 4 (of 8), off
VL,3,127;    // Velocity, voice 3 (of 8), value 127
CC,1,127;    // Midi CC, controller 1, value 127
NN,1,36;     // Note number, voice 1 (of 8), value 36 (usually a kick drum)

Entonces, puede ver que según el número de comas por punto y coma, puedo determinar cómo analizar los datos en serie del arduino en el programa de procesamiento. Desde Procesamiento, este tipo de mensajes se transforman en OSC de esta manera:

/beatseqr/play 1
/beatseqr/play 0
/beatseqr/swing 30
/beatseqr/tempo 130
/beatseqr/matrix/1/8/04 0
/beatseqr/mute/8 1
/beatseqr/solo/4 0
/beatseqr/velocity/3 127
/beatseqr/midicc/1 127
/beatseqr/midinn/1 36

Y todo funciona bien, pero se siente ineficiente. ¿Realmente necesito la aplicación de procesamiento en el medio?

Ahora, había intentado cortar el procesamiento y las partes OSC de la ecuación, pero me falta algo de conocimiento con respecto al diseño del protocolo de datos en serie.

Soy consciente de que hay un udpreceiveobjeto en Max. Y eso funciona bien, supongo. Tal vez lo estoy usando mal.

En un punto, cambié todo mi código arduino para no enviar nuevas líneas al final de cada mensaje en serie, ya que eso no significaba nada especial para el udpreceiveobjeto de Max . De hecho, si recuerdo correctamente, solo aceptaría el primer mensaje hasta la primera línea nueva y luego dejaría de procesar datos. Entonces, para evitar eso, eliminé todos los caracteres de nueva línea y luego vomitaría en max / msp continuamente.

Entonces, el siguiente problema con este método es que el udpreceiveobjeto solo acepta un carácter a la vez. Así que estaba tratando de usar un jsobjeto javascript para concatenar los caracteres entrantes y luego analizarlos en punto y coma y comas. El problema que encontré allí fue que era impredecible e inestable. Los caracteres se abandonarían y el mensaje no sería procesable. ¿Entonces realmente me hace preguntarme si debería cambiar mi protocolo de datos en serie a algo más robusto? ¿O si solo lo estoy haciendo mal por completo?

¿Debo desecharlo todo y empezar de cero desde cero con un firmware firmata? He visto algunos tutoriales para usar la firmata con Max / MSP , y creo que podría echar un vistazo a lo que está haciendo el código en la caja y si es necesario. ¿Puede la firmata aceptar datos de cadena en un pin para enviar a la pantalla LCD en serie integrada? si puedo controlar la pantalla LCD desde max / msp, eso podría funcionar bien.

¿Tienes algún consejo?

¿Es posible que su problema sea causado por Arduino? Sé que suena extraño, porque Arduino depende en gran medida de la comunicación en serie y no suele fallar. Pero le sugiero que pruebe su Arduino con diferentes velocidades, descargando datos legibles por humanos y monitoreando con un programa de terminal. He tenido el mismo problema y eso fue causado por un problema de tierra de mi arduino. Además, otra solución podría ser el uso de un diseño arduino personalizado con velocidades de reloj amigables en serie como 14.7456MHz o cualquier valor múltiplo de 3.6864MHz. Espero eso ayude...