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

Estoy trabajando en un proyecto que involucra una buena cantidad de 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 crear un protocolo de comunicación simple. Sin embargo, para proyectos más grandes, ¿cuáles son algunos buenos protocolos de comunicación simples?

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

¿Cuáles son exactamente los requisitos?
Buscando sugerencias generales. La simplicidad y los gastos generales bajos serían los principales objetivos del proyecto.
Lo siento, también quise decir: cuántos datos, qué tan rápido
No tengo medidas cuantitativas para eso, pero no mucho y la velocidad no es un gran problema.
No mucho y la velocidad no es un problema, argumentan fuertemente a favor de algo legible por humanos, ya que hace que el desarrollo y la depuración sean mucho más fáciles. Es genial cuando puedes conectar una terminal y sustituirte por cualquiera de los extremos del enlace.

Respuestas (6)

El OP solicita un protocolo en serie para una situación en la que " no 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. Solo punto a punto. No admite 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 del 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:

Tal vez uno de estos protocolos sea adecuado para su aplicación tal como está, o con solo ajustes menores.

Votaría por su cuenta y lo mantendría lo más simple posible.

He trabajado con muchos protocolos seriales para varias aplicaciones de control, y algunas cosas que puedo recomendarle que incluya son:

  • Caracteres de inicio y parada que no se utilizan en otros lugares
  • 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 caracteres de inicio/parada como este:

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. Está bien, agrega muchos gastos generales, pero significa que puede depurar con el 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 para nada. Diseñe su protocolo en torno a la transmisión de fragmentos de 1 a 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 encargarse 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 recibiéndolo de todos modos, posiblemente incluso después de recibir el reemplazo. Las cosas pueden ser más fáciles si diseña su protocolo para 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 volver a solicitarlos.

El esclavo debe asignar algún tipo de número de secuencia a los datos, y el maestro debe asignar números de secuencia a las solicitudes de cambio de estado del esclavo. Si la solicitud del maestro es de la forma "envíe el primer elemento cuyo número de secuencia sea 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 manera redundante al maestro, pero el maestro no tendrá dificultad en ignorar las consiguientes respuestas que llegan tarde. Si el esclavo recibe una solicitud de cambio de estado cuyo número de secuencia es inferior al de una solicitud anterior, debe ignorar esa solicitud, ya que fue reemplazada incluso antes de que se recibiera.

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

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

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

He blogueado sobre eso aquí:

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

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