¿Por qué molestarse incluso con paridad?

Estoy usando un periférico SPI en mi aplicación. El periférico devuelve paquetes que contienen 15 bits de datos, más un bit de paridad par para la detección de errores.

Por lo tanto, todos los ceros y todos pasan la verificación de paridad.

Esto significa que mi microcontrolador no puede detectar el tipo de error más común: ¡se desconecta el periférico! En este caso, los bits recibidos son todos cero, lo que pasa la verificación de paridad.

Suponiendo que hubiera sido tan fácil para el fabricante del periférico implementar paridad impar, mi pregunta es: ¿por qué habrían optado por usar paridad par en este caso ? ¿Hay alguna otra ventaja de Even Parity en este caso para compensar el hecho de que no puede detectar el tipo de error más común?

Un solo bit de paridad solo puede verificar la presencia de números únicos o impares de bits en los errores, por lo que esperar que detecte cuando un periférico está desconectado probablemente espere demasiado.

Sin embargo, muchos sistemas producirán una serie continua de 1 cuando un periférico no está presente y esto se puede lograr con una simple resistencia pull-up en la línea de datos de retorno. Si un periférico conectado devolviera datos reales de 8 bits, entonces el bit de paridad sería cero para la transmisión decimal 255. Entonces, incluso la paridad puede detectar cuando un periférico está desconectado bajo estas circunstancias.

Si se utilizara una paridad impar, 8 bits altos (255 decimales) darían como resultado un bit de alta paridad, lo que haría inútil la paridad impar como medio para detectar la pérdida de chip periférico.

Caballos de carreras.

La paridad, o cualquier detección de error de bloque, está destinada a detectar errores dentro de una transmisión de datos. La paridad no está diseñada para detectar si se está produciendo o no la transmisión de datos.

Dada una línea de transmisión, hay varios tipos diferentes de preocupaciones. Los dos que son relevantes aquí son: 1) falla absoluta de la línea misma, y ​​2) errores de datos de bloque dentro de una transmisión particular. Otros menos relevantes son, por ejemplo, voltajes de línea incorrectos, errores de protocolo o errores de seguridad. La paridad ayuda con 2 pero no con 1. Para que un subsistema en cualquier extremo de una línea de transmisión pueda hacer frente a 1 (falla absoluta de una conexión), se requiere otra característica de protocolo.

La tasa de detección de errores de un solo bit de paridad suele ser superior al 50%. Exactamente cuál es esa tasa depende de la heurística del segmento de datos en el protocolo. Digamos que tiene un paquete, (MSB) 1011010111011110, y hay un error de un solo bit en el último bit transmitido, la verificación de paridad fallará y lo rechazará correctamente. Del mismo modo, si tuvo un error de datos en el primer bit (el bit de paridad), el paquete sería rechazado.

Realizar esta verificación en el hardware es extremadamente simple y no requiere un procesamiento complicado. Es útil en aplicaciones con tasas de error de bits relativamente bajas para eliminar cosas como la distorsión del reloj o las señales de reloj generadas por los procesadores que ejecutan pilas de software recolectadas de basura.

SPI es un protocolo de enlace físico diseñado para líneas cortas conectadas eléctricamente donde la tasa de error de un solo bit no depende mucho de la pérdida de la línea. Si está ejecutando algo en una línea con pérdida, necesitará algo mucho más robusto que la paridad. Esto no es realmente lo que hace SPI.

Para verificar si un dispositivo todavía está conectado, intente algo más alto en la pila. En comparación, TCP / IP (IP, específicamente) no especifica bits de paridad, mientras que muchas de las especificaciones 802.x Ethernet sí. IP, por otro lado, tiene un complicado "¿estás ahí?" protocolo. ¿Qué estás ejecutando además de SPI? La respuesta a la gestión del enlace de datos probablemente esté ahí.

No hay beneficio obvio de paridad par sobre impar. En los esquemas de comunicación y almacenamiento, la polaridad de paridad (par o impar) debe seleccionarse para atrapar los modos de falla más probables o más altos.

Como usted dice, un objetivo que no responde o un cable de recepción de datos roto puede resultar en una línea MISO atascada alta o baja.

Cuando se comunican números pares de bits, como bytes a través de SPI, un bit de paridad impar detectaría una falla en los datos de este todo-1 o todo-0, pero la paridad par no lo haría.

Sin embargo, no hay un ganador tan claro al comunicar un número impar de bits, como en su aplicación con 15 bits sobre SPI. Incluso la paridad detectaría una falla en el caso de todo-1, pero se perdería el caso de todo-0. Por el contrario, una paridad impar detectaría una falla en el caso de todos los 0, pero se perdería el caso de todos los 1.

Hay poca diferencia en el beneficio con paridad par o impar. Uno se puede convertir al otro con una sola puerta invertida. El propósito principal del bit de paridad es verificar solo los 15 bits en ese valor. No es su propósito hacer ninguna otra cosa. Que uno u otro pueda detectar un chip faltante, defectuoso o desconectado no es una consideración. Usted menciona que estar desconectado es el tipo de error más común en su caso. No importa. El bit de paridad no está ahí para detectar ese tipo de error.

Tienes razón al cuestionar esto, tengo la misma crítica incluso de paridad. Con un número impar de bits de datos antes de la adición del bit de paridad, como en su ejemplo, y como es común, la paridad uniforme permite que todos los 0 y todos los 1 sean palabras válidas transmitidas, lo que es inútil para detectar un enlace muerto o un chip muerto. La respuesta previa de Tony M es incorrecta a este respecto. Consulte la tabla de ejemplo de datos de 7 bits aquí para ver pruebas: - https://en.wikipedia.org/wiki/Parity_bit

Sin embargo, la paridad impar insertaría un bit de estado opuesto en el caso de todos los 0s o todos los 1s, demostrando así que el enlace y el chip están vivos, y sería una opción mucho mejor en este caso.