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.
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
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.htmlPete 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
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.
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 :)
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.
