mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik I2C Multimaster realisieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Pete (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von M. K. (mkn)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Oliver S. (oliverso)


Bewertung
1 lesenswert
nicht lesenswert
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

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Darum die Einschränkung auf AVR 2 Master.
> Da gibts die Sorgen noch nicht.

Woher du wissen?

Oliver

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Vilis (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Inn Seida (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Vilis schrieb:
> Da ich das weiß, hättest du dir deinen Beitrag sparen können.

Aber jetzt endlich wissen wir alle das Arduino Fanboy KA hat.

von skankhunt42 (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Inn Seida schrieb:
> Aber jetzt endlich wissen wir alle das Arduino Fanboy KA hat.

Er ist ein Arduino Fanboy das steckt doch schon im Namen ;)

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dieter R. (drei)


Bewertung
0 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von sebastians (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dieter R. (drei)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dieter R. (drei)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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
von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
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
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.