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