Buenos protocolos basados ​​en RS232 para comunicación integrada en la computadora

Estoy trabajando en un proyecto que involucra una buena comunicación de datos entre un Arduino remoto y una computadora. La conexión inalámbrica es a través de un par de XBees, por lo que tenemos un enlace RS232 entre el Arduino y la computadora. Para pequeñas cantidades de datos, es bastante fácil reunir un protocolo de comunicación simple. Sin embargo, para proyectos más grandes, ¿cuáles son algunos buenos protocolos de comunicación simples?

He visto MODBUS, que parece una opción viable, pero quería ver si había otras opciones mejores.

El OP solicita un protocolo en serie para una situación en la que " no hay muchos [datos] y la velocidad no es un gran problema ". MODBUS se menciona en el OP MODBUS sobre RS-485 no es un protocolo rápido. Si bien esto no es una especificación, da una idea sobre el nicho.

Solo puedo pensar en dos protocolos estándar comunes para este nicho:

• NEMA 0183 . Protocolo ASCII de texto sin formato. Legible por humanos. Punto a punto solamente. No es compatible con el bus multipunto.
• MODBUS que ya se mencionó en el OP

Muy a menudo, cuando los programadores integrados se encuentran en una situación como la OP, diseñan sus propios protocolos de comunicación en serie desde cero.

Algunos protocolos de sistemas integrados, varios de ellos extremadamente simples, se enumeran en Sistemas integrados: Protocolos comunes , que incluyen:

• Tiny Embedded Network (TEN)
• Intérprete de microcontroladores para sistemas integrados en red (MINES)
• Otro protocolo escalable (YASP)
• Red de interconexión local (LIN)
• Servocontrolador en serie (SSC)
• Sistema operativo de robot en serie (rosserial)
• cadena de red
• varios autobuses de campo
• Modbus
• Red de área del controlador (CAN)
• Firmata (¡Gracias, jippie!)

Quizás uno de estos protocolos sería adecuado para su aplicación tal cual, o con solo pequeños ajustes.

Yo votaría el tuyo y lo mantendría lo más simple posible.

He tratado muchos protocolos en serie para diversas aplicaciones de control, y algunas cosas que puedo recomendar que incluyas son:

• Iniciar y detener caracteres que no se utilizan en otro lugar
• Algún tipo de suma de comprobación / comprobación de errores
• Algún método de control de flujo / señalización, especialmente si necesita comunicaciones bidireccionales.

Como un ejemplo muy básico, puede convertir sus datos a caracteres ASCII y pegarlos dentro de los caracteres de inicio / detención de esta manera:

Para enviar el valor de byte 0x7A, los datos enviados serían (7A), donde () son los caracteres de inicio / parada elegidos y 7 y A son dos caracteres ascii. OK, agrega muchos gastos generales, pero significa que puede depurar con un software de terminal básico.

Si sus datos pasan por XBees, debe poner los módulos en modo API con caracteres de escape, dividir sus datos en paquetes lógicos y aprovechar el hecho de que en modo API un paquete que se entrega a un XBee llegará intacto o De ningún modo. Diseñe su protocolo alrededor de la transmisión de fragmentos de 1-255 bytes, y deje que los módulos XBee se preocupen por cómo entregar los datos dentro de cada fragmento. No se preocupe por mantener la integridad de los paquetes individuales o las subdivisiones entre ellos. Los módulos Digi harán un buen trabajo al ocuparse de eso. Lo más importante de lo que debe preocuparse es el hecho de que incluso si el nodo que transmite un paquete cree que no se entregó y envía un reemplazo, el destinatario puede terminar obteniéndolo de todos modos, posiblemente incluso después de que reciba el reemplazo. Las cosas pueden ser más fáciles si diseña su protocolo de modo que un lado sea el "maestro"; Si el maestro solicita un dato, el esclavo debe enviarlo una vez y no preocuparse de si el maestro lo obtiene. Si el maestro no obtiene los datos que desea, puede solicitarlos nuevamente.

El esclavo debe asignar algún tipo de números de secuencia a los datos, y el maestro debe asignar números de secuencia a las solicitudes que el esclavo cambie de estado. Si la solicitud del maestro tiene la forma "envíe el primer elemento cuyo número de secuencia es mayor que XXX", y cada elemento de datos del esclavo incluye su propio número de secuencia y el del elemento anterior (si no están numerados consecutivamente ), los paquetes que llegan tarde pueden hacer que el esclavo envíe datos de forma redundante al maestro, pero el maestro no tendrá dificultades para ignorar las consiguientes respuestas de llegada tardía. Si el esclavo recibe una solicitud de cambio de estado cuyo número de secuencia está por debajo del de una solicitud anterior, debe ignorar esa solicitud, ya que fue reemplazada incluso antes de ser recibida.

¿Qué tal Firmata ? Tiene soporte para varios sistemas operativos y lenguajes de programación. El lado del controlador Arduino y PICduino son compatibles, pero eso no debería ser demasiado difícil de transferir a un microcontrolador simple.

Tenía una pregunta similar a esto y nunca encontré nada simple y lo suficientemente pequeño para pequeños AVR, etc. Así que hice algo inspirado en CAN. Se llama MIN (Red de interconexión de microcontroladores):

https://github.com/min-protocol/min

He blogueado sobre esto aquí:

https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/

Hay ganchos para datos de bloque, pero está principalmente dirigido a señales para sensores / actuadores. He definido un formato JSON para describir las señales y su empaque dentro de los marcos MIN y espero obtener un disector de Wireshark que lo use.