He estado investigando las diferentes formas de conectar sensores a un Arduino, y i2c parece ser un método popular. He leído que sólo es fiable a distancias cortas (unos pocos metros, como mucho), con una velocidad de datos de 400 o 100kbps. Me cuesta entender por qué los límites de este protocolo son tan bajos en comparación con otras transmisiones de datos por cobre, como el gigabit Ethernet. He visto razones como la capacitancia, la caída de tensión y la resistencia, pero ¿no está Ethernet sobre cat5/6 sujeta a todos esos mismos problemas? Básicamente, quiero saber por qué al pulsar un voltaje por un cable de cobre no se obtienen resultados más consistentes (ancho de banda, distancia) cuando se comparan estas diferentes metodologías.
Respuestas
¿Demasiados anuncios?
hacktastical
Puntos
560
El teorema de Shannon establece el límite máximo del ancho de banda de la información en un cable. Aquí hay más información al respecto: https://www.gaussianwaves.com/2008/04/channel-capacity/
Versión tl; dr: la ecuación de Shannon-Hartley:
- \$ C = B \; log_2 \left( 1 + \frac{S}{N}\right) \;\;\;\;\;\;\;\;\;\; \rightarrow (1)\$
Donde \$B\$ es el ancho de banda en Hz, \$\frac{S}{N}\$ es la relación señal-ruido.
Obviamente, I2C no se acerca al límite de Shannon para un cable. En cambio, es un protocolo ligero con una temporización intencionadamente lenta (100/400 kbit/s) que utiliza un bus de colector abierto para facilitar su implementación en una red de pequeños dispositivos con modestas necesidades de E/S y control. La lentitud de funcionamiento especificada por I2C evita la mayoría de los problemas de integridad de la señal.
Hay variantes más rápidas de I2C que utilizan tasas de 1 Mbit y 3,2 Mbit/s. Estas requieren más atención al diseño y la terminación que el I2C normal y, por supuesto, tienen una temporización más ajustada y exigente.
Subiendo en la cadena alimenticia de Shannon, Gbit Ethernet utiliza múltiples técnicas para lograr su rendimiento:
- Señalización diferencial
- Pares múltiples (4)
- Señalización multinivel, denominada PAM-5
- Preénfasis / Desénfasis
- Ecualización adaptativa
Estas técnicas requieren mucho silicio, incluido un bloque ADC/DAC de señal mixta rápido y grande para hablar con el cable y un procesamiento de señales bastante pesado para gestionarlo. A esto hay que añadir una pila de software mucho más compleja para manejarla. Esto hace que Ethernet como bloque en el chip sea demasiado para un microcontrolador de gama baja (algunos de los cuales optan por utilizar un PHY externo en su lugar). Sin embargo, su madurez lo pone al alcance de los grandes sistemas en chip.
¿Cómo de cerca estamos del límite de Shannon? Más información aquí: https://pdfs.semanticscholar.org/482f/5afbf88a06d192f7cb052f543625c4b66290.pdf
Toor
Puntos
777
La transmisión es algo más que el cable de cobre. ¿Has visto el hardware que hay detrás de ethernet? Probablemente no, porque es muy difícil encontrar un circuito básico de lo que realmente ocurre, ya que las tripas siempre están escondidas en un circuito integrado. Lo más parecido que he encontrado son los imanes necesarios para ethernet, que aparentemente no son opcionales. Eso es sólo una pista de lo que sucede físicamente con el hardware de ethernet.
Piénsalo así: El aire es un medio. ¿Por qué el tipo de información que se puede transmitir cuando los perros hablan entre sí es mucho menor que cuando los humanos hablan entre sí? ¿Por qué el envío de algunas ondas de presión a través del aire no da resultados más consistentes en la comunicación entre estos dos tipos de animales?
Algunos de los factores limitantes de I2C (y de muchos otros protocolos) son:
- accionamiento por colector abierto
- sin adaptación de la impedancia
- no hay transmisión equilibrada
- no hay comprobación de errores
- esquema de codificación simple
- niveles de tensión relativamente altos (si el paso de tensión no tiene que ser tan grande puedes transmitir más rápido porque tu dV/dT no tiene que ser tan alto para velocidades más altas)
- sin aislamiento
- tensiones unipolares (ethernet transmite a +/- 2,5V lo que probablemente ayude de alguna manera)
- La transmisión del esclavo es sincronizada por el maestro, así que básicamente el reloj tiene que hacer un viaje de ida y vuelta más rápido que la señal de datos
Todo esto es bueno para simplificar las cosas. No son tan buenos para las altas tasas de datos o la transmisión a larga distancia.
También es probable que haya algún otro vudú en el hardware que desconozco.
samjudson
Puntos
27483
Unas sencillas reglas generales: La tierra no existe. Todos los cables son antenas. Todos los cables son líneas de transmisión. Siempre hay ruido.
Si un cable es corto en comparación con el tiempo de subida de la señal, se pueden ignorar los desajustes de la impedancia de la línea de transmisión y las reflexiones (a diferencia de Ethernet, que requiere complejas terminaciones y formación de impulsos). Si el cable es largo, es más probable que las tensiones inducidas en el cable y los diferenciales de tierra hagan que los niveles de la señal digital en el extremo lejano sean indeterminados o incorrectos. Pero Ethernet utiliza señalización diferencial de par trenzado, lo que reduce en gran medida los problemas de ruido inducido y de referencia de tierra. El receptor de Ethernet también utiliza entradas analógicas más sensibles en lugar de las típicas entradas digitales, lo que permite una mayor pérdida de línea. Si a esto le añadimos la codificación y la corrección de errores de Ethernet para superar las estadísticas del ruido, se puede llegar más rápido y más lejos de forma fiable.
Dan Mills
Puntos
381
I2C es un bus de drenaje abierto El nivel de la resistencia es bajo, pero el pull up (al menos para las variantes normales de 100kHz y 400kHz) son resistencias pasivas.
Debido a esto hay un límite en la rapidez con la que la cosa puede trabajar basado en la rapidez con la que las resistencias de pull up pueden cargar la capacitancia del bus, a veces se puede obtener algo más de velocidad mediante la reducción de los valores de pull up, pero eso significa que los nodos tienen que hundir más corriente para obtener una lógica baja.... O puedes ir en la dirección contraria, ralentizar el bus para permitir el uso de resistencias pull up de mayor valor para una menor disipación de energía (ver por ejemplo el bus PM).
Es instructivo encender un osciloscopio y notar que el borde descendente en I2C es MUCHO más agudo que el ascendente.
Para el uso previsto, básicamente sensores de temperatura y pequeños dispositivos de configuración dentro de una única placa (o como mucho un único chasis) resulta que esto da en el clavo entre la complejidad de la implementación, el bajo número de pines y el hardware simple. La intención del diseño no era "Enlaces de datos rápidos y de larga distancia", y a pesar de que encuentro que SPI es generalmente más fácil de manejar, I2C se ajusta a su caso de uso previsto realmente muy bien.
Una vez que las distancias aumentan entonces algo más se convierte en un mejor ajuste, pero en una placa con modestas interfaces de configuración de eeprom/temperatura/dispositivo, lo hace razonablemente bien (Vale la pena señalar que la interfaz de gestión de PHY se parece MUCHO a I2C).
Ozzyprv
Puntos
1
Los diferentes resultados se deben a que el circuito conductor es diferente para cada tecnología.
El I2C de 100kHz suele utilizar una resistencia pullup para poner la señal en un nivel alto, y controladores de drenaje abierto para poner la señal en un nivel bajo.
Las resistencias pullup suelen ser de varios kilo-ohmios. Cuanto más largo sea un cable, más capacitancia tendrá. El tiempo que tarda la línea en pasar de 0 a 1 será proporcional a la capacidad total de la línea y al valor de la resistencia de subida. Un valor aproximado de T = 2*R*C sería correcto.
Por ejemplo, si tienes un cable de 10 pies que tiene 20pF por pie de capacitancia y usas una resistencia pullup de 10K, entonces tomaría T = 2 * 20pF/pie * 10 pies * 10K = 3.6us para la transición de bajo a alto.
En este caso, obviamente no podrías tener ningún bit de uno que siguiera a un bit de cero que tuviera una anchura inferior a 3,6us, por lo que tu velocidad de transmisión estaría limitada a 277kHz.
En un sistema I2C real, la especificación I2C exige además tiempos de preparación y retención en torno a las transiciones de datos y reloj. Esos tiempos son de cientos de nanosegundos o microsegundos. La temporización se hizo muy lenta a propósito para que los dispositivos pudieran implementarse de forma barata (centavos), y consumir muy poca energía (milivatios).
Por otro lado, Ethernet puede funcionar más rápido a pesar de la capacitancia del cable porque no utiliza una resistencia de pullup. Conduce activamente ya sea alta o baja en el cable. El controlador es de baja impedancia y puede cargar cualquier capacitancia de la línea muy rápidamente. Por supuesto, todo esto tiene un precio. Ethernet suele consumir cientos de mW de potencia y su implementación cuesta al menos unos cuantos dólares por puerto.
Podría una configuración similar a I2C correr más rápido, seguro, sólo cambia el pullup de 10K a 100 ohmios y ahora su tiempo de subida en 10 pies de cable cae de 3,6us a 36ns. Entonces probablemente podrías correr a unos 10MHz sin demasiados problemas (aparte del hecho de que los chips I2C normales no pueden hablar tan rápido).
