¿Por qué molestarse incluso con paridad?

12

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.

Paridad en un periférico SPI

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?

Rocketmagnet
fuente
66
Tenga en cuenta que la "paridad", par o impar, es la tecnología de los dinosaurios, no debe usarse en sistemas modernos y profesionales. Tiene una probabilidad menor al 50% de capturar errores de un solo bit, y peor aún para errores de múltiples bits. Solo olvídate de usar la paridad, usarlo fue una idea tonta incluso en la década de 1960. Si necesita validar una línea de datos SPI, debe supervisar los datos en una capa inferior, utilizando un temporizador de captura de entrada o similar. Verifique también los indicadores SPI para detectar desbordamientos del búfer, etc.
Lundin
39
@Lundin "Tiene una probabilidad inferior al 50% de capturar errores de un solo bit, y peor aún para errores de varios bits". - Si un solo bit está mal, la paridad estará mal. La paridad simple tiene un 100% de posibilidades de detectar errores de un solo bit, no "menos del 50%". (de manera similar, tiene un 0% de posibilidades de detectar errores de 2 bits y un 100% nuevamente al detectar errores de 3 bits).
marcelm
77
@Lundin - Dirija sus comentarios a los creadores de AMS, que hacen estos chips.
Rocketmagnet
26
@Lundin Si el bit de paridad cambia, la verificación de paridad aún falla.
Adam Haun
44
Esto sigue siendo mayormente inútil en la mayoría de las situaciones. ⁽ᶜᶦᵗᵃᵗᶦᵒᶰ ᶰᵉᵉᵈᵉᵈ⁾
dasdingonesen

Respuestas:

14

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.

Andy alias
fuente
2
Tonto, debería haber mencionado que esta aplicación en particular tiene 15 bits de datos y un bit de paridad. Corregido ahora. Pero sigo pensando que es razonable esperar una verificación de paridad para detectar un periférico completamente desconectado. Está bastante dentro de su capacidad, y en realidad es el control más útil que puede hacer.
Rocketmagnet
1
@Rocketmagnet también, la tabla que ha agregado a su pregunta parece ser para el formato de datos que se envía al periférico - tenga en cuenta el término "Tiene que ser 0" para el 14to bit - tal vez debería vincular a la hoja de datos del dispositivo ?
Andy, también conocido como
3
La tabla modificada muestra el bit 14 como el indicador de error y mi consejo es utilizar un pull-up en los datos de retorno en serie para hacer que los datos sean todos 1 cuando el dispositivo se desconecta porque el bit 14 decodificado indicará un problema.
Andy también conocido como
1
@Trevor_G oops sí. Enmiendas en progreso.
Andy, también conocido como
1
La expectativa adecuada es que el software que utiliza el controlador spi debe validar los datos que regresan, si existe un riesgo. Si no tiene control sobre uno u otro lado, definitivamente debe hacerlo en el software de nivel superior. El único momento en que puede dejarlo pasar es si controla ambos lados del diseño spi y hace que cumpla con sus requisitos de error de bit, lo que parece que en este caso no puede. Por lo tanto, su software debe verificar todos los ceros y todos, no el trabajo del controlador spi, ni la paridad que tiene una utilidad limitada ...
old_timer
5

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í.

Stephan Samuel
fuente
1
802.3 y .11 usan CRC32; IP y TCP y (opcionalmente) UDP usan una suma de complemento de uno de 16 bits, que debido al hecho de que muy pocas máquinas o incluso ALU hoy en día son 1sC se implementa principalmente por adición sin firmar más transferencia.
dave_thompson_085
El punto es que la paridad podría detectar fácilmente una falla absoluta de la línea misma. Si recupero todos los 1s o todos los 0s, eso debería ser un fracaso.
Rocketmagnet
4

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.

TonyM
fuente
En realidad, sí, claramente hay en este caso . Como expliqué en la pregunta, Odd parity podría detectar: ​​faltan chips desconectados, defectuosos y fallas de cables, mientras que Even parity no puede.
Rocketmagnet
0

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.

atrapasueños
fuente
0

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.

Don Gato
fuente