¿Qué es el I2C ACK y cómo lo detecto?

La especificación dice que el ACK consiste en un nivel bajo después del octavo pulso de reloj, como se muestra en este diagrama:

El bus maestro generará un noveno pulso de reloj para leer el nivel. La especificación no habla de pulsar ACK, y el maestro tampoco lo notará. Siga las especificaciones y cuide la configuración de datos y los tiempos de espera (250 ns y 5$\mu$resp. para el modo estándar) para asegurarse de que el nivel se detecte correctamente.

Lo que ve como un pico en el ACK no es parte del ACK, sino una liberación de bus entre el ACK y un primer bit de datos de bajo nivel de la siguiente palabra. La liberación del bus se produce después de que SCL vuelve a estar bajo, tanto en su diagrama como en el mío. De acuerdo con el diagrama anterior, se requiere esta versión; tenga en cuenta que el nivel bajo de SDA después de ACK se interrumpe, lo que indica que SDA debe subir.

Nota: la liberación del bus no se muestra en el diagrama de temporización, figura 38, ni se da la temporización en las características de CA. No pude encontrar ninguna referencia a él en el texto de la especificación. Tampoco hay actividad de SCL durante este máximo de SDA. Esto sugiere que la liberación del bus no es realmente necesaria. En ese caso, el diagrama contiene un error, aparentemente copiado por otros, como en la hoja de datos de TMP175.

editar
Madmanguruman comenta que el ACK proviene del esclavo, mientras que el siguiente bit de datos proviene del maestro. Este será a menudo el caso, y tiene razón. Sin embargo, el siguiente bit de datos también vendrá del esclavo, si es la respuesta del esclavo a un comando de lectura. Entonces tendría perfecto sentido que el esclavo no suelte el bus.

Estaba tratando de hacer funcionar un DAC I2C el otro día y tuve esta misma pregunta. El host/maestro del bus envía un byte a un dispositivo y, una vez que el dispositivo lo recibió correctamente, baja la línea de datos (SDA) para indicarle al maestro del bus que se recibió el byte. La hoja de datos del DAC mencionó una prueba de conectividad del dispositivo al buscar el ACK del dispositivo. Al tener acceso solo a un osciloscopio analógico, rápidamente descubrí que el DAC probablemente no estaba enviando ACK, porque el marco en el bus en serie solo era lo suficientemente largo para un solo byte, mientras que esperaría tres bytes consecutivos. Además de eso, no pude encontrar un ACK convincente en la señal (un bit bajo). Pensé que el maestro/anfitrión del bus podría ser lo suficientemente inteligente como para no enviar el segundo byte si no recibía un ACK del receptor, el DAC. Eso explicaría por qué vi mensajes demasiado cortos pasando el bus I2C. Dado que el DAC es un dispositivo bastante simple, la única opción que se me ocurrió fue usar una dirección de dispositivo incorrecta. Así que comencé a tratar de direccionar el DAC con diferentes direcciones y, rápidamente, detecté un cuadro en el bus serie que era mucho más largo que los demás.

Ahora, para responder a su pregunta: una vez que pude abordar con éxito el DAC, noté un efecto interesante. Con mi sonda de alcance conectada cerca del DAC, el pulso ACK era claramente visible en el alcance analógico. Donde todos los bits enviados desde el host tenían un cierto nivel de voltaje mínimo, los pulsos ACK se extrajeron mucho mejor a 0V. Entonces, por ejemplo, los bits 0 enviados desde el host medirían alrededor de 0,2 V, los ACK medirían 0,1 V. Los valores en este ejemplo están inventados para ilustrar mi punto. Esto hizo que los pulsos ACK se destacaran claramente del resto del flujo de datos.

Cualquier transacción I2C en curso se cancelará si SDA cambia mientras SCK es alto. Cualquier dispositivo I2C que desee afirmar o liberar SDA debe hacerlo en un momento en el que pueda estar seguro de que SCK no aumentará. Hay dos formas en que un dispositivo puede estar seguro de que SCK no aumentará: (1) puede estar afirmando SCK en sí mismo, o (2) si ve un borde descendente en SCK, puede saber que SCK permanecerá bajo por un cierta cantidad mínima de tiempo (dependiendo de la velocidad del autobús). Debido a que la mayoría de los dispositivos esclavos I2C nunca afirman SCK por sí mismos, la única vez que pueden cambiar de manera segura lo que están emitiendo en SDA es inmediatamente después de un borde descendente de SCK.

Sin embargo, un maestro I2C es libre de cambiar el estado en SDA en cualquier momento en que esté afirmando SCK. Para leer el estado del bit ACK de un dispositivo remoto, el maestro debe liberar SDA antes del flanco ascendente del reloj que sigue al ACK, y debe dejarlo liberado hasta después del siguiente flanco descendente de SCK. Incluso si el primer bit transmitido después del "reconocimiento" debe ser un "0", el maestro debe demorar entre la afirmación de SCK y la afirmación de SDA. El hecho de que los esclavos reaccionen inmediatamente a un flanco descendente en SCK, mientras que los maestros deben agregar un retraso entre la activación de SCK y SDA, significa que en una "transferencia" de control del esclavo al maestro, a menudo habrá un breve momento cuando ninguno de los dispositivos considerará apropiado afirmar SDA (técnicamente, el retraso mínimo requerido entre el maestro '

Por cierto, si ningún esclavo usa la extensión del reloj, uno puede decir fácilmente en un diagrama de alcance qué cambios de SDA son causados ​​por el maestro y cuáles son causados ​​por el esclavo. Si SDA cambia al mismo tiempo que SCK cambia de alto a bajo, el cambio es causado por el esclavo. Si SDA cambia en cualquier otro momento, el cambio lo provoca el maestro.