I2C es de alguna manera un protocolo muy bueno, pero su propósito de diseño es interconectar dispositivos en una sola tarjeta. Incluso más allá de los problemas de los niveles de señalización, también existen algunos problemas de protocolo que pueden plantear problemas cuando se utiliza para comunicaciones de múltiples tarjetas.
Por ejemplo, supongamos que hay dos dispositivos esclavos conectados que permitirían a un maestro leer un número arbitrario de bytes y que podrían devolver cero para un número arbitrario de esos bytes. Si mientras un dispositivo está enviando datos al maestro, un segundo dispositivo interpreta erróneamente parte de los datos como una secuencia de "INICIO" seguida de su dirección de lectura, sería posible que para cada ciclo de reloj posterior, al menos uno de los dispositivos falte. para generar un bit de datos "0". Tal escenario haría imposible que el maestro recupere el control del bus. Si bien es posible diseñar comunicaciones de una sola placa de manera que los impulsos parásitos "simplemente no ocurran", a menudo no es posible cuando se conectan muchos dispositivos. Uno puede intentar minimizar la probabilidad de que se produzcan pulsos parásitos, pero no debe esperar evitarlos por completo. La lectura de un sensor se corrompe una vez al mes debido a un pulso parásito puede ser aceptable, pero tener el sistema bloqueado una vez al mes probablemente no lo sea tanto.
Si está utilizando una configuración de un solo maestro, sugeriría que valdría la pena utilizar cables separados para SDA a los esclavos y el retorno de SDA. Si los esclavos están utilizando un apretón de manos, puede valer la pena hacer lo mismo para SCK. La salida del maestro podría entonces ser activada activamente alta y baja (en lugar de ser impulsada activamente baja y pasivamente elevada). Si los conectores hubieran designado los lados de "entrada" y "salida", cada placa de la cadena podría "Y" el retorno del dispositivo anterior con el estado del pin de su propio dispositivo, y dar salida activa a alto y bajo en la dirección de retorno también. Es probable que un diseño de este tipo requiera el uso de un maestro de bit-bang en lugar de un maestro de hardware, pero dado que las implementaciones de software-maestro a menudo pueden administrar una mejor recuperación de errores que los maestros de hardware que no deberían ser una limitación.
Además de la robustez mejorada que resulta de la unidad activa-alta / activa-baja, el uso de cables de salida / retorno separados para SDA evitará la posibilidad de que un dispositivo esclavo interfiera con los intentos del maestro para que otro dispositivo se cierre, ya que incluso si todos los dispositivos esclavos, excepto uno, quisieran una salida baja en SDA, el maestro no tendría ningún problema en generar una transición de bajo a alto en el pin SDA del último esclavo restante.
Si no desea utilizar los cables adicionales para separar el SDA del retorno de SDA, sería posible cablear los esclavos de modo que su resistencia de extracción en SDA fuera limitada, y cablear el maestro para que pueda dominar con seguridad a los esclavos. Eso permitiría una recuperación limpia en caso de mal funcionamiento del esclavo, pero no ofrecería las ventajas de limpieza de la señal de usar cables separados. Además, solo funcionaría bien si no se utiliza el handshaking. La operación robusta de I2C requiere que las transiciones en SCK y SDA estén separadas por un tiempo superior al sesgo de transmisión del peor caso. Si el maestro está en control exclusivo de SCK, puede garantizarlo. Sin embargo, los esclavos que utilizan el protocolo de enlace, pueden generar eventos de forma asincrónica en SCK y SDA, sin que el maestro controle su separación.
