protocolo de comunicación uart

Estoy trabajando en un proyecto en el que tengo que comunicar comandos de diferentes longitudes desde mi PC a un microcontrolador. (Usando el puente usb a uart) Ya hice un pequeño protocolo (byte de inicio, algunos datos, suma de verificación ...) pero necesito adaptarlo para mi nueva necesidad.

Me pregunto si ya existe un estándar o una forma común de hacerlo.

Respuestas (4)

comandos de longitud variable

Mucha gente prefiere mucho 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 desborde mi búfer de recepción?
  • Si un poco de ruido voltea el bit alto del campo "longitud" de un paquete corto (haciendo que parezca un paquete largo), ¿mi sistema se recupera correctamente?
    • malo: el microcontrolador 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 enviarle mensajes que decían "desplegar las bolsas de aire", "bajar las barras de control", "abrir las puertas de la bahía de cápsulas, HAL", etc., finalmente obtiene todos los bytes que esperaba, ve que la suma de comprobación falla, desecha este "paquete largo" y vuelve a funcionar con normalidad.
    • bueno: después de un minuto o algún otro tiempo razonable, el microcontrolador se agota, borra todo en el búfer de comando (posiblemente descartando algunos mensajes de "desplegar las bolsas de aire" después del mensaje dañado por la longitud) y comienza a funcionar normalmente nuevamente.
    • bueno: el microcontrolador reconoce inmediatamente que hay algún error en el encabezado (que incluye el byte de inicio, el campo de longitud y la suma de verificación del encabezado), e inmediatamente descarta ese encabezado y comienza a buscar el byte de inicio nuevamente. El microcontrolador inmediatamente comienza a funcionar normalmente de nuevo, reconociendo el primer comando válido (la suma de verificación del encabezado es buena y también la suma de verificación de los datos) después del comando corrupto.
  • ¿El microcontrolador envía inmediatamente un ACK después de ver que la suma de verificación (final) del paquete es buena, 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 hace que sea más fácil de depurar?

consejos generales de diseño de protocolos

Hay muchos protocolos más o menos simples enumerados en el Wikibook "Programación en serie" .

Si tiene suerte, quizás uno de ellos ya sea perfecto para su aplicación. O al menos lo suficientemente cerca como para que solo requiera un pequeño ajuste para que encaje.

Prácticamente 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 da dolor de cabeza. Parece un montón de complejidad innecesaria. Descartemos todas esas cosas y construyamos un protocolo agradable y simple.
  • 2 No funciona. Tal vez si agrego [característica 1] entonces funcionará.
  • 3 Mejor, pero todavía no funciona muy bien. ¿Quizás agregar [característica 2]? ...
  • 98 Finalmente está funcionando. Mejor escribo quién hace qué en mi protocolo simple para que si necesito cambiar a un microcontrolador diferente o quiero escribir un mejor programa en la PC, recordaré cómo funciona.
  • 99 Es curioso cómo mi protocolo simple toma tantas páginas para describir.
No estoy de acuerdo con el último párrafo. La mayoría de los protocolos seriales simples son, de hecho, simples y puede recorrer un largo camino con solo algunos requisitos de sincronización de paquetes y CRC. Los protocolos seriales basados ​​en texto sin CRC son un asunto completamente diferente.
El libro afirma que no es posible que un protocolo sea limpio de 8 bits mientras ofrece una 'copia simple' y un 'inicio inequívoco'. Esas afirmaciones solo son ciertas si uno se limita a la transmisión de datos de 8 bits. Si uno usa transmisión de datos de 9 bits o usa caracteres BREAK para indicar el comienzo del paquete, puede tener las otras ventajas buscadas.
@supercat -- Ah, transmisión de 9 bits. Tienes razón: es una omisión flagrante. Espera mientras lo arreglo... listo. :-). Gracias.
@davidcary: Un placer. Puede valer la pena mencionar los caracteres de interrupción larga como un caso especial, ya que incluso los UART que se limitan a manejar datos de 8 bits con frecuencia tienen alguna disposición para los caracteres de interrupción. Si bien lleva más tiempo enviar una pausa que un carácter normal, el uso de pausas para la señalización no requiere ninguna sobrecarga adicional para los datos de 8 bits.
@supercat -- Sí. Agregué una breve mención del "descanso largo" a esa página. Gracias de nuevo.
@davidcary: Buena observación de que la "pausa larga" para la secuencia de escape de Hayes es efectivamente otro tipo de símbolo.

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

Este es realmente agradable y simple. Simplemente adhiérase a Modbus RTU y no se preocupe por los "códigos de función" estándar.

Si solo hay una conexión maestro-esclavo, parece que ha hecho todo lo que necesita hacer. Utilice un algoritmo de suma de comprobación CRC estándar, pero eso es todo lo que hay que estandarizar significativamente. No se preocupe por tener un protocolo oficial ISO/IEEE.

No sé para qué es 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 en 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 lo que quieres hacer. Todos los protocolos que pueda encontrar pueden ser "mejorados", pero si planea conectarse a algún equipo "real", use su protocolo, no invente el suyo propio.

protocolo de comunicación uart
RespuestasAquíPolítica de privacidad1y, 0v