C++ - Ayuda Interpretación de las instrucciones de una asignación de programación de verificación de errores CRC

Esto no es convencional, según lo que he visto, pero no puedo comunicarme con los ayudantes de mi profesor para aclarar esta tarea. Espero que esto todavía esté bien para publicar aquí.

Agradecería mucho que me ayudaran a interpretar las instrucciones para una tarea de programación que me dieron, relacionada con los bits de paridad y la verificación de errores de CRC. Me gustaría recibir ayuda con la lógica detrás de las instrucciones y alguna orientación sobre lo que se supone que deben hacer los procesos que se nombran en las instrucciones. Una vez que comprenda la lógica, planeo (al menos espero) poder encargarme de la parte de programación real desde allí.

Siento que las instrucciones no son muy concisas (aunque pueden estar bien para aquellos familiarizados con el material). Las frases por las que estoy especialmente perplejo estarán en negrita+cursiva :

Detección y codificación de errores: paridad, CRC y FEC

Parte 1:

a) Escriba un programa (en cualquier lenguaje, como C, C++, Java, Javascript o Python) que genere un bit de paridad ( par o impar, usted elige ) para cada byte de datos y verifique su correcto funcionamiento.

b) Escriba otro programa para detectar los datos correctos en función de la paridad que haya definido. Luego use el programa para generar un byte de datos junto con el bit de paridad (9 bits en total) y observe qué sucede cuando hay 0, 1, 2 o 3 bits erróneos en un byte determinado. Incluya una captura de pantalla de los resultados (línea de comando u otro) y discuta la probabilidad de que ocurra un error no detectado .

Parte 2:

a) Escriba un programa que genere una suma de verificación CRC de 8 bits para un flujo de datos. A continuación se muestra un ejemplo de este programa, en pseudocódigo. Este mismo programa se puede utilizar para comprobar la correcta recepción del flujo de datos. El flujo de datos más simple para el que se puede usar es de dos bytes; simule al menos 5 flujos de datos diferentes de 2 bytes con y sin errores y registre los resultados. Particularmente interesantes son los flujos de datos de error que difieren en solo 1 bit de los datos correctos.

b) Además, simule al menos un flujo de datos de 32 bytes con al menos un error y registre los resultados. Incluya una captura de pantalla de los resultados y discuta la probabilidad de que ocurra un error no detectado.

Pseudocódigo del programa CRC

Initialize counter and data stream
Loop for each bit in data stream
Define next states for each bit
Next Bit 1 = next bit of Data In
Next Bit 2 = Present Bit 1
Next Bit 3 = Present Bit 2 XOR
present Bit 8
Next Bit 4 = Present Bit 3 XOR
present Bit 8
Next Bit 5 = Present Bit 4 XOR
present Bit 8
Next Bit 6 = Present Bit 5
Next Bit 7 = Present Bit 6
Next Bit 8 = Present Bit 7
Move next states into present states
Present Bit 1 = Next Bit 1
Present Bit 2 = Next Bit 2
Present Bit 3 = Next Bit 3
Present Bit 4 = Next Bit 4
Present Bit 5 = Next Bit 5
Present Bit 6 = Next Bit 6
Present Bit 7 = Next Bit 7
Present Bit 8 = Next Bit 8
Output CRC encoder byte to screen
End loop
Output final CRC checksum byte

Porciones en negrita+cursiva :

1a)

  • Estoy creando una función a través de la cual escribo manualmente un byte para probar mi programa. ¿Correcto?

  • " par o impar: usted elige ": sé que un byte es una cadena de 8 bits, cada uno de los cuales es un 1 o un 0 . Sé que un bit de paridad es un "noveno bit" agregado al final de la secuencia de bits. Creo que "par o impar, tú eliges" significa que debo decidir si un bit de paridad 1 indica que hay un número par de 1 en el byte o que hay un número impar de 1 en el byte. ¿Correcto?

1b)

  • Ahora estoy creando un generador de bytes que , en función de si hay un número par o impar de 1 en el byte generado , agrega un bit de paridad , siendo un 1 o un 0 . (Decidamos ahora que un número par de 1 significa que el bit de paridad será 1 y viceversa) . ¿Es esto correcto?

  • " detectar datos correctos basados ​​en la paridad " - Entonces... ¿Simplemente confirme que tengo el número correcto de 1 en mi byte, basado en el valor del bit de paridad? ¿No es lo mismo que "verificar [ing] su correcto funcionamiento" del paso a) ? ¿Qué bytes estamos usando para hacer este paso? Todavía no hemos creado nuestro generador de bytes. Ya nos pidieron "verificar el funcionamiento correcto [del bit de paridad]" en el paso a) , entonces, ¿este paso es redundante?

  • "¿ Qué sucede cuando hay 0, 1, 2 o 3 bits de error ?" - Espera. Entonces, ¿debo crear intencionalmente un generador de bytes que contenga errores en algunos de los bytes generados? ¿Cómo sabría siquiera que un byte generado tiene un error? No tengo un "caso base" o una "versión correcta del byte" para comparar cada byte. ¿Quién puede decir que hay un error en ello?

  • probabilidad de un error no detectado : estamos tratando con 1 byte u 8 bits. Encontré esta página que indica que la probabilidad de un error no detectado en sistemas de 8 bits es PAG tu mi = 1 ( 1 q ) 8 . ¿Es correcta esta ecuación estándar que se usa? ¿Sería la probabilidad en un sistema de 16 bits simplemente PAG tu mi = 1 ( 1 q ) dieciséis ?

2a)

Suma de verificación CRC de 8 bits : ¿necesito escribir una función que genere una secuencia de puertas XOR en posiciones aleatorias en la secuencia de 8 bits? ¿Basado en la imagen de abajo?:

ingrese la descripción de la imagen aquí

Supongo que no puede haber 0 puertas XOR y no puede haber puertas XOR en los 8 bits. ¿Existen otras limitaciones para generar una suma de verificación CRC? Entonces, si el codificador de 8 bits se viera como arriba, ¿sería la suma de verificación 01110000 ? ¿Qué hago con la suma de comprobación?

Flujos de datos de 2 bytes con y sin errores : 2 bytes son 16 bits. ¿Estamos utilizando el generador de suma de comprobación en este paso? ¿Se supone que debo programar el generador de suma de comprobación para que ocasionalmente cometa errores? En este caso, un "error" sería un byte que pasa por el codificador CRC y termina con un 1 donde debería haber un 0 o viceversa. ¿Correcto? ¿Se supone que debo programarlo para que las puertas XOR/codificador CRC no siempre hagan su trabajo?

Espero que tu maestro también te haga saber que las verificaciones de paridad son una forma horrible y poco profesional de buscar cualquier tipo de error y que nunca debes usar esa basura en aplicaciones del mundo real. Particularmente no como parte de la comunicación UART.

Respuestas (1)

Pasar en orden y no responder específicamente con fines de tarea.

1a No escribiría manualmente un flujo de bytes, pero es fácil escribir un script para generar una buena selección de valores conocidos. Un poco de paridad, sí, tienes razón.

1b Has empezado bien. No es redundante, ya que 1a era escribir un script que generaba un bit de paridad y 1b era escribir un script que verificaba el bit de paridad. Debe crear un flujo de bytes conocido que sea correcto, y luego puede cambiar aleatoriamente algunos bits y ver si el verificador de paridad indica una falla. Obviamente, debe realizar un seguimiento si volteó un poco. Puedes hacer las partes de la pregunta.

2 Necesitas leer un poco más sobre las sumas de verificación, pero nuevamente estás en las líneas correctas. Los errores en el flujo de bytes se refieren a transferencias dañadas, no a errores en el sistema CRC.