Tres errores en I2C que todos desearían que no estuvieran ahí

La mejor parte de I2C es que es un bus que está disponible prácticamente en cualquier lugar, cubriendo un vasto ecosistema de dispositivos que lo ofrecen como una interfaz definida por hardware, y al mismo tiempo es lo suficientemente sencillo como para implementarse exclusivamente en software en GPIO simple. patas. A pesar de esta popularidad, I2C es uno de esos famosos estándares informales que presenta un par de implementaciones populares, mientras deja muchos de los detalles como la sincronización exacta, la capacitancia del bus y otros detalles tediosos al pobre tipo que desarrolla el producto. Por lo tanto, terminamos con artículos como uno reciente en el blog de trabalenguas [par de peras cortadas], que cubre problemas encontrados al implementar un esclavo I2C.

Al igual que con cualquier bus compartido, ya sea multimaestro o no, averiguar cuándo el bus está libre es un tema divertido, pero que puede causar interminables dolores de cabeza. Un problema aquí proviene de una característica que la versión SMBus de I2C llama lectura/escritura rápida. Esto permite la transferencia rápida de algunos datos. Aún así, dependiendo de los datos devueltos por el esclavo, al maestro le puede parecer que no está sucediendo nada todavía, ya que el esclavo mantiene el SDA bajo hasta la condición de parada, lo que esencialmente bloquea el bus.

Cuando las cosas se vuelven aún más emocionantes ocurre generalmente en la forma de lo que a los analizadores lógicos les encanta llamar traumáticamente una "espuria condición de inicio/parada". Esto se refiere al comportamiento de SDA y SCL, donde SDA baja antes de que SCL indique un error. Esto puede ocurrir debido a un tiempo de espera demasiado bajo, lo que hace que otros dispositivos en el bus pierdan la transición. Aquí SMBus define un tiempo de transición de 300 ns, mientras que I2C llama durante 0 segundos, pero ahora se sugiere retrasar la llamada a una condición de inicio/parada hasta que haya pasado un retraso de 300 ns. Básicamente, parecería que implementar un tiempo de espera es el camino a seguir hasta que aparezca evidencia de lo contrario.

El tercer problema se refiere a los modos de mayor velocidad de I2C, incluidos Fast-Mode (FM) y Fast-Mode Plus (FM+). La compatibilidad con versiones anteriores de estas versiones de mayor velocidad está ausente o es irregular. Aunque se supone que FM+ (introducido por NXP en 2007) es compatible con velocidades más lentas, efectivamente las diferencias en los requisitos de sincronización entre los estándares FM+ y FM son demasiado grandes para compensarlas. Al menos en las versiones actuales de los estándares, pero una de las alegrías de I2C es que siempre hay otro nuevo conjunto de revisiones que esperar.