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

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

El maestro del bus generará un noveno impulso 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 los datos y los tiempos de espera (250 ns y 5 \ $ \ mu \ $ s 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 databit de bajo nivel de la siguiente palabra. El lanzamiento del bus viene después . SCL vuelve a bajar, 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 ir alto.

Nota: la versión del bus no se muestra en el diagrama de tiempo, figura 38, ni el tiempo se da en las características de CA. No pude encontrar ninguna referencia a ella en el texto de la especificación. Tampoco hay actividad de SCL durante esta alta SDA. Esto sugiere que el lanzamiento del autobús no es realmente requerido. 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 databit proviene del maestro. Esto será a menudo el caso, y él tiene un punto. La siguiente base de datos también vendrá del esclavo, sin embargo, si es la respuesta del esclavo a un comando de lectura. Entonces tendría perfectamente sentido que el esclavo no suelte el bus.

Estaba intentando que un DAC I2C funcionara el otro día y tenía la misma pregunta. El bus maestro / host envía un byte a un dispositivo y, una vez que el dispositivo lo recibió con éxito, tira de la línea de datos (SDA) hacia abajo para indicar al bus maestro 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 me di cuenta de que era muy probable que el DAC no enviara los ACK, porque la trama en el bus serie solo era lo suficientemente larga 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 bus maestro / host 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 al pasar 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 empecé a tratar de dirigir el DAC con diferentes direcciones y rápidamente detecté una trama en el bus serie que era mucho más larga que las otras.

Ahora, para responder a tu pregunta: una vez que pude abordar el DAC con éxito, noté un efecto interesante. Con mi sonda de alcance conectada cerca del DAC, el pulso ACK era claramente visible en el alcance analógico. Cuando todos los bits enviados desde el host tenían un cierto nivel de voltaje mínimo, los impulsos ACK se aplicaban mucho mejor a 0V. Entonces, por ejemplo, los 0 bits enviados desde el host medirían aproximadamente 0.2V, los ACK medirían 0.1V. Los valores en este ejemplo están hechos 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 terminará si SDA cambia mientras SCK está alto. Cualquier dispositivo I2C que quiera hacer valer o liberar SDA debe hacerlo en un momento en que pueda estar seguro de que SCK no va a aumentar. Hay dos maneras en que un dispositivo puede estar seguro de que SCK no va a aumentar: (1) puede estar afirmando que SCK mismo, o (2) si ve un borde descendente en SCK, puede saber que SCK seguirá siendo bajo durante un tiempo. 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 hacen valer SCK, la única vez que pueden cambiar de manera segura lo que están emitiendo en SDA es inmediatamente después de un flanco 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 límite ascendente del reloj después de la confirmación, y debe dejarlo liberado hasta después del siguiente flanco descendente de SCK. Incluso si el primer bit transmitido después de "ack" debería ser un "0", el maestro debería 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 conducción de SCK y SDA, significa que en una "transferencia" del control del esclavo al maestro, a menudo habrá un breve momento cuando ninguno de los dos dispositivos lo considerará apropiado para afirmar SDA (técnicamente, el retraso mínimo requerido entre la afirmación del maestro de SCK y su afirmación de la SDA es menor que el máximo requerido entre la afirmación del maestro de SCK y la liberación del esclavo de la SDA, pero la mayoría de los maestros retraso más largo que eso).

Por cierto, si ningún esclavo usa el estiramiento de reloj, se 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 es causado por el maestro.