Was ist das I2C ACK und wie erkenne ich es?

Die Spezifikation besagt, dass das ACK nach dem 8. Takt aus einem niedrigen Pegel besteht, wie dieses Diagramm zeigt:

Der Busmaster erzeugt einen 9. Taktimpuls zum Lesen des Pegels. Die Spezifikation spricht nicht über das Pulsen von ACK, und der Master wird es auch nicht bemerken. Befolgen Sie die Spezifikation und kümmern Sie sich um die Einrichtungs- und Haltezeiten der Daten (250 ns und 5$\mu$s bzw. für den Standardmodus), um sicherzustellen, dass der Füllstand richtig erkannt wird.

Was Sie als Spitze im ACK sehen, ist kein Teil des ACK, sondern eine Busfreigabe zwischen dem ACK und einem ersten Datenbit auf niedrigem Pegel des nächsten Wortes. Die Busfreigabe erfolgt, nachdem SCL wieder auf Low geht, sowohl in Ihrem als auch in meinem Diagramm. Gemäß dem obigen Diagramm ist diese Freigabe erforderlich; Beachten Sie, dass der niedrige Pegel des SDA nach ACK unterbrochen wird, was anzeigt, dass SDA hoch gehen muss.

Hinweis: Die Busfreigabe wird nicht im Timing-Diagramm, Abbildung 38, angezeigt, noch ist das Timing in den AC-Kennlinien angegeben. Ich konnte im Text der Spezifikation keinen Hinweis darauf finden. Es gibt auch keine SCL-Aktivität während dieses SDA-Hochs. Dies deutet darauf hin, dass die Busfreigabe nicht wirklich erforderlich ist. In diesem Fall enthält das Diagramm einen Fehler, der anscheinend von anderen kopiert wurde, wie im TMP175-Datenblatt.

bearbeiten
Madmanguruman kommentiert, dass das ACK vom Slave kommt, während das nächste Datenbit vom Master kommt. Das wird oft der Fall sein, und er hat Recht. Das nächste Datenbit kommt aber auch vom Slave, wenn es die Antwort des Slaves auf einen Lesebefehl ist. Dann wäre es durchaus sinnvoll, dass der Slave den Bus nicht freigibt.

Ich habe neulich versucht, einen I2C-DAC zum Laufen zu bringen, und ich hatte genau dieselbe Frage. Der Busmaster/Host sendet ein Byte an ein Gerät und sobald das Gerät es erfolgreich empfangen hat, zieht es die Datenleitung (SDA) auf Low, um dem Busmaster anzuzeigen, dass das Byte empfangen wurde. Das Datenblatt des DAC erwähnte einen Gerätekonnektivitätstest, indem nach dem ACK des Geräts gesucht wurde. Da ich nur Zugriff auf ein analoges Oszilloskop hatte, stellte ich schnell fest, dass der DAC höchstwahrscheinlich keine ACKs sendete, da der Rahmen auf dem seriellen Bus nur lang genug für ein einzelnes Byte war, während ich drei aufeinanderfolgende Bytes erwarten würde. Außerdem konnte ich kein überzeugendes ACK im Signal finden (ein niedriges Bit). Ich dachte mir, dass der Busmaster / Host intelligent genug sein könnte, das zweite Byte nicht zu senden, wenn er kein ACK vom Empfänger, dem DAC, erhalten hat. Das würde erklären, warum ich zu kurze Nachrichten gesehen habe, die den I2C-Bus passierten. Da der DAC ein ziemlich einfaches Gerät ist, war die einzige Option, die mir einfiel, die Verwendung einer falschen Geräteadresse. Also fing ich an zu versuchen, den DAC mit verschiedenen Adressen anzusprechen, und ziemlich schnell entdeckte ich einen Rahmen auf dem seriellen Bus, der viel länger war als die anderen.

Nun zur Beantwortung Ihrer Frage: Als ich den DAC erfolgreich ansprechen konnte, bemerkte ich einen interessanten Effekt. Als meine Oszilloskopsonde in der Nähe des DAC angebracht war, war der ACK-Impuls auf dem analogen Oszilloskop deutlich sichtbar. Wo alle vom Host gesendeten Bits einen bestimmten Mindestspannungspegel hatten, wurden die ACK-Impulse viel besser auf 0 V gezogen. So würden beispielsweise vom Host gesendete 0-Bits etwa 0,2 V messen, die ACKs würden 0,1 V messen. Die Werte in diesem Beispiel dienen nur dazu, meinen Standpunkt zu veranschaulichen. Dadurch heben sich die ACK-Pulse deutlich vom restlichen Datenstrom ab.

Jede laufende I2C-Transaktion wird beendet, wenn sich SDA ändert, während SCK hoch ist. Jedes I2C-Gerät, das SDA aktivieren oder freigeben möchte, muss dies entweder zu einem Zeitpunkt tun, zu dem sicher sein kann, dass SCK nicht steigen wird. Es gibt zwei Möglichkeiten, wie ein Gerät sicher sein kann, dass SCK nicht ansteigen wird: (1) es kann SCK selbst bestätigen, oder (2) wenn es eine fallende Flanke an SCK sieht, kann es wissen, dass SCK für a niedrig bleiben wird bestimmte Mindestzeit (abhängig von der Busgeschwindigkeit). Da die meisten I2C-Slave-Geräte niemals SCK selbst geltend machen, können sie ihre Ausgabe auf SDA nur unmittelbar nach einer fallenden Flanke von SCK sicher ändern.

Ein I2C-Master kann jedoch jederzeit den Zustand auf SDA ändern, wenn er SCK geltend macht. Um den Zustand des ACK-Bits eines entfernten Geräts zu lesen, muss der Master SDA vor der ansteigenden Taktflanke nach dem ack freigeben und muss es bis nach der nächsten abfallenden Flanke von SCK freigegeben lassen. Selbst wenn das erste übertragene Bit nach dem "ack" eine "0" sein sollte, sollte der Master zwischen der Behauptung von SCK und der Behauptung von SDA verzögern. Die Tatsache, dass Slaves sofort auf eine fallende Flanke an SCK reagieren, während Master eine Verzögerung zwischen dem Ansteuern von SCK und SDA hinzufügen müssen, bedeutet, dass es bei einer "Übergabe" der Steuerung vom Slave an den Master oft einen kurzen Moment geben wird wenn keines der Geräte es für angemessen hält, SDA geltend zu machen (technisch gesehen die erforderliche Mindestverzögerung zwischen Master'

Wenn übrigens keine Slaves Clock-Stretching verwenden, kann man auf einem Scope-Plot leicht feststellen, welche SDA-Änderungen vom Master und welche vom Slave verursacht werden. Ändert sich SDA gleichzeitig mit dem Wechsel von SCK von High auf Low, wird die Änderung vom Slave verursacht. Wenn sich SDA zu einem anderen Zeitpunkt ändert, wird die Änderung vom Master verursacht.