Hey Leute ich hab mal ein paar Fragen zum Multimaster betrieb. Und zwar wie realisiert man sowas, dass es nicht zu einer Kollision im Bus kommt? Ich habe ein Master Atmega welcher von mehren Sensoren über I2C Daten abholten und Aktuatoren per SPI ansteuert. Nun soll ein PIC hinzu kommen welcher über eine HID Schnittstelle verfügt. Und Daten vom Atmega anfordern kann. Nun meine Frage wie realisiert man den Mulimaster Betrieb, muss dazu der Atmega noch zusätzlich als Slave konfiguriert werden? Und wie kann man sicherstellen das nicht beide Master zeit gleich auf den Bus zugreifen?
Multimaster Busssysteme sind immer ganz schick. Besonders wenn der Bus den man dafür vergewaltigt dafür nie vorgesehen war. Du kannst das genau so machen wie auf jedem anderen Bussystem. Mit allen Problemen die man dann schön zu Fuss lösen kann. Du kannst ein Token weiterreichen und nur der Besitzer des Tokens darf den Master spielen. Dann löse aber auch gleich das Problem eines 'verlorenen' Tokens, den irgendjemand muss den Bus dann aus der Erstarrung holen. Du kannst die Master einfach kollidieren lassen, die Kollision erkennen und eine zufällige Zeit vom Bus gehen um das dann nochmal zu versuchen. Und ein Stoßgebet senden das die Kollision nicht für irgendeinen Busteilnehmer scheinbar gültige Daten erzeugt hat. Aber wenn Du ganz gerissen bist, machst Du nix dergleichen. Polle den PIC einfach oft genug, ob der Daten haben will.
Pete schrieb: > Nun meine Frage wie realisiert man den Mulimaster Betrieb, muss dazu der > Atmega noch zusätzlich als Slave konfiguriert werden? Und wie kann man > sicherstellen das nicht beide Master zeit gleich auf den Bus zugreifen? Die Bus Arbitrierung wird von der TWI Einheit des ATMega abgehandelt. Bei 2 AVR Mastern kann gar nix passieren. Kollisionen werden zuverlässig erkannt Details: 22.8 Multi-master Systems and Arbitration http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf Bei mehr als zwei Mastern: Für den unwahrscheinliche Fall eines Deadlocks könntest du den WDT aktivieren. Zu PIC kann ich nichts sagen.
M. K. schrieb: > wenn der Bus den man dafür vergewaltigt dafür nie vorgesehen war. Natürlich ist der Bus prinzipiell Multimasterfähig. Und zwar wegen zweier Mechanismen: 1. alle Teilnehmer und somit auch die anderen potentiellen Busmaster müssen mithören, ob gerade eine Übertragung läuft. Falls ja: abwarten. 2. wenn zwei Master eine Übertragung beginnen, einer eine 1 sendet, aber eine 0 auf dem Bus sieht, bricht er seine Übertragung ab. Sieh https://www.i2c-bus.org/multimaster/ Im Prinzip also die selben Mechanismen wie beim CAN-Bus. Allerdings haben nur wenige Busmaster in µC die für 2. nötige Arbitrierungslogik eingebaut, die dann bei Verlust der Arbitrierung sofort vom Bus geht. Deshalb kann man damit nicht brauchbar einen Multimasterbus aufbauen. Es ist auch immer gut, die Spec des I²C zur Hand zu haben: https://www.nxp.com/docs/en/user-guide/UM10204.pdf Dort ab Kapitel 3.17.
Moin, Pete schrieb: > Und Daten vom Atmega anfordern kann. Das waere ja nicht nur Multimaster, sondern der eine Master muesste dann auch noch Slave des anderen Masters sein. Aber ich wuerde niemals sowas aufbauen, selbst wenn alle Specs Stein und Bein schwoeren, dass sowas nicht unmoeglich waere. Nimm ein 2. Interface zwischen den µControllern, getrennt vom Sensor-I2C Bus. Die 2..3 Pins extra sind den gesparten Aerger echt wert. Gruss WK
Arduino Fanboy D. schrieb: > Die Bus Arbitrierung wird von der TWI Einheit des ATMega abgehandelt. > Bei 2 AVR Mastern kann gar nix passieren. > Kollisionen werden zuverlässig erkannt In der Theorie schon. Leider ist die Atmel-Multimaster-TWI-Implementierung in den AVRs nicht fehlerfrei, und nicht stabil nutzbar. Ich würde es lassen. Oliver
Dergute W. schrieb: > sondern der eine Master muesste dann > auch noch Slave des anderen Masters sein. > > Aber ich wuerde niemals sowas aufbauen, Angst? Warum? Das tuts ohne jedes Problem. Oliver S. schrieb: > In der Theorie schon. Leider ist die > Atmel-Multimaster-TWI-Implementierung in den AVRs nicht fehlerfrei, und > nicht stabil nutzbar. > > Ich würde es lassen. Darum die Einschränkung auf AVR 2 Master. Da gibts die Sorgen noch nicht.
Arduino Fanboy D. schrieb: > Darum die Einschränkung auf AVR 2 Master. > Da gibts die Sorgen noch nicht. Woher du wissen? Oliver
Oliver S. schrieb: > Woher du wissen? Ein Büschel Arduinos am I2C Bus. Dauertest, Stresstest. Mit zunehmender Anzahl Master, zunehmend Kommunikationsversager, diese sind meist abfangbar, da Status auswertbar. 2 Master, immer abfangbar. Ab 3 und mehr Master, Neigung zur Totalblockade. Immer noch selten, muss man aber mit rechnen Warum, KA... (wohl Bug in TWI Einheit und/oder Wire Lib) Der TWI Status ändert sich nicht mehr. Als wenn die TWI Einheit stehen bleibt. Leider blockiert sie dabei manchmal(immer?) den Bus.
Arduino Fanboy D. schrieb: > Warum, KA... (wohl Bug in TWI Einheit und/oder Wire Lib) KA bedeutet keine Ahnung. Da ich das weiß, hättest du dir deinen Beitrag sparen können.
Arduino Fanboy D. schrieb: > Mit zunehmender Anzahl Master, zunehmend Kommunikationsversager, diese > sind meist abfangbar, da Status auswertbar. > > 2 Master, immer abfangbar. > > Ab 3 und mehr Master, Neigung zur Totalblockade. > Immer noch selten, muss man aber mit rechnen > > Warum, KA... (wohl Bug in TWI Einheit und/oder Wire Lib) > Der TWI Status ändert sich nicht mehr. > Als wenn die TWI Einheit stehen bleibt. > Leider blockiert sie dabei manchmal(immer?) den Bus. Arduino Fanboy D. schrieb: > Angst? > Warum? Noch Fragen, Kienzle? > Das tuts ohne jedes Problem. Janeee, is klaaa! SCNR, WK
Beitrag #6143796 wurde von einem Moderator gelöscht.
Beitrag #6143843 wurde von einem Moderator gelöscht.
I2C-Multimaster ist zwar theoretisch möglich und spezifiziert, nur macht man sich in der Praxis alles andere als Freude damit. Viele Systeme (Software wie Hardware) kommt damit erfahrungsgemäß nicht in allen Randfällen zurecht. Das führt dann in seltenen Fällen zu kompletten Busblockaden, die sich nur noch mit einem harten Reset lösen lassen. Nicht umsonst empfielt Philips/NXP in der I2C-Spec eine Resetleitung für alle I2C-Busteilnehmer vorzusehen.
Gerd E. schrieb: > Nicht umsonst empfielt Philips/NXP in der I2C-Spec eine Resetleitung für > alle I2C-Busteilnehmer vorzusehen. Das mag zwar hilfreich sein bei schlecht entwickelter Peripherie, steht so allerdings gar nicht in der Philips-Spezifikation.
Oliver S. schrieb: > In der Theorie schon. Leider ist die > Atmel-Multimaster-TWI-Implementierung in den AVRs nicht fehlerfrei, und > nicht stabil nutzbar. Das ist wo dokumentiert? Also: ja, es gab da mal ein Problem im TWI vor unvordenklichen Zeiten bei einigen wenigen ATMegas der ersten Generation. Ungefähr vor 15 Jahren wurde es behoben. Seitdem löppt das TWI hardwaremäßig, wie es sollte. Alle sonstigen Probleme in dieser Richtung sind reine Softwareprobleme. Ja, man muss schon wirklich programmieren können, um in einer Multimaster-Umgebung jederzeit alles korrekt zu tun...
c-hater schrieb: > Das ist wo dokumentiert? https://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html Kann sein dass diese Seite schon 15 Jahre alt ist. > Ungefähr vor 15 Jahren wurde es behoben. Frage zurück: Wo ist das dokumentiert? Und welche sind diese neuen ATMegas, die nicht zu den "wenigen ATMegas der ersten Generation" gehören? Sind es schon die mit einer 4 hintendran (ATMega16 -> ATMega164) oder meinst du XMega? Gibt es von Atmel Errata zu den "wenigen ATMegas der ersten Generation" oder muss man das halt so wissen?
Dieter R. schrieb: > Gerd E. schrieb: > >> Nicht umsonst empfielt Philips/NXP in der I2C-Spec eine Resetleitung für >> alle I2C-Busteilnehmer vorzusehen. > > Das mag zwar hilfreich sein bei schlecht entwickelter Peripherie, steht > so allerdings gar nicht in der Philips-Spezifikation. Nun, dann lies Dir mal folgenden Absatz aus der I2C-Spec durch. Die Alternative zur Resetleitung ist die Stromversorgung für die I2C-Geräte schaltbar zu machen: UM10204, Kapitel 3.1.16: > In the unlikely event where the clock (SCL) is stuck LOW, the > preferential procedure is to reset the bus using the HW reset signal if > your I2C devices have HW reset inputs. If the I2C devices do not have HW > reset inputs, cycle power to the devices to activate the mandatory > internal Power-On Reset (POR) circuit. Wenn man bedenkt daß bei vielen ICs die Datenleitungen keine Spannungslevel größer Vcc haben dürfen, ist das vom µC aus schaltbare Vcc kein realistisch gangbarer Weg denn dann bräuchtest Du Massen an 74er-Leitungstreibern. Das SCL-stuck-low ist leider wegen Clock-stretching und Multimaster ein reales Problem was man bei der Planung seiner Schaltung auf dem Radar haben sollte.
Gerd E. schrieb: >> In the unlikely event where the clock (SCL) is stuck LOW, the >> preferential procedure is to reset the bus using the HW reset signal if >> your I2C devices have HW reset inputs. If the I2C devices do not have HW >> reset inputs, cycle power to the devices to activate the mandatory >> internal Power-On Reset (POR) circuit. > > ... > > Das SCL-stuck-low ist leider wegen Clock-stretching und Multimaster ein > reales Problem was man bei der Planung seiner Schaltung auf dem Radar > haben sollte. Ich kenne den Absatz und ich bin mir sicher, ihn richtig verstanden zu haben. Da hast zwar recht, was deine Schlussfolgerungen aus unsauberer Implementierung angeht. Du hast aber unrecht, dass Philips ein solches Reset-Signal empfiehlt. Es wird nur die Situation beschrieben samt sämtlicher Krücken, mit denen man ein kaputtes System wieder zum Laufen bringt. "Preferential procedure" hat nichts mit "recommended signal" bezogen auf Reset zu tun. Ich traue mir schon zu, soweit über englisches Sprachverständnis zu verfügen. Was hilft, ist eine saubere Implementierung. Dann gibt es das Problem auch nicht.
Dieter R. schrieb: > Da hast zwar recht, was deine Schlussfolgerungen aus unsauberer > Implementierung angeht. Ich denke nicht daß Du das Problem mit einer saubereren Implementierung verhindern kannst, denn ist steckt im Konzept für I2C. Es können jederzeit einmalige/kurze Störimpulse von außen auf die Leitung kommen und im falschen Moment können die das auslösen. Die I2C-Spec sieht kein Konzept vor um das SCL-stuck-low-Problem ohne Reset/Vcc-off zu lösen. Das hätten die eigentlich bedenken müssen und dafür eine bessere Lösung finden sollen. Daß sie den Absatz mit reingenommen haben, zeigt ja klar daß die sich des Problems bewusst waren. Das hätten sie eigentlich sauber lösen sollen. Meiner Meinung nach hätten sie dafür gerne Multimaster und/oder Clock-Stretching über die Klinge springen lassen können. Aber dafür ist es nun zu spät und alle, die nicht nur Spielkram damit bauen wollen, haben den Salat. > Du hast aber unrecht, dass Philips ein solches > Reset-Signal empfiehlt. Es wird nur die Situation beschrieben samt > sämtlicher Krücken, mit denen man ein kaputtes System wieder zum Laufen > bringt. "Preferential procedure" hat nichts mit "recommended signal" > bezogen auf Reset zu tun. Indirekt schon. Denn Du kannst die "Preferential procedure" nicht ohne das Reset umsetzen. Und wenn man einen zuverlässigen Bus braucht, kommt man um das Thema SCL-stuck-low leider nicht rum.
Gerd E. schrieb: > Es können jederzeit einmalige/kurze Störimpulse von außen auf die Leitung kommen > und im falschen Moment können die das auslösen. Die I2C-Spec sieht kein > Konzept vor um das SCL-stuck-low-Problem ohne Reset/Vcc-off zu lösen. Wenn du davon überzeugt bist, dass die erwähnten Störimpulse bei ansonsten KORREKTER Protokoll-Implementierung zu einem Stuck-Low-Problem führen können, dann bitte ich darum, dies detailliert zu erklären - oder eine entsprechende Literaturstelle zu benennen. Es werden dann ja wohl auch schon andere festgestellt haben, nicht nur du. Ich kann dies nicht erkennen, und bloß mit dauernder Wiederholung ohne jeden Beleg wird es auch nicht richtig. StörIMPULSE führen eben gerade NICHT zu SCL-stuck-low. Deshalb ist es auch kein Konzeptproblem. Es ist niemand daran gehindert, bei seiner eigenen Implementierung Notanker in Form einer Reset-Leitung vorzusehen. Manche (wenige?) kommerzielle I2C-ICs haben es ja auch. Milliarden von Devices haben es nicht.
Ein vollständig und fehlerfrei implementiertes I2C ist per Spezifikation immer Multimasterfähig. Da braucht es keine Token, Resetleitungen oder ähnlichen Hassle. Bei Arbitrationsverlust schaltet der unterlegene Master automatisch in den Slavemode und der gewinnende Master sendet einfach weiter. Sehr gut hat das z.B mit den original Pillips MCs P80C652 der MCS-51 Familie funktioniert. Atmel hat bei den AVRs das I2C zwar weitgehend von Philips abgekupfert (ähnliche Registernamen, Bitnamen, Statusworte), aber nicht gründlich getestet. Daher ist es buggy und schwer zu benutzen: https://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html Pete schrieb: > Nun soll ein PIC hinzu kommen welcher über eine HID Schnittstelle > verfügt. Da mußt Du mal im Produktselektor schauen, welche PICs I2C-Multimaster unterstützen.
Arduino Fanboy D. schrieb: > Warum, KA... (wohl Bug in TWI Einheit und/oder Wire Lib) ist bekannt bei blockierenden I2C slave mit clockstretching Deswegen muss ja auch mit einem weiteren Port nicht blockierend die SCL Leitung gepollt werden ob sie mal wieder high wird. Notfalls muss der blockierende I2C Slave zurückgesetzt werden, dazu gibt es Init, irgendwie beide auf low oder high zu setzen, wenn das nicht hilft muss der Blockierte durch PoR power on reset zurückgesetzt werden also sein VCC mal kurz abgeschaltet werden. Lösbar ist ALLES aber der Aufwand, da lobe ich mir doch 422 & 485
:
Bearbeitet durch User
Joachim B. schrieb: > ist bekannt bei blockierenden I2C slave mit clockstretching Clockstretching stellt überhaupt kein Problem dar. Es stellt nur sicher, daß der Slave genügend Zeit hat, um in den I2C-Interrupt zu springen. Der Master muß auch nichts pollen, das macht die I2C-HW von alleine. Wenn die CPU aber mit anderen höher priorisierten Interrupts vollgeballert wird, dann ist das alleine die Schuld des Programmierers. Die Bugs des AVR-Masters sind unter anderem, Nichteinhalten der Pause zwischen Stop und Start, Nichterkennen eines Start eines anderen Masters während Stop, permanentes Takten des SCL ohne Daten.
:
Bearbeitet durch User
Peter D. schrieb: > Clockstretching stellt überhaupt kein Problem dar. Es stellt nur sicher, > daß der Slave genügend Zeit hat, um in den I2C-Interrupt zu springen. ist mir doch bekannt, warum wiederholst du das? (schlecht geschlafen?) Was ist wenn in einer Schleife auf SDL high gewartet wird? Wie soll der AVR da rauskommen wenn es niemals high wird? Peter D. schrieb: > Der Master muß auch nichts pollen, das macht die I2C-HW von alleine. an welcher Stelle im AVR? https://www.mikrocontroller.net/articles/AVR_TWI Master Receiver Mode "Das TWI wartet nun solange, bis der Bus frei ist" und wie wird das erkannt? (erst Recht wenn der Slave abgestürzt ist?) Beitrag "Re: I²C Clock stretching" Du schreibst es doch selbst: Peter D. schrieb: > Wie schon gesagt, als Single-Master muß man nur die While-Schleife zum > SCL testen hinzufügen. > Und schon hat man die komplette standard konforme Funktion eines Single > I2C-Masters für Slaves mit Clock-Stretching. > Man könnte noch ein Timeout hinzufügen, falls der Slave mal hängt. Das > muß man beim HW-TWI des AVRs dann aber auch machen. Es ist auch bekannt das manche I2C Chips ohne Power zu trennen nicht wieder ansprechbar sind! Ich verstehe dich wirklich nicht mehr!
Ich schliesse mich dem Wunschdenken an, dass jeder I2C-Slave eigentlich einen RESET-Eingang haben sollte. Auch im Single Master Betrieb. Man stelle sich nur vor ein Gerät hat einen Reset-Taster oder ein Watchgog-Reset schlägt zu. Wenn zum Zeitpunkt eises RESETs ein Slave ausgelesen wird und der gerade die SDA-Leitung auf LOW treibt... A HIGH to LOW transition on the SDA line while SCL is HIGH defines a START condition. A LOW to HIGH transition on the SDA line while SCL is HIGH defines a STOP condition. Und nu? Was mach ich beim Neustart? Gegen ein LOW auf SDA komm ich nicht an. Solange händisch am SCL toggeln (LOW,HIGH) bis SDA auf HIGH geht und dann SDA auf LOW gefolgt von HIGH (START . STOP)? Funktioniert das immer ? Manche Mikrokontroller unterstützen nicht mal GPIO-Betrieb für SCL. Damit ich als Softie keine Bauchschmerzen vor einer I2C-Entwicklung bekomme sollte die Hardware etwa so was für jeden I2C-Slave haben. https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf Oder eine ganz eigene (schaltbare) I2C-POWER-Domain. PS: Hatte ich schon erwähnt dass ich I2C an sich hasse :)
:
Bearbeitet durch User
Meine Lösung: Beide Arduino I2C Master haben eine verbindende Leitung. Diese wird von beiden ATMegas mit INPUT_PULLUP auf HIGH gehalten. Bevor auf den I2C Bus zugriffen wird wird gecheckt ob die Leitung noch HIGH ist. Wenn ja wird der PIN der gemeinsamen Leitung auf OUTPUT und LOW gesetzt. Dann erfolgt die Master Abfrage am I2C Bus. Danach wird A4 und A5 (SDA, SCL) und die gemeinsame Leitung auf INPUT_PULLUP gesetzt. Wenn der andere IC merkt das die gemeinsame Leitung LOW ist wird der I2C Bus nicht abgefragt und die A4, A5 Pins bleiben auf INPUT_PULLUP. Dann müssen die alten Daten herhalten. Mit einem Slave funktioniert das.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.