Cuándo se debe cambiar de ASCII a avanzado de protocolos serie?

Question

Todos mis microcontrolador dispositivos que se comunican con el PC a través de UART uso de cadenas de caracteres ASCII para enviar comandos y recibir datos (como se implementa en el Arduino). Eso es lo que yo aprendí cuando empecé a escarbar en la electrónica y siempre he encontrado el envío de desnudo cadenas a ser suficiente. Sin embargo, me di cuenta de que la mayoría de los dispositivos me encontré con el uso de sofisticados protocolos binarios que incluyen los códigos de función, direcciones y CRC comprobación de errores.

Cuando se ASCII básico de comunicación aceptables y cuando debo tener en cuenta algo más avanzado, como Modbus? Hacer comerciales de uso de los dispositivos tales ASCII? Industrial?

Answer 1

1. ASCII y el CRC no son mutuamente excluyentes. ASCII es un código, y el CRC es para la comprobación de errores.

2. CUALQUIER cosa puede ser enviado como ASCII. Nos oldsters sin duda recordar UUEncoding, que convierte cualquier cosa en una cadena ASCII.

3. A) Para mí, es generalmente una cuestión de velocidad y eficiencia. El envío de un gran número de 32 bits por ASCII puede tomar un largo tiempo, pero solo ocupa 4 bytes a enviar como binario a través de un protocolo de serie.

   B) el Envío de los NÚMEROS a través de ASCII, significa que usted tiene que convertir el número en ASCII, que es un claro paso extra (esto es parte de lo que "printf").

4. Si de alguna manera pierde su lugar, tornillo, perder el formato, llegue el mal endian, etc., un binario protocolo de comunicación sin duda puede arruinar. Si usted está enviando ASCII, puede ser más fácil recuperarse de screwups por sólo va en y MIRANDO el flujo de datos.

Answer 2

Aquí están algunas ideas al respecto:

• ASCII es bueno porque usted puede utilizar un monitor de puerto serie para tener un manual de mirar en lo que se envíe.
• si su conexión no es confiable,usted debe esperar de transmisión de errores y debe utilizar un CRC para comprobar la integridad de cada mensaje recibido. Esto también puede ser hecho en ASCII mensajes.
• si su conexión es demasiado lenta puede reducir el tamaño de los mensajes por el cambio a un formato binario
• Especializado formato binario puede ser más fácil de decodificar en el lado del receptor de ASCII

Answer 3

En el nivel más simple, se podría decir que un simple protocolo de comunicación tiene tres capas: física, transporte y aplicación. (Hay modelos con más como OSI con 7 o TCP/IP con 4. El número de capas no es muy importante en el contexto de esta pregunta).

La capa de aplicación es la capa que tratar directamente en el código, y el foco de la cuestión. Tan lejos como el de la capa de transporte se refiere, el byte que pasa en send_data es sólo un patrón binario, pero se puede interpretar en el código de la aplicación, como la letra 'A'. El CRC o de la suma de comprobación de cálculo será la misma independientemente de si usted se considera el byte a ser 'A', 0x41, o 0b01000001.

La capa de transporte es el nivel de paquetes, donde usted tiene su encabezados de los mensajes, y la comprobación de errores, ya sea de CRC o básico de una suma de comprobación. En el contexto de firmware, usted puede tener una función como send_data, donde se pasa de un byte a enviar. Dentro de esa función, se pone en un paquete que dice: "Hola, este es un mensaje normal, requiere de un reconocimiento, y la suma de comprobación es 0x47, el tiempo actual es la X." Este paquete se envían a través de la capa física para el nodo receptor.

La capa física es donde la electrónica y la interfaz se definen: los conectores, los niveles de voltaje, el tiempo, etc. Esta capa puede variar desde un par de trazas de ejecución de señales TTL para una UART en un PCB, totalmente aislado par diferencial como en algunos PUEDE implementaciones.

En el nodo receptor, el paquete viene en la capa física, es descomprimido en la capa de transporte, y, a continuación, su patrón binario está disponible para la capa de aplicación. Es hasta el nodo receptor de la capa de aplicación para saber si ese patrón debe ser interpretado como 'A', 0x41, o 0b01000001, y qué hacer con él.

En conclusión, es casi siempre aceptable para enviar caracteres ASCII, si eso es lo que necesita la aplicación. Lo importante es entender su esquema de comunicación, y que incluyen un mecanismo de comprobación de error.

Answer 4

Un punto que aún no se menciona es que si uno está usando ASCII o un protocolo binario, el envío de un rub-out personaje antes de cada paquete se asegura de que incluso si el ruido en la línea o errores de trama aparecen antes de que el inicio de un paquete, todos los caracteres después del rub-out será correctamente enmarcada en la ausencia de ruido. De lo contrario, si uno envía los paquetes de forma continua y no incluye ninguno de los caracteres que están garantizados para conseguir resynchrononization, es posible que una falla puede corromper todo lo que sigue hasta la siguiente pausa en la transmisión. El 0xFF carácter es agradable, ya que garantiza que cualquier receptor será capaz de volver a sincronizar en el siguiente carácter.

(*) 0xFF-llamado rub-porque alguien que escribe un erróneas de carácter, mientras que la escritura de los datos en una cinta de papel que puede empujar el "paso de la cinta hacia atrás" botón y pulse rub-out para reemplazar el erróneamente-un puñetazo personaje con 0xFF, que será ignorado por la mayoría de los receptores).

Answer 5

Una de las ventajas de envío de cadenas de caracteres ASCII es que los códigos de control puede entonces ser utilizado para la señal de inicio / final de mensaje. por ejemplo, STX (char 2) y ETX (char 3) puede ser una señal de inicio de la transmisión y el final de la transmisión. Alternativamente, usted puede agregar una simple línea de alimentación para marcar el final de la transmisión.

Al enviar datos binarios esto se vuelve más complicado ya que no existe ningún patrón de bits que puede ser reservado para un código de control (sin cierta sobrecarga adicional o complejidad) como válido el byte de datos pueden tener el mismo patrón.