I2C Read Acknowledge und Stop condition

Einfach das I2C Device (Linux) oder z.B. die HAL-Routinen (STM) zu nehmen, das geht nicht?

Muss ja eine 'lustige' Architektur sein, wo der Hersteller nichts anbietet. Jede meiner benutzten Controller-Plattformen bot eine passende Bibliothek an.

Es gibt auch einige Bit-Banging Treiber mit Source Code. Da könnte man auch mal reinschauen. Google liefert ein Menge Antworten bei der Suche danach.

Peter ist so ein parade Beispiel für die toxische Kultur hier..

Nur am meckern.

Eigentlich beantwortet die originale Spec von Philips alle diese Fragen sehr ausführlich und zuverlässig.

Kurzform: Stop kommt erst nach dem Ende von allem anderen also nach dem letzten Ack/Nack.

Oliver

Ich habe Google, du auch?

https://www.nxp.com/docs/en/user-guide/UM10204.pdf

https://www.i2c-bus.org/specification/

https://de.wikipedia.org/wiki/I%C2%B2C

Max H. schrieb:

... ein parade Beispiel ...

o.m.g.

Fpga I. schrieb:

Beim Read Zugriff sendet der Master ja das Acknowledge zu den Daten. Wird beim letzten Byte dann auch noch ein Acknowledge gesendet? W

Das ist zwar Off-Topic hier, aber da die Diagramme dazu meist sehr gut und eindeutig sind und Du vielleicht per FPGA recht schnell: Schaue Dir "Clock-Stretching" genau an, wenn Du das noch nicht kennst!

Fpga I. schrieb:

Wo kommt dann die Stop Condition hin?

Ein Bild sagt mehr als tausend Worte: Fig. 7 auf S.6 https://www.ti.com/lit/an/slva704/slva704.pdf

Bei der Übertragung von Bits darf sich der Pegel von SDA während der H-Phase vom SCL nicht ändern. Bei der Stop-Condition findet dagegen auf SDA ein L-H Übergang statt.

Fpga I. schrieb:

Beim Read Zugriff sendet der Master ja das Acknowledge zu den Daten. Wird beim letzten Byte dann auch noch ein Acknowledge gesendet?

Natürlich nicht. Der Master muß dann ein NACK senden, damit der Slave weiß, daß er nun still zu sein hat. Ansonsten kann das STOP mit dem nächsten Datenbit kollidieren.

Bei den üblichen I2C-Chips muß das NACK vor dem letzten Datenbyte gesetzt werden, d.h. der Master taktet immer 9 Bits in einem Rutsch.

Hallo zusammen,

erst einmal vielen Dank für die hilfreichen Antworten (die anderen ignoriere ich einfach).

Dass das Stop Bit nach dem Ack gesendet wurde, sah für mich in den Datenblättern auch so aus, jedoch erschien es mir für den read Zugriff nicht plausibel, da das Ack dann ja vom Master getrieben wird und das Bit nach dem Ack dann wieder vom Slave. Sendet der Slave also eine '0' im MSB, kann ich keine Stop Condition mehr erstellen.

Des Rätsels Lösung: nach dem letzten Byte muss der Master ein NACK senden, um im nächsten Bit Zugriff auf den Bus zu haben. Somit kann der Slave also protokollbedingt nicht erkennen, ob das letzte Byte korrekt empfangen wurde, da es immer mit einem NACK bestätigt wird. Das ging aus den Datenblättern meiner Chips leider nicht hervor, ist aber im Datenblatt von Rainer schön dargestellt (S.7 Figure 9): https://www.ti.com/lit/an/slva704/slva704.pdf

edit: Danke @Peter D., das wäre die Antwort gewesen, die mir direkt geholfen hätte, hab sie nur leider etwas zu spät gesehen

Fpga I. schrieb:

Dass das Stop Bit nach dem Ack gesendet wurde

Nur der Vollständigkeit halber: bei I2C sind START und STOP keine Bits (wie z.B. bei asynchronen Datenübertragungen), sondern Zustände (="conditions") auf dem Bus.