8 votos

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

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?

11voto

RelaXNow Puntos 1164

Hay 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 te parece bien suponer que todas ellas se interpretarán según lo previsto.

Un circuito correctamente diseñado en una placa correctamente diseñada debería ser fiable. Piensa en una salida CMOS conduciendo una entrada CMOS a través de una placa. Aparte de un fallo total de los componentes (que es un problema totalmente diferente a la corrupción ocasional de datos), piense en lo que puede salir mal. En el extremo de accionamiento, tienes un FET con una resistencia máxima garantizada que conecta una línea a Vdd o a tierra. ¿Qué es exactamente lo que imaginas que puede hacer que no tenga el nivel correcto en el extremo receptor?

Inicialmente, el estado puede ser indeterminado, ya que cualquier capacitancia de la línea está cargada o descargada. Entonces puede haber timbre en la traza corta. Sin embargo, podemos calcular los tiempos máximos en el peor de los casos para que todo esto se estabilice y la línea cruce de forma fiable algún umbral en el otro extremo.

Una vez que se ha alcanzado este tiempo y hemos esperado a lo que sea el peor retardo de propagación de la lógica, hay poco que cambiar en la señal. Quizá pienses que el ruido de otras partes de la placa puede acoplarse a la señal. Sí, eso puede ocurrir, pero también podemos diseñar para ello. Por lo general, se conoce la cantidad de ruido que hay en otra parte de la placa. Si no es así, entonces viene de otra parte y en un diseño adecuado se sujetaría para limitarlo a un máximo dV/dt y otras características. Todas estas cosas pueden ser diseñadas.

En teoría, el ruido externo puede alterar las trazas de una placa, pero la intensidad del campo tendría que ser excesivamente grande para que la placa estuviera bien diseñada. Los entornos con mucho ruido existen, pero se limitan a lugares conocidos. Una placa puede no funcionar a 10 metros de un transmisor de 10 kW, pero incluso para eso se puede diseñar.

Así que la respuesta es básicamente que las señales digitales en la misma placa, si se diseñan adecuadamente, pueden considerarse absolutamente fiables para la mayoría de los usos ordinarios. En casos especiales en los que el coste del fallo es muy alto, como el espacio y algunas aplicaciones militares, se utilizan otras estrategias. Éstas suelen incluir subsistemas redundantes. Sigues considerando fiables las señales individuales de una placa, pero asumes que las placas o subsistemas en su conjunto pueden fallar ocasionalmente. También hay que tener en cuenta que estos sistemas cuestan mucho más, y una carga de costes así haría inútiles la mayoría de los sistemas ordinarios, como los ordenadores personales, por ejemplo, por ser demasiado caros.

Dicho esto, hay casos en los que incluso en la electrónica de consumo ordinaria se recurre a la detección y corrección de errores. Esto suele deberse a que el propio proceso tiene una cierta probabilidad de error y a que se están sobrepasando los límites. Las memorias principales de alta velocidad de los ordenadores suelen incluir bits adicionales para la detección y/o corrección de errores. Es más barato conseguir el rendimiento y la tasa de error final forzando los límites y añadiendo recursos a la corrección de errores que ralentizar las cosas y utilizar más silicio para que todo sea inherentemente más fiable.

7voto

Alex Andronov Puntos 178

Especialmente para los protocolos que no están diseñados para ser utilizados a través de cables, una placa correctamente diseñada no tendrá errores, y una placa mal diseñada no funcionará bien con o sin comprobación de errores. Por ejemplo, los fallos en un bus I2C con múltiples esclavos pueden bloquear permanentemente el bus(*) a menos que el maestro tenga un driver que pueda poner SDA alto incluso cuando los esclavos estén intentando ponerlo bajo. Protegerse contra eso haría el protocolo más lento, pero si el bus está lo suficientemente libre de fallos como para que ese posible comportamiento no se considere un riesgo, no habría mucha necesidad de lógica de comprobación de errores en general.

(*) Si un esclavo cree ver una condición de inicio en medio de un byte de datos que está siendo leído desde otro dispositivo, e interpreta los datos que están siendo leídos como el inicio de un comando que debería leer una cadena de ceros, entonces sería posible para cada uno de los dispositivos esclavos acusar recibo de los bytes de datos enviados al otro de tal manera que en cualquier momento dado al menos uno de los esclavos estaría reteniendo el bus.

3voto

honi Puntos 63

¿Por qué lo pregunta sólo en relación con la comprobación de errores?

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

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

2voto

John Birckhead Puntos 176

La respuesta corta es que muchos de los 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 permiten implementarlos en firmware con poca sobrecarga. Si se dispone de la potencia necesaria, se pueden añadir tantas capas como sea necesario, pero estas capas eliminarían muchas pequeñas aplicaciones integradas.

0voto

ggambett Puntos 155

No podría dar una respuesta legid, pero sí alguna comparación. Los protocolos de red necesitan capas de mecanismos, hacer todos los propósitos a la vez no es una buena idea, no tienes crc de paquetes en PHY hasta que la capa MAC ha detectado el error de RF en 802.11.

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

es todo lo que se me ocurre.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X