uart protocolo de comunicación

comandos de longitud variable

Muchas personas prefieren los comandos de longitud fija. Si necesita tener comandos de longitud variable, debe pensar en:

• ¿Es posible que un ruido accidental (o bromistas malintencionados) genere algo que desbordará mi búfer de recepción?
• Si un poco de ruido invierte la parte alta del campo de "longitud" de un paquete corto (lo que parece ser un paquete largo), ¿mi sistema se recupera correctamente?
  • malo: el microcontrolador lo detiene todo, esperando el resto de lo que cree que es un paquete "largo". Varios días después, después de muchos intentos frenéticos de enviar mensajes diciendo "desplegar las bolsas de aire", "bajar las barras de control", "Abrir las puertas de la bahía de la cápsula, HAL", etc., finalmente obtiene todos los bytes que esperaba, ve que la suma de comprobación falla, tira este "paquete largo" y comienza a funcionar normalmente otra vez.
  • bueno: después de un minuto o algún otro tiempo razonable, el microcontrolador agota el tiempo de espera, borra todo lo que se encuentra en el búfer de comandos (posiblemente descartando algunos mensajes de "despliegue de airbags" después del mensaje de longitud dañada) y comienza a funcionar normalmente de nuevo .
  • bueno: el microcontrolador reconoce inmediatamente que hay un error en el encabezado (que incluye el byte de inicio, el campo de longitud y la suma de comprobación del encabezado), e inmediatamente elimina ese encabezado y comienza a buscar nuevamente el byte de inicio. El microcontrolador inmediatamente comienza a funcionar normalmente nuevamente, reconociendo el primer comando válido (la suma de comprobación del encabezado es buena, y también la suma de verificación de los datos es buena) después del comando dañado.
• ¿El microcontrolador envía inmediatamente un ACK después de ver que la suma de comprobación (final) del paquete es buena, y luego ejecuta el comando y finalmente envía una respuesta a ese comando? ¿O es mejor enviar solo el ACK o solo la respuesta? ¿Cuál facilita la depuración?

consejos generales de diseño de protocolos

Hay muchos más o menos simples protocolos enumerados en el "Wikilibro de programación en serie" .

Si tienes suerte, quizás uno de ellos ya sea perfecto para tu aplicación. O al menos lo suficientemente cerca como para que solo requiera un poco de ajuste para que quepa.

Casi todos los que desarrollan con éxito un nuevo protocolo pasan por estas fases:

• 1 Puede que no sepa mucho, pero leer los protocolos de otras personas me causa dolor de cabeza. Parece un montón de complejidad innecesaria. Volcemos todo eso y construyamos un protocolo bonito y simple.
• 2 No está funcionando. Tal vez si agrego [característica 1], entonces funcionará.
• 3 Mejor, pero aún no funciona muy bien. Tal vez añadir [característica 2]? ...
• 98 Finalmente está funcionando. Será mejor que escriba quién hace qué en mi protocolo simple, de modo que si necesito cambiar a un microcontrolador diferente o quiera escribir un programa mejor en la PC, recordaré cómo me va.
• 99 Es curioso cómo mi protocolo simple toma tantas páginas para describir.

Hay muchos protocolos disponibles. Uno de mis favoritos es el Modbus. protocolo Modbus

Si solo hay una conexión maestro-esclavo, parece que has hecho todo lo que necesitas hacer. Utilice un algoritmo de suma de comprobación CRC estándar, pero eso es todo lo que hay que estandarizar de manera significativa. No te preocupes por tener un protocolo oficial ISO / IEEE.

No sé para qué sirve su aplicación, pero si está tratando de hacer algo en un "mercado definido", investigue ese mercado e intente usar algo que esté implementado allí. En SCADA, Modbus en cualquiera de sus dos o tres versiones (dos en serie y una es IP) es una buena apuesta. En CCTV, Pelco D es una buena apuesta. Todos estos protocolos son fáciles de implementar y están documentados. Y además, hay otros protocolos en el mismo mercado, así que diviértete decidiendo qué quieres hacer. Todos los protocolos que puede encontrar pueden ser "mejorados", pero si planea conectarse a algún equipo "real", use su protocolo, no invente el suyo.