¿Qué tan seguro es \ n \ r como bytes de parada?

Question

En mi UART comunicación necesito saber el byte de inicio y la parada de bytes del mensaje enviado. El inicio de bytes es fácil, pero la parada de bytes, no tanto. He implementado parada de dos bytes al final de mi mensaje, que es \n y \r (10 y 13 decimal). UART sólo funciona en bytes de 0 a 255 valores entonces, ¿cómo fail-safe es esto? Me imagino, aunque la probabilidad es baja, que mi mensaje puede contener los valores "10 y 13" después de cada uno de los otros cuando no están a la parada de bytes.

Existe una mejor forma de implementar esto?

Answer 1

Hay diferentes maneras de evitar que esto:

• Asegúrese de no enviar nunca una 10/13 combinación con el resto de mensajes (tan sólo como dejar de bytes). E. g. para enviar 20 21 22 23 24 25:

20 21 22 23 24 25 10 13

• Escapar de 10 y 13 (o todos los que no son caracteres ASCII con un carácter de escape por ejemplo . Para enviar 20 21 10 13 25 26 enviar: (véase el comentario de/créditos: DanW)

20 21 1b 10 1b 13 25 26

• Definir un paquete cuando el envío de mensajes. E. g. si desea enviar mensaje 20 21 22 23 24 25 que en lugar de agregar el número de bytes enviados, por lo que el paquete es:

< nr_of_data_bytes > < datos >

Si sus mensajes son max 256 bytes a enviar:

06 20 21 22 23 24 25

Así que usted sabe que después de recibir 6 bytes de datos que es el final; usted no tiene que enviar un 10 13 después. Y usted puede enviar 10 13 dentro de un mensaje. Si los mensajes puede ser más largo, se puede utilizar de 2 bytes para el tamaño de los datos.

Actualización 1: Otra forma de definir los paquetes

Otra alternativa es enviar comandos a los que tienen una longitud específica y puede tener muchas variaciones, por ejemplo,

10 20 30 (Comando de 10, que siempre tiene 2 bytes de datos)

11 30 40 50 (Comando 11, que siempre tiene 3 bytes de datos)

12 06 10 11 12 13 14 15 (Comando 12 + 1 byte para el número de bytes de datos que siga)

13 01 02 01 02 03 ... (Comando de 13 + 2 bytes (01 02 para 256 + 2 = 258 bytes de datos que siga)

14 80 90 10 13 (Comando de 14 que es seguido por una cadena ASCII terminando con 10 de 13)

Actualización 2: conexión Mala/byte pérdidas

Todo lo anterior sólo funciona cuando la UART línea es el envío de bytes correctamente. Si desea utilizar más fiable formas de envío, también hay muchas posibilidades. A continuación se presentan algunas:

1. El envío de una suma de comprobación dentro del paquete (cheque de google para CRC: Comprobación de Redundancia Cíclica). Si el CRC es correcto, el receptor sabe que el mensaje ha sido enviado ok (con alta probabilidad).
2. Si usted necesita un mensaje para ser reenviados, de un acuse de recibo (ACK/respuesta) mecanismo debe ser utilizado (por ejemplo, el remitente envía algo, el receptor recibe los datos corruptos, envía un NACK (no reconocido), el remitente puede enviar de nuevo.
3. Tiempo de espera: En caso de que el receptor no recibe un ACK o NACK en el tiempo, un mensaje debe volver a enviar.

Tenga en cuenta que por encima de todo mecanismo puede ser simple o tan complicado como usted quiere (o necesita). En caso de volver a enviar el mensaje, también un mecanismo para la identificación de los mensajes es necesario (por ejemplo, la adición de un número de secuencia en el paquete).

Answer 2

Cómo fail-safe es \n\r como dejar de bytes?

Si usted enviar datos arbitrarios -> probablemente no a prueba de fallos suficiente.

Una solución común es el uso de escapar:

Vamos a definir que los personajes 0x02 (STX - frame de inicio) y 0 x 03 (ETX - cuadro final) deben ser únicos dentro del flujo de datos transmitido. De esta manera el inicio y el final de un mensaje puede ser detectado de forma segura.

Si uno de estos personajes se debe enviar dentro del marco de mensaje, es reemplazado por el prefijo de un carácter de escape (ESC = 0x1b) y la adición de 0x20 a su carácter original.

Carácter Original reemplazado por

0x02 -> 0x1b 0x22  
0x03 -> 0x1b 0x23  
0x1b -> 0x1b 0x3b  

El receptor se invierte este proceso: en cualquier Momento se recibe un carácter de escape, este personaje se cae y el siguiente carácter se resta por 0x20.

Esto sólo añade una sobrecarga de procesamiento, pero es 100% fiable (suponiendo que no hay errores de transmisión se producen, lo que se puede/debe verificar además la implementación de un mecanismo de suma de comprobación).

Answer 3

Usted sabe, ASCII ya ha bytes para estas funciones.

• 0x01 : inicio de la partida -- start byte
• 0x02 : el inicio del texto -- fin de encabezados, de comenzar de carga
• 0x03 : final del texto -- fin de la carga
• 0x04 : fin de la transmisión -- deje de byte
• 0x17 : fin del bloque de transmisión-mensaje continúa en el siguiente bloque

También tiene códigos para diversos usos dentro de la carga útil.

• 0x1b : escapar (escapar de la siguiente carácter -- uso en carga para indicar que el siguiente carácter no es el de la estructura que describe los códigos utilizados en el protocolo)
• 0x1c, 0x1d, 0x1e, 0x1f : archivo, grupo, grabar, y la unidad de separador, respectivamente -- utiliza como simultánea stop y start byte para piezas de datos jerárquicos

Su protocolo debe especificar los mejores granularidad de ACK (0x06) y NAK (0x15), por lo que la negativa reconoció que los datos pueden ser retransmitidos. A este mejor granularidad, es recomendable disponer de un campo de longitud inmediatamente después de cualquier (sin escape) indicador de inicio y (como se explicó en otra respuesta(s)) es sabio seguir cualquiera (sin escape) indicador de detención con un CRC.

Answer 4

UART no es infalible, por su propia naturaleza - estamos hablando de 1960, la tecnología aquí.

La raíz del problema es que UART solo sincroniza una vez por 10 bits, lo que permite un montón de tonterías para pasar entre los períodos de sincronización. A diferencia de, por ejemplo, PUEDE que las muestras de cada bit individual en múltiples ocasiones.

Cualquier doble de bits de error que se producen en el interior de los datos se corrompen una UART marco y pasar desapercibido. Errores de Bit de start/stop bits puede o no puede ser detectado en forma de errores de saturación.

Por lo tanto, no importa si usted utiliza los datos brutos o paquetes, siempre hay una probabilidad de que el bit voltea causada por EMI resultado inesperado de datos.

Existen numerosas formas de "tradicional UART charlatanería" para mejorar la situación sea muy ligeramente. Usted puede agregar bytes de sincronización, sincronización de bits, paridad, el doble de bits de parada. Usted puede agregar las sumas de comprobación de que el recuento de la suma de todos los bytes (y luego invertir - porque, por qué no) o usted puede contar el número de binario como una suma de comprobación. Todo esto es ampliamente utilizado, salvajemente científico y con una alta probabilidad de errores de falta. Pero esto era lo que la gente hizo de la década de 1960 hasta la década de 1990 y un montón de cosas extrañas como estas vidas en el día de hoy.

La manera más profesional a la seguridad de la transmisión a través de la UART es tener una suma de comprobación CRC de 16 bits en el final del paquete. Todo lo demás no es muy segura y tiene una alta probabilidad de errores de falta.

A continuación, en el nivel de hardware puede utilizar diferencial RS-422/RS-485 para mejorar drásticamente la robustez de la transmisión. Esta es una necesidad para la seguridad de la transmisión en largas distancias. Nivel TTL UART sólo deben ser utilizados para las comunicaciones a bordo. RS-232 no debe ser utilizado para ningún otro propósito, pero la compatibilidad hacia atrás con cosas viejas.

En general, el más cercano al hardware de su mecanismo de detección de errores, más eficaz es. En términos de eficacia, señales diferenciales agregar la mayoría, seguido por la comprobación de encuadre/saturación, etc errores. CRC16 añade algunos, y luego "tradicional UART charlatanería", añade un poco.

Answer 5

... Puedo imaginar, aunque la probabilidad es baja, que mi mensaje puede contener los valores "10 y 13" después de cada uno de los otros cuando no están a la parada de bytes.

Una situación en la que una porción de los datos es igual a la terminación de la secuencia debe ser considerado a la hora de diseñar el formato de una serie de paquetes de datos. Otra cosa a considerar es que cualquier personaje puede quedar dañado o perdido durante la transmisión. Un carácter de inicio, un carácter de parada, una carga útil de datos byte, una suma de comprobación CRC byte, una corrección de errores hacia adelante byte no es inmune a la corrupción. El mecanismo de encuadre tiene que ser capaz de detectar cuando un paquete de datos corruptos.

Hay varias maneras de acercarse a todo esto.

Yo estoy haciendo la hipótesis de trabajo de que los paquetes están enmarcadas sólo con la serie de bytes. Apretón de manos de líneas no se utilizan para enmarcar. Los retrasos de tiempo no se utilizan para enmarcar.

Enviar paquetes de longitud

Enviar la longitud del paquete en el principio, en lugar de (o además] el carácter de terminación al final.

pros: la Carga útil es enviado en una eficiente en formato binario.

contras: Necesita conocer la longitud del paquete en el inicio de la transmisión.

Escapar los caracteres especiales

Escapar los caracteres especiales cuando el envío de los datos de la carga. Esto ya está explicado en una anterior respuesta.

pros: Remitente no necesita conocer la longitud de los paquetes en el comienzo de la transmisión.

contras: un poco menos eficiente, dependiendo de cuántos bytes de carga útil deben ser escapado.

Carga de datos codificados de tal manera que puede no contener iniciar y detener los personajes

La carga útil del paquete está codificado de tal manera que puede no contener el inicio o parada de los personajes. Generalmente, esto se hace mediante el envío de números como sus ASCII o Hex-ASCII representación.

pros: legible por Humanos con el terminal común de los programas. Sin necesidad de código para controlar el escape. No hay necesidad de conocer la longitud de los paquetes en el inicio de la transmisión

contras: Menor eficiencia. Por un byte de datos de la carga, de varios bytes que se envían.