¿Por qué las comunicaciones a bordo como I2C, SPI, etc. no tienen comprobación de errores en general?

Question

Algunos métodos de comprobación de errores como la comprobación de paridad, la suma de comprobación, CRC, etc. se utilizan para las comunicaciones por cable/inalámbricas. Sin embargo, la mayoría de los circuitos integrados con interfaces como I2C, SPI, etc. no utilizan ningún método de comprobación de errores.

Busquemos "i2c i/o expander" y abramos una hoja de datos al azar. Por ejemplo, consideremos PCF8574 de TI que es un expansor de E/S de 8 bits. Si un bit correspondiente al registro de salida es volteado durante la transmisión I2C, el IC conducirá el pin correspondiente a un nivel no deseado. Por qué más de este tipo de circuitos integrados no tienen ningún mecanismo de comprobación de errores? Supongo que aunque la comunicación sea entre circuitos integrados, todas las señales tienen ruido. Aunque la probabilidad será bastante baja, el ruido puede causar un bit flip.

¿Puede ser esta la razón? Ninguno de los mecanismos de comprobación de errores garantiza una comunicación completamente libre de errores. Sólo pueden ayudarnos a reducir la probabilidad de error. Es obvio que la probabilidad de error en la comunicación a larga distancia es mayor que en la comunicación a bordo. Tal vez la probabilidad de error de bit para la comunicación a bordo está en un rango aceptable incluso sin ningún mecanismo de comprobación de errores.

¿Qué te parece?

Answer 1

Encontrar una solución específica para un problema específico.

Si tiene 3 relés que requieren fiabilidad absoluta: Entonces mida la salida de los mismos con 3 entradas digitales, un sistema de confirmación redundante, a la medida de su aplicación.

Si te pusieras a diseñar un protocolo de comunicación personalizado, para resolver todos los problemas de fiabilidad de una vez por todas, estarías cometiendo un error de diseño común; Desviarse de los requisitos específicos para caer en generalidades.

Answer 2

En primer lugar, es importante recordar que I2C son las siglas de Integrated Circuit to Integrated Circuit communications. Fue diseñado para funcionar de chip a chip en una placa de PC. Sin embargo, con sistemas como la Raspberry Pi, la conexión I2C se realiza a través de cables, el estándar no se está utilizando para lo que estaba destinado, y la degradación de la señal resultante significa que la transmisión va a ser mucho más propensa a errores. Estoy leyendo este hilo porque estoy buscando pistas sobre cómo reducir los errores de I2C en mi configuración Raspberry Pi.

Dicho esto, cada dispositivo compatible con I2C en mi bus valida y genera CRCs para comprobar si hay errores en el bus. Lo que no comprueba los errores es el controlador del dispositivo I2C entrante en Linux, pero puedes encontrar fácilmente librerías online para C o Python para comprobar los CRCs que vuelven. Lo que puedo decirte es que comprobarlos me abrió los ojos porque una fracción alarmante de los datos que volvían eran malos. Ahora, simplemente lo descarto y trato de leer los datos de nuevo, pero la solución a largo plazo es rediseñar mi sistema I2C para tener menos distancia/capacitancia en él. Estoy considerando un conmutador I2C para aislar los dispositivos en sus propios recorridos de señal. O cambiar a Modebus o CANbus que son más robustos eléctricamente (y un poco más caros de usar porque los dispositivos son más caros.)

Debido a debilidades en el estándar estimuladas por largos recorridos de la señal, hay algunos errores como SDA siendo retenido por un dispositivo esclavo que son irrecuperables usando controladores linux I2C típicos y pueden requerir un ciclo de alimentación. Para corregir los bloqueos de bus en tu Pi, podrías cambiar los pines I2C a pines generales de E/S y luego resetear el bus en software con los 9 relojes requeridos a 400 KHz antes de cambiarlos de nuevo a la función I2C, pero hay un montón de trucos para esto, incluyendo la necesidad de código C para alternar el pin CLK lo suficientemente rápido para un reset. Aunque he visto esto discutido en línea, todavía no he encontrado ningún código para ello, y estoy considerando sólo escribirlo yo mismo. O abandonar el I2C.

Por cierto, creo que el uso de I2C cerca de lo que estaba destinado, como la conexión de tarjetas hijas en un Pi, es bastante seguro. No he tenido ningún problema con este tipo de diseños.