Forum: Mikrocontroller und Digitale Elektronik Frage zum I²C Protkoll bezüglich NACK


von Stefan F. (Gast)


Lesenswert?

In dem Referenzhandbuch vom STM32F1 steht, dass der Master nach dem 
Empfang des letzten Bytes ein NACK senden muss, dann die STOP Bedingung.

Das habe ich aber so noch nie gemacht. Ich habe bisher immer so viele 
Bytes empfangen wie ich wollte und dann mit STOP beendet. Hatte damit 
bisher stets Erfolg.

Falls jemand Bilder dazu sehen möchte: Siehe 
Beitrag "STM3103RBT6 ist mein I²C Master mit CMSIS so korrekt?"

Habe ich es falsch gemacht, oder ist die Info von STM falsch?

von Cyblord -. (cyblord)


Lesenswert?

Stefanus F. schrieb:
> In dem Referenzhandbuch vom STM32F1 steht, dass der Master nach dem
> Empfang des letzten Bytes ein NACK senden muss, dann die STOP Bedingung.

Jeder Teilnehmer der gerade empfängt muss mit ACK oder NAK nach jedem 
Byte quittieren. Nach dem letzten sollte ein NAK kommen, weil er keine 
weiteren Bytes empfangen möchte. Nur ist das als Master nicht kritisch 
weil der die Kommunikation sowieso kontrolliert und jederzeit STOP 
senden kann.
Ein Slave kann das aber nicht und ist auf das NAK angewiesen.

Trotzdem muss auch der Master nach jedem empfangenen Byte ACK oder NAK 
senden auch nach dem letzten. Das einfach wegzulassen weil man es kann 
ich nicht so schön.

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

Ich habe natürlich immer jedes Byte mit ACK bestätigt, erst dann STOP 
gesendet.

Es ist also nicht Ok, auch das letzt Byte mit ACK zu bestätigen? Mir ist 
nicht klar, warum das den Slave stören sollte, er kann die STOP 
Bedingung doch trotzdem eindeutig erkennen.

Die Spezifikation sagt es klar, keine Frage. Ich würde nur gerne den 
Sinn dahinter kennen lernen.

von Cyblord -. (cyblord)


Lesenswert?

Stefanus F. schrieb:
> Ich habe natürlich immer jedes Byte mit ACK bestätigt, erst dann STOP
> gesendet.

> Die Spezifikation sagt es klar, keine Frage. Ich würde nur gerne den
> Sinn dahinter kennen lernen.

Keine Ahnung wie ich es noch weiter klar machen soll. Ein NAK zeigt dem 
Sender dass keine weiteren Bytes empfangen werden wollen. Warum soll man 
von diesem generellen Schema abweichen, nur weil der Master gerade 
empfängt und nicht ein Slave.

Du kannst bei einem Telefon auch einfach auflegen, dann weiß dein 
gegenüber dass du nicht mehr weiter reden willst. Aber eine 
Verabschiedung vorher ist trotzdem üblich.

> Es ist also nicht Ok, auch das letzt Byte mit ACK zu bestätigen?
Nach Spec nicht.

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

Mein Widerwille kommt daher, dass ich NAK mit "Nicht akzeptiert" 
assoziiere, was hier aber nicht der Fall ist.

Egal, ich hab's verstanden. Es muss ein NAK sein. Habe ich ja (in dem 
anderen Thread) ja auch so umgesetzt.

von Cyblord -. (cyblord)


Lesenswert?

Stefanus F. schrieb:
> Mein Widerwille kommt daher, dass ich NAK mit "Nicht akzeptiert"
> assoziiere, was hier aber nicht der Fall ist.

Das stimmt so aber nicht. Das NAK ist für einen Empfänger die einzige 
Möglichkeit den Sender mitzuteilen ob weitere Bytes empfangen werden 
sollen. Die I2C Spec sieht keine Möglichkeit vor, nach Empfang eines 
Bytes dessen Korrektheit zu bestätigen.

von Reiner_Gast (Gast)


Lesenswert?

Cyblord -. schrieb:
> Stefanus F. schrieb:
>> Mein Widerwille kommt daher, dass ich NAK mit "Nicht akzeptiert"
>> assoziiere, was hier aber nicht der Fall ist.
>
> Das stimmt so aber nicht. Das NAK ist für einen Empfänger die einzige
> Möglichkeit den Sender mitzuteilen ob weitere Bytes empfangen werden
> sollen. Die I2C Spec sieht keine Möglichkeit vor, nach Empfang eines
> Bytes dessen Korrektheit zu bestätigen.

Ich hatte schon den Fall, das ein I2C Client nur einmal am Bus 
geantwortet und Daten geliefert hat und danach scheinbar hängen 
geblieben ist.

Mir ist dann aufgefallen, dass ich nach dem letzten Byte kein NAK 
gesendet habe, sondern immer ein ACK. Kaum korrigiert, gab es mit dem 
Client auch keine Probleme mehr

von Cyblord -. (cyblord)


Lesenswert?

Reiner_Gast schrieb:
> Ich hatte schon den Fall, das ein I2C Client nur einmal am Bus
> geantwortet und Daten geliefert hat und danach scheinbar hängen
> geblieben ist.

I2C Client ist allerdings etwas irreführend. Es gibt Master und es gibt 
Slaves.
Davon kann jeder mal Sender oder Empfänger sein.

> Mir ist dann aufgefallen, dass ich nach dem letzten Byte kein NAK
> gesendet habe, sondern immer ein ACK. Kaum korrigiert, gab es mit dem
> Client auch keine Probleme mehr

Kaum macht man es richtig, geht es.

von Dumm Frager (Gast)


Angehängte Dateien:

Lesenswert?

Ich verstehe die Nomenklatur nicht ....

Wie kann man bitte aktiv ein Nichts senden?

Ich sehe in Datenblättern von (beispielsweise) EEPROMs keinerlei
Bezug auf das Kürzel NACK oder NAK was hier dauernd verwendet
wird.

Auch sehe ich keine Timing-Spezifikation die mir vorschreibt
dass ich nach einem letzten Datenbit einen Zeitschlitz von
einem Bit für ein nicht vorhandenes ACK vorsehen müsste wie
es das symbolische Ablauf-Diagramm vorzeigt. Also muss ich
doch eine Stop-Condition nach dem letzten Datenbit augeben
können ohne "jemanden zu beleidigen".

Nein, nochmal, wie kann man aktiv nichts senden?

Um die hier verwendete NAK-Nomenklatur zu hinterfragen: Wie
würdet ihr (die Verwender des Ausdrucks NAK/NACK) denn aktiv
und richtig ge-timed einen Chip-Select nicht auslösen?

von Stefan F. (Gast)


Lesenswert?

Es geht um das 9. Bit, mit dem der Empfänger eine Antwort an den Sender 
schickt:

High = NAK
Low = ACK

Man sendet für das NAK ein Bit mit High Pegel. Dass dazu physikalisch 
Open-Drain Ausgänge genutzt werden, ist dafür zweitrangig. Du musst hier 
zwischen der elektrischen Spezifikation und dem darüber liegenden 
Protokoll unterscheiden.

> Wie würdet ihr (die Verwender des Ausdrucks NAK/NACK) denn aktiv
> und richtig ge-timed einen Chip-Select nicht auslösen?

Das Timing gibt der Master durch die Taktleitung vor. Unabhängig davon, 
ob der Master oder der Slave ein NAK zu senden hat, muss das im 9. Takt 
eines Bytes passieren.

Im übrigen sind Dokumente von Atmel die Falsche Quelle für solche 
Fragen. Das Protokoll wurde von Philips/NXP spezifiziert.

von Peter D. (peda)


Lesenswert?

Stefanus F. schrieb:
> Ich habe bisher immer so viele
> Bytes empfangen wie ich wollte und dann mit STOP beendet. Hatte damit
> bisher stets Erfolg.

Dann hattest Du einfach Glück.
Wenn Du ein ACK sendest, legt im nächsten Takt der Slave das nächste 
Datenbit auf den Bus. Ist es 1, dann hast Du Glück und der Master kann 
Stop senden. Ist es aber 0, dann kann der Master kein Stop senden, da er 
dazu ja SDA auf high setzen muß, der Slave jedoch SDA auf low zieht.

von Michael R. (Firma: Brainit GmbH) (fisa)


Lesenswert?

Stefanus F. schrieb:
> Im übrigen sind Dokumente von Atmel die Falsche Quelle für solche
> Fragen. Das Protokoll wurde von Philips/NXP spezifiziert.

Jein. Philips/NXP hat I2C spezifiziert. Atmel hat TWI implementiert. 
Hintergrund waren wohl Patent-Streitigkeiten.

Nichtsdestotrotz stimme ich meinen Vorrednern zu: Es "gehört sich 
einfach", den Empfang des letzten Bytes mit NAK zu quittieren.

von Dumm Frager (Gast)


Lesenswert?

Stefanus F. schrieb:
> Es geht um das 9. Bit, mit dem der Empfänger eine Antwort an den Sender
> schickt:
>
> High = NAK
> Low = ACK

Du tust so als ob du einem Arduino-Anfänger das I2C-Protokoll
begreiflich machen willst. Dabei ist das gerade auch darin
enthalten was ich als Anhang mitgelifert habe.

Stefanus F. schrieb:
> Das Timing gibt der Master durch die Taktleitung vor. Unabhängig davon,
> ob der Master oder der Slave ein NAK zu senden hat, muss das im 9. Takt
> eines Bytes passieren.

Nochmal: es gibt keine Timing Spezifikation ein Nichts zu senden.

von Dumm Frager (Gast)


Lesenswert?

Stefanus F. schrieb:
> Im übrigen sind Dokumente von Atmel die Falsche Quelle für solche
> Fragen.

Das sollte wohl auch bedeuten dass ich auf keinen Fall ein Atmel-
Datenblatt verwenden sollte um nachzusehen ob ich ein Atmel-
EEMROM richtig bediene? Das ACK-Handling also für Atmel-EEPROMs
auch völlig anders ist als das Philips vorgesehen hat?

von Stefan F. (Gast)


Lesenswert?

> Wenn Du ein ACK sendest, legt im nächsten Takt der Slave das nächste
> Datenbit auf den Bus.

Jetzt habe ich geschnallt, super Erklärung! Irgendwie brauchte ich 
diesen Satz um das Offensichtliche zu erkennen.

> Das sollte wohl auch bedeuten dass ich auf keinen Fall ein Atmel-
> Datenblatt verwenden sollte um nachzusehen ob ich ein Atmel-
> EEMROM richtig bediene?

Auf diese alberne Schlussfolgerung gehe ich absichtlich nicht weiter 
ein. Bleibe bitte beim Thema oder mische Dich nicht ein.

von Dumm Frager (Gast)


Lesenswert?

Stefanus F. schrieb:
> Bleibe bitte beim Thema oder mische Dich nicht ein.

Ich bin sehr wohl beim Thema wenn ich frage wie man gezielt
ein NACK (NAK), also ein Nichts senden soll. Was muss ich
denn wann in ein Datenregister schreiben um ein NACK (NAK)
auszulösen?

Ich bin sehr wohl beim Thema wenn ich behaupte dass man ein
Nichts nicht senden kann.

von Cyblord -. (cyblord)


Lesenswert?

Dumm Frager schrieb:
> Ich bin sehr wohl beim Thema wenn ich frage wie man gezielt
> ein NACK (NAK), also ein Nichts senden soll.

Ein NAK ist nicht nichts. Deine Frage ist daher absolut unsinnig und ein 
ACK/NAK wird auch gar nicht "gesendet", sondern stellt einen Zustand der 
Datenleitung beim 9. Bit dar, welcher vom Empfänger verändert werden 
kann (low gezogen = ACK).

Und in deinem Anhang ist 9 . Bit = ACK Bit deutlich zu sehen. Ist es 
nicht low, entspricht dies einem NAK. Auch wenn NAK nicht in deinem 
Screenshot vorkommt.

: Bearbeitet durch User
von Reiner_Gast (Gast)


Lesenswert?

Dumm Frager schrieb:
> Auch sehe ich keine Timing-Spezifikation die mir vorschreibt
> dass ich nach einem letzten Datenbit einen Zeitschlitz von
> einem Bit für ein nicht vorhandenes ACK vorsehen müsste wie
> es das symbolische Ablauf-Diagramm vorzeigt. Also muss ich
> doch eine Stop-Condition nach dem letzten Datenbit augeben
> können ohne "jemanden zu beleidigen".
>
> Nein, nochmal, wie kann man aktiv nichts senden?
>

Ich empfehle dir hier mal einen Blick in die application note AVR315: 
http://ww1.microchip.com/downloads/en/AppNotes/00002480A.pdf

Dort steht ganz klar:

"All data packets transmitted on the TWI bus are 9 bits, consisting of 
one data byte and an acknowledge bit."

D.h. es müssen IMMER 9 Bits übertragen werden.

Und weiter:

"During a data transfer, the master generates the clock and the START 
and STOP conditions, while the receiver is responsible for acknowledging 
the reception. An Acknowledge (ACK) is signaled by the receiver pulling 
the SDA line low during the ninth SCL cycle. If the receiver leaves the 
SDA line high, a NACK is signaled."

D.h. das Protokoll gibt vor das der Empfänger das neunte Bit sendet.

> Um die hier verwendete NAK-Nomenklatur zu hinterfragen: Wie
> würdet ihr (die Verwender des Ausdrucks NAK/NACK) denn aktiv
> und richtig ge-timed einen Chip-Select nicht auslösen?


Gegenfrage: In welchem Zusammenhang siehst du denn bei I2C/TWI ein Chip 
Select?

von Bernd K. (prof7bit)


Lesenswert?

Dumm Frager schrieb:
> Ich sehe in Datenblättern von (beispielsweise) EEPROMs keinerlei
> Bezug auf das Kürzel NACK oder NAK was hier dauernd verwendet
> wird.

NACK meint umgangssprachlich das Gegenteil von ACK. Bei I2C ist das ein 
Bit an einer festen Position, ein Bit kennt genau zwei Zustände, wenn 
sein Zustand nicht ACK ist dann ist sein Zustand "nicht ACK", eine 
andere Möglichkeit gibts gar nicht. Zufrieden?

von Dumm Frager (Gast)


Lesenswert?

Bernd K. schrieb:
> Zufrieden?

Nein.

Dumm Frager schrieb:
> es gibt keine Timing Spezifikation ein Nichts zu senden.
----------------^^^^^^^^^^^^^^^^^^^^

Also es steht nirgends "gebe kein ACK aus warte danach eine
Zeiteinheit eines Bits"

Daher behaupte ich das man sofort nach dem letzten Bit eine
Stop-Condition ausgeben kann ohne das Nicht-ACK. Der Bit-Zyklus
des letzten Datenbits (7...0) ist ja schon durch.

Es gibt kein Nichts senden, jedenfalls nicht "by spec".

Ich glaube erst das Gegenteil wenn mir jemand vormisst dass
das Nichtsenden eines ACKs und dauffolgendem Warten einer
Bit-Zeit eine korrekte Funktionalität bringt die ohne Warten
nicht erfüllt wäre.

von Cyblord -. (cyblord)


Lesenswert?

Dumm Frager schrieb:
> Also es steht nirgends "gebe kein ACK aus warte danach eine
> Zeiteinheit eines Bits"
>
> Daher behaupte ich das man sofort nach dem letzten Bit eine
> Stop-Condition ausgeben kann ohne das Nicht-ACK. Der Bit-Zyklus
> des letzten Datenbits (7...0) ist ja schon durch.

Troll. Und tschüss

von Bernd K. (prof7bit)


Lesenswert?

Reiner_Gast schrieb:
> das ein I2C Client nur einmal am Bus
> geantwortet

Du bringst die Begriffe durcheinander.

Client -> Server
Master -> Slave
Kunde -> Pizzalieferservice

Links steht der der ansagt was gemacht wird. Rechts der ders macht.

Der Client ist der Master, der Kunde ist der König.

Der Server ist der Diener, der Slave ebenso. Wie der Name schon sagt. 
Und der Pizzabote liefert was ich bestelle, wann ich es bestelle und 
ansonsten hält er sich fern.

Der König befiehlt, der Untergebene gehorcht. der Master (Client) 
beliebt zu sprechen wann er will und der Slave (Server) hat jederzeit 
dienstbeflissen zu antworten, ansonsten hat er zu schweigen.

> Client nur einmal am Bus geantwortet

Von so einer Ungeheuerlichkeit daß ein Herr seinem Diener antworten 
sollte hab ich noch nie gehört, das wäre verdrehte Welt.

: Bearbeitet durch User
von Reiner_Gast (Gast)


Lesenswert?

Bernd K. schrieb:
> Reiner_Gast schrieb:
>> das ein I2C Client nur einmal am Bus
>> geantwortet
>
> Du bringst die Begriffe durcheinander.
>
> Client -> Server
> Master -> Slave
> Kunde -> Pizzalieferservice

Ja, ja... schon lange geklärt...

von Stefan F. (Gast)


Lesenswert?

> Also es steht nirgends "gebe kein ACK aus warte danach eine
> Zeiteinheit eines Bits"

Doch, und zwar das 9. Bit. Das hat einen genau definierte Position und 
es ist mandatorisch. Die Dauer des Bits legt der Master durch seinen 
Takt fest. Man kann nicht "nichts" als 9. Bit senden und man kann es 
auch nicht weglassen. Entweder ist die SDA Leitung zum Zeitpunkt des 9. 
Bits LOW oder HIGH. Die STOP Bedingung kommt erst nach dem 9. Bit.

Das wurde alles schon geschrieben.

Was höchstens noch fehlt ist, dass der Slave die Takte verlängern kann, 
wenn er will. Aber darum geht es gerade wohl nicht.

Um das 9. Bit zu überspringen müsste man erst eine Zeitmaschine 
erfinden.

von Dirk B. (Gast)


Lesenswert?

Bernd K. schrieb:
> Client -> Server
-> Kunde -> Pizzalieferservice-Konzern <-
> Master -> Slave
> Kunde -> Pizzalieferservice mit 2 Kunden
....so ungefähr und manchmal bis häufiger SCNR

von Bernd K. (prof7bit)


Lesenswert?

Dirk B. schrieb:
>> Kunde -> Pizzalieferservice mit 2 Kunden

Ja, Multi-Master-Systeme gibts auch. Ist ja auch vom Internet her 
bekannt: Ein Server und hunderttausende von Clients.

von Dirk B. (Gast)


Lesenswert?

Ein Slave von bspw. Google mit hundertausenden Mastern dürfte für einen 
Kunden eher mit Amazon und ein Server der dem einschalten einer 
heimischen Lampe dient eher mit dem kleinen Pizzadienst vergleichbar 
sein. Vom Prinzip haben Amazon/Pizzadienst bzw. Slave/Server  und 
Kunde/Kunde bzw. Master/Client jeweils die gleiche Rolle, aber 
Prinzipien haben manchmal Konnotationen ...

Beitrag #5405551 wurde von einem Moderator gelöscht.
von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

Hi,
sogar im "USI"-TWI ist der String mit den NACK drin.
(Muss wohl wichtig sein.)

ciao
gustav

von Bernd K. (prof7bit)


Lesenswert?

Dumm Frager schrieb:
> Es gibt kein Nichts senden, jedenfalls nicht "by spec".

Er soll auch nicht "nichts senden" sondern ein NACK-Bit.

> Daher behaupte ich

Es ist der Welt vollkommen egal was Du behauptest, der Standard sagt man 
soll ein NACK senden, alle tun das, alle Slaves verlassen sich drauf daß 
der Master das macht und wenn man es nicht tut funktioniert es nicht 
zuverlässig, manche Slaves hängen sich sogar auf bzw. erkennen das 
nächste Start nicht mehr wenn man an der Stelle ne 0 statt ner 1 sendet.

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

> manche Slaves hängen sich sogar auf

Das bringt mich auf eine andere Frage sich auch schon länger in meinem 
Kopf herum geistert:

Meine Geräte hängen sich bei Kommunikationsfehlern tatsächlich häufig 
auf. Ich muss dann einen Hardware-Reset machen, um diese Blockade zu 
lösen.

Ich habe hier öfters gelesen, das der Master diese Situation erkennen 
kann und dann mittels Freitakten oder Software-gesteuerten Reset 
Leitungen dagegen arbeiten kann.

Wie üblich ist dieser Aufwand in Consumer Elektronik? Bin ich ein 
außergewöhnlich schlechter Entwickler wenn ich sage "solche Störungen 
dürfen nicht auftreten, also baue ich auch keine Workarounds dagegen 
ein."?

von Dirk B. (Gast)


Lesenswert?

Vielleicht als Kompromiss noch nBrk,n0,n1,nErr,,...als Optionen 
definieren, um mehrere Möglichkeiten zu haben einmal kurz nichts tun und 
die Leitung nicht zu belasten.
Praktischerweise sind alle Varianten nichts von der Leitung zu verändern 
kompatibel mit der Standard NACK und wenn ein Slave nicht die 
Konzentration hat kurz zu warten, dann ist der erkennbar für den Master 
mit Wackelkontakt implementiert und unzuverlässig. So eine Übertragung 
kann dann sinnvollerweise als gescheitert klassifiziert werden sofern 
die Daten eine Relevanz haben

von Bernd K. (prof7bit)


Lesenswert?

Stefanus F. schrieb:
> Ich habe hier öfters gelesen, das der Master diese Situation erkennen
> kann und dann mittels Freitakten oder Software-gesteuerten Reset
> Leitungen dagegen arbeiten kann.

Ich hab das bei mir mal so gelöst daß mein I2C-Master-Treiber bei jedem 
Interrupt eine Timer-Variable setzt (sozusagen der Zeitpunkt der letzten 
Aktivität) und regelmäßig (systick) lass ich kurz nachschauen ob der Bus 
Idle ist und wenn nicht wie lange die letzte Aktivität zurück liegt und 
wenn das zu lange her war dann schalte ich die Master-Hardware aus, 
versuche den Bus freizutakten und initialisiere den Treiber und die 
Hardware wieder frisch, die gerade laufende Transaktion lass ich nach 
oben hin mit einen Fehler sofort enden.

Das hab ich mit absichtlichen Kurzschlüssen und Leitungsunterbrechungen 
und EMV Einstrahlungen auch mit Gewalt nicht dazu bringen können sich 
dauerhaft aufzuhängen. Man sieht zwar schön wie das Freitakten ab und zu 
ausgelöst wird aber es hat jedesmal Erfolg weil meine Slaves sich nicht 
aufhängen.

Nur wenn ein Slave auf der Taktleitung steht weil er in irgendeinem 
Deadlock hängt und nicht mehr mit dem Clock-Stretching aufhört dann ist 
der ganze Bus tot. Dagegen hilft evtl. noch ein Watchdog im Slave so daß 
er sich automatisch irgendwann selbst resettet, aber erfahrungsgemäß ist 
es ein Bug im Slave wenn so ein Deadlock überhaupt jemals geschehen 
kann. Testen, testen, testen, absichtlich stören auf jede erdenkliche 
Weise, Logic-Analyzer mitlaufen lassen und genau analysieren was in dem 
Moment passiert wenn es hängt.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.