Hotplug Mikrocontroller an I²C-Bus

[Tobias E. (m1k3y)]

Hallo zusammen,

Ich habe einen Anwendungsfall bei dem Mikrocontroller mit einem I²C-Bus 
kommunizieren. Dabei kann zu jedem Zeitpunkt ein Teilnehmer per Hotplug 
hinzugefügt oder entfernt werden.

Welche Fallstricke gibt es da?

Was bekannt ist: Es muss sichergestellt werden dass SDA und SCL 
verbunden/getrennt werden während GND und Vcc schon/noch verbunden sind.

Solange der hinzugefügte/entfernte Teilnehmer an der aktuellen 
Übertragung nicht beteiligt war oder keine Übertragung stattfindet 
dürfte dann nichts passieren. Liege ich da richtig?

Was kann passieren wenn ein Teilnehmer entfernt wird, der gerade an 
einer Übertragung beteiligt war (als Master oder Slave)? Und was kann 
man tun um dies zu verhindern?

Danke im voraus,
M1k3y

[Jonas G. (jstjst)]

Hallo,

Tobias E. schrieb:
> Es muss sichergestellt werden dass SDA und SCL verbunden/getrennt werden
> während GND und Vcc schon/noch verbunden sind.
Wäre ich mir noch nicht mal absolut sicher ob das zwingend nötig ist.

Tobias E. schrieb:
> Solange der hinzugefügte/entfernte Teilnehmer an der aktuellen
> Übertragung nicht beteiligt war oder keine Übertragung stattfindet
> dürfte dann nichts passieren. Liege ich da richtig?
Ja

Tobias E. schrieb:
> Was kann passieren wenn ein Teilnehmer entfernt wird, der gerade an
> einer Übertragung beteiligt war (als Master oder Slave)?
Sollte nicht weiter stören, die Übertragung bricht halt ab. Jedoch 
sollte in der Programmierung ein timeout drin sein sonst wartet das 
Programm ewig auf Daten.

Tobias E. schrieb:
> Und was kann man tun um dies zu verhindern?
Wenn die Teile entfernbar sind wird man es nur mit elektrisch 
verriegelten Steckverbindern verhindern können. Aber es sollte auch 
während einer Übertragung nichts schlimmeres passieren.

Gruß Jonas

[holger (Gast)]

>Ich habe einen Anwendungsfall bei dem Mikrocontroller mit einem I²C-Bus
>kommunizieren. Dabei kann zu jedem Zeitpunkt ein Teilnehmer per Hotplug
>hinzugefügt oder entfernt werden.

Dann hast du dir mit I2C den falschen Bus für deine Anwendung 
ausgesucht.

[Tobias E. (m1k3y)]

holger schrieb:
> Dann hast du dir mit I2C den falschen Bus für deine Anwendung
> ausgesucht.

Ich habe leider keine alternativen. Das Hotplugging ist noch mein 
kleinstes (und inzwischen einziges verbliebenes) Problem.

[Jonas G. (jstjst)]

holger schrieb:
>>Ich habe einen Anwendungsfall bei dem Mikrocontroller mit einem I²C-Bus
>>kommunizieren. Dabei kann zu jedem Zeitpunkt ein Teilnehmer per Hotplug
>>hinzugefügt oder entfernt werden.
>
> Dann hast du dir mit I2C den falschen Bus für deine Anwendung
> ausgesucht.

Wieso soll das nicht funktionieren?

[Sebastian S. (amateur)]

Wenn man z.B. in einen externen Speicher schreibt, von außen nicht 
sichtbar während man zieht, so kann alles Mögliche passieren.
Also von nix bis zur Zerstörung des aktuellen Datums. Dürfte auch 
interessant werden, wenn man sich die schnellen Blockmodi der einzelnen 
Speicher anschaut.
Ziehst Du den Master, so ist meist Ruhe im Puff. Was die, eventuell 
gefütterten Slaves dazu sagen ist etwas anderes. Eine vermasselte 
Ausgabe kann zwischen nix und einem Gau alles bewirken. Vor allem in 
Anbetracht der Tatsache, dass die Slaves alles glauben, was auf dem Bus 
passiert und keiner weiß, was genau während des Ziehens (elektrisch) 
passiert. Mir ist auf jeden Fall kein Slave bekannt, der 
Sicherungsmaßnahmen für diesen Fall beinhaltet.

Ich würde mir die Normalität: "Teilnehmer verschwindet" auf jeden Fall 
verkneifen.
Anders sieht es natürlich aus, wenn alle Teilnehmer dass, was sie zu 
hören bekommen, verifizieren.
Dazu reicht aber meist die Intelligenz nicht aus. Wiederum die Ausnahme: 
Alle Teilnehmer sind µPs. Die können dann natürlich jede Übertragung, 
indirekt, überprüfen.

[spess53 (Gast)]

Hi

Was sagt Gurgel zu 'hotplugging i2c'?

MfG Spess

[Tobias E. (m1k3y)]

OK, Ich habe vergessen zu erwähnen, dass ALLE Teilnehmer Mikrocontroller 
sind und somit die entsprechende Logik kein Problem wird. Zudem sind 
alle Teilnehmer außer einem Hotplug-fähig und alle können zum Master 
werden.

Meine Frage zielt speziell auf Situationen ab, die den Bus blockieren 
könnten.

[Marc V. (Firma: Vescomp) (logarithmus)]

Tobias E. schrieb:
> Solange der hinzugefügte/entfernte Teilnehmer an der aktuellen
> Übertragung nicht beteiligt war oder keine Übertragung stattfindet
> dürfte dann nichts passieren. Liege ich da richtig?

 Wenn man sicherstellt, dass zuerst GND verbunden wird, liegst du
 da richtig. Der neue Teilnehmer muss aber als Slave initialisiert
 sein.
 Um den Bus zu verwalten, bzw. zu wissen ob neue Teilnehmer
 dazugekommen sind, muss ein und nur ein Master sowie ein geeignetes
 Protokoll vorhanden sein. Der Master kann z.B. jede Sekunde den Bus
 auf neue Teilnehmer abfragen.
 Neue Teilnehmer können sich z.B. mit Adresse 0xEF melden, nachdem der
 Master seine Abfrage auf diese Adresse rausgeschickt hat, melden die
 sich und kriegen vom Master eine neue Adresse zugewiesen. Von da an
 bis zum Reset behalten die diese Adresse.

Tobias E. schrieb:
> Was kann passieren wenn ein Teilnehmer entfernt wird, der gerade an
> einer Übertragung beteiligt war (als Master oder Slave)?
 Natürlich kann jeder Slave zum Master werden, ob das aber notwendig
 und sinnvoll ist - das ist die Frage.

> Und was kann man tun um dies zu verhindern?
 Nichts - deswegen kriegen die Slaven auch Adressen - wenn der Master
 auf diese Adresse ein NACK kriegt, ist der Slave nicht mehr da.
 Wenn auf ein Byte kein ACK kommt, ist der Slave auch nicht mehr da.

 Immer vorausgesetzt, dass deine Behauptung:
> Ich habe einen Anwendungsfall bei dem Mikrocontroller mit einem I²C-Bus
> kommunizieren.

 auch stimmt. Mit "dummen" ICs geht das nicht.

[Tobias E. (m1k3y)]

Marc V. schrieb:
> [...]

ungeschicktes Timing. Siehe mein Kommentar vor dir.

Eine Art DHCP ist vorgesehen.