Wie beendet man das Senden von Daten über I2C durch Slave oder Master?

Nehmen wir an, ein Slave oder Master sendet mehrere Bytes auf dem I2C-Bus an den Empfänger und die Anzahl der Bytes ist nicht im Voraus definiert. Wie teilt der Sender dem Empfänger dann mit, dass er keine Daten mehr zu senden hat?

Bisher verstehe ich, dass für den Fall, dass der Absender Master ist, er ein NACK sendet, um dem Slave (Empfänger) mitzuteilen, dass keine Daten mehr zu senden sind. Und nach dem Senden von NACK sendet es die STOP-Bedingung, um die Sitzung zu beenden.

Aber ich frage mich, wie dieser Handshaking zwischen einem Master und einem Slave stattfindet, wenn der Slave Sender und der Master Empfänger ist und nur der Slave (Sender) weiß, wann keine Daten mehr an den Empfänger gesendet werden müssen.

Antworten (6)

Aber ich frage mich, wie dieser Handshaking zwischen einem Master und einem Slave stattfindet, wenn der Slave Sender und der Master Empfänger ist und nur der Slave (Sender) weiß, wann keine Daten mehr an den Empfänger gesendet werden müssen.

Das soll nicht passieren. i2c ist ein sehr definiertes Protokoll und jedes Slave-Gerät sollte jedem Master bekannt sein. Typischerweise fordert der Master den Slave zum Senden auf, und entweder ist die Nachrichtengröße festgelegt, die Nachricht ist sequentiell oder die Nachricht enthält, wie viele Bytes gesendet werden.

  1. Der Master schreibt eine Registeradresse, dann schaltet der Master auf Lesen und der Slave sendet ein Byte. Das ist alles, was der Meister will, schickt einen Stopp.

  2. Der Master schreibt eine Registeradresse, dann schaltet der Master auf Lesen und der Slave sendet ein Byte, dann liest der Master erneut, sodass der Slave das nächste Byte (oder dasselbe Byte) sendet. Der Master liest willkürlich, wie viele er will, und sendet dann einen Stopp.

  3. Der Master schreibt eine Registeradresse, dann schaltet der Master auf Lesen und der Slave sendet ein Byte. Dieses Byte teilt dem Master mit, wie viele Bytes dieses Register haben sollte. Der Master liest und der Slave sendet so viele, dann stoppt der Master.

Die gesamte Kommunikation wird vom Master gesteuert. Der Sklave tut nichts, was der Meister nicht will. Der Master steuert die Taktgeschwindigkeit (Taktdehnung nicht standhaltend) und wie viele Bytes gelesen werden. Zu keinem Zeitpunkt sollte der Slave versuchen, die Datenleitung zu erzwingen, wenn der Master es ihm nicht gesagt hat. Die Datenstruktur sollte vorher bekannt sein.

Exakt. Wenn Ihr Slave mit dem Master sprechen möchte, sollte er etwas anderes verwenden, nicht I2C. Vielleicht eine Unterbrechungsleitung zu einem anderen I/O. Warten Sie andernfalls, bis Sie angesprochen werden.
Es kann sogar sein, dass der Slave keine eigene Taktquelle hat und sich vollständig auf die vom Master bereitgestellte I2C-Uhr verlässt.
@Michael Das scheint gefährlich zu sein. In einer Multi-Slave-Umgebung bedeutet dies, dass ein anderes Gerät gesperrt wird, wenn sich eine Slave-Uhr ausdehnt. Ich bin mir nicht sicher, ob ich so einen i2c-IC gesehen habe.

Das sind die beiden Optionen.

Wenn der Slave-Empfänger keine weiteren Daten akzeptiert, kann er das Byte NAKen, aber der Master ist immer noch für das Senden der Stoppbedingung verantwortlich.

Für einen Slave-Sender kann es nichts zum Stoppen signalisieren, es muss vorher bekannt sein, oder es könnte in den Daten kodiert sein, z. B. wird eine Textzeichenfolge mit einer Null abgeschlossen, damit der Slave Nullen senden kann, bis der Master stoppt.

Normalerweise ist dies selten und es gibt ein bekanntes Protokoll, sodass der Master immer im Voraus wissen muss, wie viele Bytes er in einer einzelnen Transaktion lesen oder schreiben wird, selbst wenn es bedeutet, zuerst einen Header mit fester Größe zwischen Geräten zu übertragen, wie viel zu übertragen ist.

Nehmen wir an, ein Slave oder Master sendet mehrere Bytes auf dem I2C-Bus an den Empfänger und die Anzahl der Bytes ist nicht im Voraus definiert. Wie teilt der Sender dem Empfänger dann mit, dass er keine Daten mehr zu senden hat?

Wenn der Master der Sender ist, dann weiß er, wie viele Bytes gesendet werden müssen. Der Master signalisiert das Ende seiner Datenübertragung durch Senden einer STOP-Bedingung nach dem Senden des letzten Bytes und beendet die Transaktion.

Beachten Sie, dass der Meister dies jederzeit tun kann. Der Slave kann NACK senden, um mitzuteilen, dass er keine Daten mehr empfangen möchte. Aber nur der Master entscheidet, ob diese Transaktion gestoppt wird.

Aber ich frage mich, wie dieser Handshaking zwischen einem Master und einem Slave stattfindet, wenn der Slave Sender und der Master Empfänger ist und nur der Slave (Sender) weiß, wann keine Daten mehr an den Empfänger gesendet werden müssen.

Wenn der Slave der Sender ist, sollte der Master vorher wissen, wie viele Bytes empfangen werden müssen. Der Master signalisiert dies, indem er nach Erhalt des letzten Bytes ein NACK sendet, sodass der Slave die SDA-Leitung nicht mehr ansteuert. Der Master kann nun eine STOP-Bedingung einleiten und die Transaktion beenden.

Lesen Sie hier gut: TEXAS i2c

Ich werde deinen ganzen Post nach und nach verdauen...

Nehmen wir an, ein Slave oder Master sendet mehrere Bytes auf dem I2C-Bus an den Empfänger und die Anzahl der Bytes ist nicht im Voraus definiert.

Aber es sollte definiert werden. Wenn zufällige Informationen gesendet oder empfangen wurden, können Sie diese niemals interpretieren.

Wie teilt der Sender dem Empfänger dann mit, dass er keine Daten mehr zu senden hat?

Der Hersteller legt fest, wie viele Bits er vom Slave empfangen muss. Der Master wird normalerweise von einem Logikgerät wie einem Mikrocontroller, einer CPU usw. geschrieben.

Bisher verstehe ich, dass für den Fall, dass der Absender Master ist, er ein NACK sendet, um dem Slave (Empfänger) mitzuteilen, dass keine Daten mehr zu senden sind.

Nein, nicht ganz richtig richtig. Ein "NACK" tritt auf, wenn der Master nichts vom Slave "hört", nachdem er dieses Bit an den Slave gesendet hat. Es ist, als würde man telefonieren und sagen: "Hallo, bist du da?"

Aber ich frage mich, wie dieser Handshaking zwischen einem Master und einem Slave stattfindet, wenn der Slave Sender und der Master Empfänger ist und nur der Slave (Sender) weiß, wann keine Daten mehr an den Empfänger gesendet werden müssen.

Ihre Definition von Sender und Empfänger ist verzerrt. Sowohl der Master als auch der Slave fungieren sowohl als Sender als auch als Empfänger. Der Master kann je nach Schreib- bzw. Leseoperation sowohl senden als auch empfangen.


Hilfreicher Rat: Erwägen Sie, irgendein I2C-Slave-Datenblatt zu lesen. Suchen Sie nach dem Schlüsselwort „Nachricht“. Das sind die Informationen, die der Master an den Slave sendet.

Geben Sie hier die Bildbeschreibung einBild von hier ... nicht mein Bild.

Der Master sollte so programmiert werden, dass er die gleiche Länge des Adressrahmens wie der Slave liest, was durch das Datenblatt des Slaves definiert ist. Sie können möglicherweise auch eine Adresse eines Slaves einstellen, aber normalerweise nicht viel. Dies hilft beim Adressieren von Konflikten, wenn zwei Slaves dieselbe Adresse teilen.


Hier ist ein Beispiel für ein Teil, mit dem ich erst kürzlich gearbeitet habe, es ist ein ADM1276-Hot-Swap-Controller. Es hält sich an die PMBUS-Spezifikationen, aber die I2C-Topologie gilt weiterhin. Es zeigt Ihnen die Interaktionen von Master und Slave, wenn Sie Bytes senden, empfangen, lesen und schreiben.

Geben Sie hier die Bildbeschreibung ein

Es gibt nichts im i2c-Protokoll, das dieses Problem löst. Sie können es zum Laufen bringen, aber Sie werden dafür eine Software verwenden. Da i2c für die Hardwarekommunikation entwickelt wurde, die normalerweise Register mit fester Größe umfasst, wurde nichts bereitgestellt, um Daten mit variabler Länge zu verarbeiten. Ich habe das selbst herausgefunden und musste das gleiche Problem lösen, das Sie in Betracht ziehen.

Da der Master alles kontrolliert, kann der Slave ihm nur Hinweise darauf geben, wie viele Daten er senden muss. Was für mich am besten funktioniert hat, ist, dass der Slave die Länge als erstes Byte sendet. Dann weiß der Master, wie viele Bytes er anfordern muss.

Das Protokoll selbst lässt eine solche Aktion nicht zu, aber es ist nichts, was nicht durch Programmierung gelöst werden kann.

Zwei mögliche Optionen möglicherweise:

  1. Dass der Lehrer zuerst einen Wert in diesem Integer-Fall (kleiner als 255) anfordert und dies die Größe der Daten ist, die Sie später beim nächsten Anruf senden, den Sie tätigen.

  2. Wenn Sie die maximale Länge der zu sendenden Daten kennen, nehmen Sie diese als Referenz, konvertieren Sie sie in ein Array oder eine Zeichenfolge und fügen Sie ein bestimmtes Zeichen hinzu, das Sie verwenden werden, um zu markieren, wo Ihre Daten enden und im Master Sie konvertieren wieder in den Datentyp, den Sie verwenden. Füllen Sie bei den kleinsten Daten den Rest der Zeichenfolge mit Ihrem Sonderzeichen aus und voila, Sie senden immer eine Zeichenfolge mit derselben Größe.