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

6

Algunos métodos de comprobación de errores, como la comprobación de paridad, 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 un método de comprobación de errores.

Vamos a buscar "i2c i / o expander" y abrimos una hoja de datos aleatoria. Por ejemplo, consideremos PCF8574 de TI, que es un expansor de E / S de 8 bits. Si un bit correspondiente al registro de salida se invierte durante la transmisión I2C, el IC dirigirá el pin correspondiente a un nivel no deseado. ¿Por qué la mayoría de este tipo de circuitos integrados no tiene ningún mecanismo de comprobación de errores? Supongo que incluso si la comunicación es entre circuitos integrados, todas las señales son ruidosas. Aunque la probabilidad será bastante baja, el ruido puede causar un poco de cambio.

¿Puede ser esta la razón ?: Ninguno de los mecanismos de verificación de errores garantiza una comunicación completamente libre de errores. Solo pueden ayudarnos a reducir la probabilidad de error. Es obvio que la probabilidad de error de bit para la comunicación de largo alcance es mayor que 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 verificación de errores.

¿Qué piensas?

    
pregunta Alper

6 respuestas

9

Tienes que asumir que ciertas cosas simplemente funcionan, incluso en un mundo con comprobación de errores. ¿Por qué elegir IIC o SPI cuando normalmente hay muchas más señales digitales en una placa? Parece que está bien si asume que todos se interpretarán de la forma prevista.

Un circuito adecuadamente diseñado en una placa adecuadamente diseñada debería ser confiable. Piense en una salida CMOS que conduce una entrada CMOS a través de una placa. Aparte de la falla total de los componentes (que es un problema completamente diferente de la corrupción ocasional de datos), piense en lo que realmente puede salir mal. En el extremo de conducción, tiene un FET con un máximo garantizado en la resistencia que conecta una línea a Vdd o tierra. ¿Qué es exactamente lo que imaginas puede hacer que no tenga el nivel correcto en el extremo receptor?

Inicialmente, el estado puede ser indeterminado ya que cualquier capacitancia en la línea está cargada o descargada. Entonces puede haber un timbre en el trazo corto. Sin embargo, podemos calcular los tiempos máximos de peor caso para que todo esto se resuelva y la línea sea confiable a través de algún umbral en el otro extremo.

Una vez que se ha alcanzado este tiempo y hemos esperado lo que sea el retraso de propagación de la lógica en el peor de los casos, hay poco para cambiar la señal. Puede estar pensando que el ruido de otras partes del tablero puede acoplarse a la señal. Sí, eso puede suceder, pero también podemos diseñar para eso. La cantidad de ruido en otra parte del tablero es generalmente conocida. Si no, entonces viene de otra parte y, con un diseño adecuado, se limitaría a un máximo de dV / dt y otras características. Todas estas cosas pueden ser diseñadas para.

En teoría, el ruido externo puede alterar las trazas en un tablero, pero la intensidad de campo debería ser demasiado grande para un tablero diseñado adecuadamente. Existen entornos con mucho ruido, pero se limitan a ubicaciones conocidas. Una placa puede no funcionar a 10 metros de un transmisor de 10 kW, pero incluso eso puede diseñarse para.

Entonces, la respuesta es básicamente que las señales digitales en la misma placa, si se diseñan correctamente, pueden considerarse absolutamente confiables para la mayoría de los usos comunes. En casos especiales donde el costo de la falla es muy alto, como el espacio y algunas aplicaciones militares, se utilizan otras estrategias. Estos suelen incluir subsistemas redundantes. Todavía considera confiables las señales individuales en una placa, pero las placas o subsistemas en su conjunto pueden fallar ocasionalmente. Tenga en cuenta también que estos sistemas cuestan mucho más, y tal carga de costos haría que los sistemas más comunes, como las computadoras personales, por ejemplo, sean inútiles por ser demasiado caros.

Dicho todo esto, hay casos en los que incluso en la electrónica de consumo ordinaria se emplean la detección y corrección. Esto generalmente se debe a que el proceso en sí tiene una cierta probabilidad de error y porque se están imponiendo límites. La memoria principal de alta velocidad para computadoras a menudo incluye bits adicionales para la detección y / o corrección de errores. Es más barato obtener el rendimiento y la tasa de error final al aumentar los límites y agregar recursos a la corrección de errores que a ralentizar las cosas y usar más silicio para que todo sea inherentemente más confiable.

    
respondido por el Olin Lathrop
5

Especialmente para los protocolos que no están diseñados para ser usados sobre cables, una tarjeta diseñada adecuadamente no tendrá errores, y una tarjeta mal diseñada no funcionará bien con o sin verificación de errores. Por ejemplo, los fallos en un bus I2C con varios esclavos pueden bloquear permanentemente el bus (*) a menos que el maestro tenga un controlador que pueda sacar el nivel alto de SDA, incluso cuando los esclavos están intentando bajarlo. Protegerse contra eso haría que el protocolo fuera más lento, pero si el bus está lo suficientemente libre de fallos técnicos como para que tal comportamiento no se considere un riesgo, no habría mucha necesidad de una lógica de comprobación de errores en general.

(*) Si un esclavo piensa que ve una condición de inicio en medio de un byte de datos que se está leyendo desde otro dispositivo, e interpreta que los datos que se están leyendo inician un comando que debe leer una cadena de ceros, entonces sería posible que cada uno de los dispositivos esclavos reconociera los bytes de datos enviados al otro de tal manera que en cualquier momento dado al menos uno de los esclavos estuviera presionando el bus.

    
respondido por el supercat
2

¿Por qué lo preguntas solo con respecto a la comprobación de errores?

¿Cómo puede estar seguro de que la condición de inicio se interpreta correctamente? En las comunicaciones por cable o inalámbricas, el inicio del cuadro es una combinación muy compleja de bits, mientras que en RS-232 es un cambio simple de alto a bajo, y en I2C una simple violación de protocolo.

Lo que quiero decir es que no solo la comprobación de errores es diferente, sino que todos los elementos del protocolo son mucho más simples para los protocolos de a bordo que sus homólogos para comunicaciones por cable e inalámbricas. Y la razón es que la probabilidad de error es varias órdenes inferior a la de las comunicaciones por cable / inalámbricas.

    
respondido por el Claudio Avi Chami
2

La respuesta corta es que muchos dispositivos a los que se dirigen I2C y SPI son dispositivos de bajo consumo con pequeños conjuntos de instrucciones y memoria de programa limitada. Las especificaciones les permiten implementarse en el firmware con poca sobrecarga. Si tiene los caballos de fuerza, puede agregar tantas capas como necesite, pero estas capas eliminarían muchas aplicaciones incrustadas pequeñas.

    
respondido por el John Birckhead
0

No pude proporcionar una respuesta legítima, pero sí algunas comparaciones. Los protocolos de red necesitan capas de mecanismos, no es una buena idea hacer todos los propósitos a la vez, no tiene paquetes crc en PHY hasta que la capa MAC detectó el error de RF en 802.11.

SPI e i2c están sincronizados, por lo que la tasa de error y los conflictos de comunicación en el tiempo serán mínimos, y el hardware para implementarlos se considera escaso.

eso es todo lo que puedo pensar.

    
respondido por el einzeln00
0

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

Si tiene 3 relés que requieren una fiabilidad absoluta: Luego mida su salida con 3 entradas digitales, un sistema de confirmación redundante, adaptado a su aplicación.

Si se fue y diseñó un protocolo de comunicación personalizado, para resolver todos los problemas de confiabilidad de una vez por todas, estaría cometiendo un error de diseño común; Alejarse de los requisitos específicos para desviarse en generalidades.

    
respondido por el user5792628

Lea otras preguntas en las etiquetas