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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 ...
Beitrag #5405551 wurde von einem Moderator gelöscht.
Hi, sogar im "USI"-TWI ist der String mit den NACK drin. (Muss wohl wichtig sein.) ciao gustav
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
> 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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.