Para UART, ¿debo usar la paridad en un nivel de tablero?

Paridad impar vs pareada

Esto dependerá ligeramente de la comunicación que esté utilizando. Sé que dijiste que estás usando UART, pero voy a responder un poco más. Si decide ir con paridad, seleccione la opción que hará que su estado "inactivo" requiera que el bit de paridad cambie.

Si tiene un sistema alto activo, entonces todos los 0 están inactivos. Así que haz que paridad impar para que el bit de paridad tenga que cambiar el estado de inactivo.

En un sistema bajo activo, deberías mirar en cuántos bits se superará la paridad. Si es de 8 bits, entonces la paridad par dará como resultado un bit de paridad de 0, que sigue la idea de forzar un cambio en el estado para la paridad.

¿Deberías usar la paridad?

Bueno, esta es una pregunta un poco difícil. En general, nos gusta modelar el ruido como ruido gaussiano, lo que significa que los errores de bit serán completamente aleatorios. En la actualidad, el ruido que tiene un efecto en nuestro sistema no siempre es aleatorio. La razón de esto es que las cosas que pueden causar errores en una PCB son radiadores de otra cosa. Si lo piensas bien, para que un rastro tan corto tenga suficiente ruido como para causar un error de bit, entonces tenía que ser algo bastante extremo. Cuando tienes una fuente de ruido como esta, hay una buena posibilidad de que cambies más de un bit. La paridad es inútil contra un número par de errores de bit. Sin el buceo en las matemáticas, la paridad ayudará, pero no ayuda a las toneladas. Si no puedes permitirte hacer mucho procesamiento, entonces la paridad puede ser lo mejor que puedes hacer ...

¿Por qué usar un CRC?

En primer lugar, usted dice que tiene un generador de CRC incorporado, esto significa que debería ser muy fácil de calcular. Los CRC son mucho mejores para capturar múltiples errores de bit. En un entorno en el que desea una muy baja posibilidad de obtener algún error, realmente desea utilizar un CRC. De hecho, elija el CRC más grande que pueda pagar en su sistema. Un pequeño truco que sé que funciona para al menos el crc16, si no otros, es que si CRC el mensaje que recibió con el CRC debería obtener un 0 como respuesta. Si tiene hardware para calcular el CRC, entonces esta es una manera muy eficiente de generar CRC y verificar el CRC.

En mi experiencia, casi todos los equipos y sistemas con los que he trabajado se saltan la paridad y solo usan sumas de comprobación de mensajes o CRC para detectar errores.

Si tiene la capacidad de interrumpir un mensaje, se puede usar un error de paridad para detener una transmisión incorrecta más rápido que una verificación CRC, especialmente para paquetes de gran tamaño. De lo contrario, un cheque CRC detectará cualquier cosa que un cheque de paridad, y más. Si está realmente preocupado, puede utilizar métodos de detección de software adicionales, como la verificación de contexto y la duplicación de mensajes. Los tiempos de espera pueden usarse para evitar que la OSD caiga en un estado incorrecto de forma permanente.

En primer lugar, trabajaría en proteger este cable.

Coloque los planos de tierra a su alrededor (y / o) burry en capas internas entre los planos de tierra. Entonces confíe en CRC. Usa la paridad si es gratis.

Si usa paridad, piense en cómo manejará el error en su código. Si no tiene una forma elegante de administrar el error, la detección no ayudará mucho.

La paridad es inútil, en mi opinión.

Con conexiones cortas de chip a chip en una sola placa como esta, siempre que conduzca correctamente las líneas, debería estar prácticamente libre de ruidos, al menos en comparación con, digamos, su DRAM. Algunas personas esperan un error de bit suave, por día, por gigabyte de DRAM. ¿Cómo sabe que el error que vio no fue causado por un error tan suave en lugar de ruido en los cables de comunicación? Si ha inducido un ruido lo suficientemente grande como para voltear un poco en una traza de PCB correctamente controlada, es probable que tenga otros problemas mayores de los que preocuparse. (Por "correctamente manejado", me refiero a conducir activamente cada línea todo el tiempo, o usar una resistencia desplegable o una resistencia desplegable para establecer el estado entre los mensajes).

Con conexiones externas de mayor alcance, a menudo es inevitable tener cables flotantes que presenten un pin de entrada con más o menos ruido aleatorio continuo, e incluso cuando está transmitiendo un mensaje, a menudo recibe errores de bits. En este caso, la paridad es mejor que nada. Como se mencionó en bt2, querrá usar CRC para poder detectar muchos errores que la paridad pierde por completo, y una vez que tiene CRC, agregar paridad no ayuda significativamente.

Si es posible poner su sistema en un "mal estado", intente diseñar cosas que devuelvan a un buen estado en un tiempo razonable. Utilice los tiempos de espera de comunicación y los temporizadores de vigilancia como márgenes de marca y bt2 mencionados. Vuelva a transmitir periódicamente los comandos de inicialización para que, independientemente del estado extraño en que se encuentre el receptor, se restablezca al estado correcto.

"La estática en el satélite afectó a su computadora, que leyó el ruido como un comando para apagarse. Para superar el problema, los controladores enviaron un flujo continuo de comandos de ENCENDIDO al satélite para mantenerlo encendido". - Satélites de radio aficionados: OSCAR-6

No quieres la paridad. Quieres una comunicación más confiable.

La razón por la cual la paridad se usa poco es que es costosa en términos de rendimiento de datos. Comienza haciendo una trama casi un 10% más larga: bit de inicio + 8 bits de datos + paridad + bit de parada = 11 bits en lugar de 10. Pero es mucho peor que eso. Si tiene una manera de saber si recibió los datos correctamente, tiene el deber de hacer algo con eso. Simplemente ignorar la comunicación errónea no es suficiente; El transmisor tiene que enviarlo de nuevo. Por eso hay que saber si se recibió bien. Tendrá que enviar un acuse de recibo ( ACK / NAK ) después de cada byte, y el transmisor no podrá enviar el siguiente byte antes de que haya recibido el ACK . Si usas códigos ASCII eso es 11 bits de retorno. Así que reduce a la mitad el rendimiento, y ya perdimos el 10%, por lo que ahora estamos en un 36% de eficiencia de carga útil , desde el 80%. Y esa es la razón por la que a nadie le gusta la paridad.

  

Notas:
  1. No necesita acusar recibo de un acuse de recibo; la distancia de Hamming entre los códigos ASCII para ACK y NAK es 3 (con paridad incluso 4), por lo que no solo se puede detectar un error en la recepción de ACK/NAK , sino también < fuerte> corregido .
  2. Muchos UART pueden trabajar con longitudes de datos de hasta 5 bits, y es posible cambiar a 5 bits para enviar el ACK , pero esto no es más que una apariencia de ventana y solo complica la comunicación.

Una mejor solución puede ser utilizar un CRC al final de cada bloque. Los CRC son mejores que los bits de paridad al capturar múltiples errores (sin embargo, aún no pueden corregirlos). La eficiencia mejorada solo se puede obtener para bloques largos; si un bloque consta de solo 2 bytes, no sirve de nada agregar un CRC de 8 bits.
Otra desventaja sería que todavía tiene que reconocer la recepción correcta. Así que probablemente tampoco sea eso.

¿Qué hay de los códigos de autocorrección ? Los códigos de Hamming agregan poca sobrecarga y te permiten corregir 1 bit erróneo; Ya no hace falta reconocerlo. Al igual que los CRC, los códigos de Hamming son más eficientes en bloques más largos; el número de bits adicionales se define como

  

\ $ N + H < 2 ^ H \ $

donde N = número de bits de datos, y H = número de bits de Hamming. Por lo tanto, para corregir 1 bit en una comunicación de 8 bits debe agregar 4 bits de Hamming; solo se requiere un quinto bit de Hamming a partir de 12 bits de datos. Esta es la forma más eficiente de detección / corrección de errores en mensajes cortos (unos pocos bytes), aunque requiere un cierto malabarismo con sus datos: los bits de Hamming deben insertarse en posiciones específicas entre los bits de datos.

Ahora, antes de agregar los códigos de corrección de errores de Hamming, vale la pena analizar su configuración. Puede esperar errores en una línea de 100 m entre maquinaria pesada, pero no debe tener errores en una línea de 2 cm. Si capta ruido puede ser una impedancia demasiado alta. ¿Los conductores empujan / tiran? Si es así, deberían poder darle bordes rápidos, excepto si el "cable" es capacitivo, que no estará en esta corta distancia. ¿Hay trazas de alta corriente que se ejecutan paralelas a las líneas de datos? Podrían inducir ruido. ¿Realmente necesita esta alta velocidad y los relojes de ambos lados coinciden lo suficiente? Disminuir la velocidad a 57600 bits por segundo puede resolver el problema.

A pesar de la gran cantidad de respuestas, agregaré mi pieza. La paridad funcionará en un nivel de byte, y un CRC funciona (generalmente) en un nivel de paquete. Los esquemas de paquetes son, en mi opinión, superiores a las comunicaciones de tipo byte en bruto. Si su hardware rechaza un solo byte basado en la paridad, eso es ideal para una secuencia de bytes sin procesar, pero no tan bueno para un paquete. De repente, boom, te has perdido un byte en el medio de un paquete, que arruina tu análisis. En el mejor de los casos, todo su paquete se ha ido, pero si su algoritmo de búsqueda de paquetes no es bueno, podría perder más (y he visto algunos algoritmos de detección de paquetes de muerte cerebral utilizados en productos reales). Usar paquetes y CRC como se sugirió.

La paridad generalmente es inútil con la comunicación asíncrona "normal", pero puede ser útil en otros contextos. Por ejemplo, algunos esquemas de codificación diferencial requieren que cada carácter tenga un número par de transiciones de línea para que el estado final de la línea coincida con el estado inicial. Los códigos de barras del código 39 usan paridad, una especie de (*), para validar caracteres individuales y, en general, eliminan la necesidad de un carácter de suma de comprobación.

Si los errores de un solo bit fueran mucho más comunes y los errores de múltiples bits o los errores de trama, la comprobación de paridad por byte podría ser un complemento útil a una suma de comprobación o CRC, ya que la ubicación de un byte con un error permitiría que el error sea corregido Sin embargo, en la mayoría de las situaciones prácticas que involucran UART, muchas fallas en las líneas causan errores de trama, lo que hace que la recuperación de datos sea imposible en muchos casos con o sin paridad de bytes.

(*) Un carácter válido del Código 39 debe tener un número impar de espacios anchos (1 o 3) y un número par de barras anchas (0 o 2).