TWI per Plug an Play

Hallo,

Mein Ziel ist es, mehrere AVRs (alles ATmega16) zu vernetzen, wobei nur ein definierter unveränderlicher Master vorliegt, der an eine unbestimmte Anzahl Slaves (die wahlweise am Bus angesteckt werden können) Daten sendet. Um nicht jedes Mal einen Slave mit einer neuen Adresse festzulegen, besitzen alle Slaves die selbe Adresse und werden vom Master per GENERAL CALL angesprochen. Die Rückantwort der Slaves ist uninteressant, es interessieren nur die Transferdaten vom Master, die für alle Slaves identisch sind. Vom Prinzip her hatte ich auch schon eine erfolgreiche Kommunikation mit mehreren Slaves aufgebaut. Das Problem ist jedoch, dass durch das laufende An- und Abstecken der Teilnehmer (das leider in der Praxis vorkommen kann) sich der Bus manchmal aufhängt und nur wieder durch einen Hardware-Reset des Masters und aller Slaves eine neue Kommunikation stattfindet.
Softwaremäßig (WinAVR-gcc) habe ich schon viele Versuche unternohmmen, doch der Bus startet einfach nicht mehr.

Hat sich schon mal jemand mit diesem Problem auseinandergesetzt?


Nachtrag, betr. Hardware AVR:
------------------------------------
Ein übrigens sehr interessantes Phänomen habe ich beobachtet, wenn ich von einem Slave den Versorgungs-Minus abklemme (U+ und die beiden TWI-Leitungen sind noch angeklemmt). In diesem Falle holt sich der Slave den Minus über die beiden TWI-Leitungen der anderen Teilnehmer. Das Slaveboard - bestehend aus einem ATmega16 und einem Grafikdisplay mit Hintergrundbeleuchtung (zieht normalerweise um die 100mA) wird dabei mit einem "hochohmigen" Minus versorgt, sodass die Hintergrundbeleuchtung schwach leuchtet. Da aber die beiden TWI-Leitungen absolout nirgends nach Masse führen, können diese beiden Pins nur vom anderen Board nach Minus geschaltet werden. Ich finde das ziemlich bedenklich, fließt doch der Strom über den einen Versorgungsplus des Boardes 2 über die Displaybeleuchtung (bzw. auch über die komplette Last der Boardversorgung 2) zu den Portpins PC0 und PC1 des Boardes 1 und von hier endlich nach Masse. Die Atmegas können laut Spezifikation im Extremfall ca. max. 200mA für einen Pin bereit stellen - sowohl Sink als auch Source. Ob für den TWI-Betrieb eine interne Begrenzung vorgesehen ist, bezweifle ich. Also könnte man im ungünstigsten Fall durch die unsymmetrische Spannungsversorgung den Controller zerschießen.
Falls ich falsch liege, korrigiert mich bitte.


francesco

Ursache könnten Transienten sein, die beim An-/Abstecken der Boards auf den Leitungen auftreten, zB auf den Datenleitungen (SDA/SCL) oder auf VCC, alls die Board die gleiche Versorge haben wie das Masterboard.

Vielleicht kannst Du rausfunden, wo sich der Master aufhängt? ZB in einer I²C-Schleife/einem I²C-State, weil am Bus Bedingungen auftauchen, die nicht abgehandelt werden weil sie standardmässig nicht vorgesehen sind oder nicht I²C-konform sind.

Zudem sollten die Steckverbinder ähnlich ausgelegt werden wie Steckverbinder anderer Hot-Plug-Busse, wie zB USB (dort sind VCC/GND länger als D+ und D- und kontakten dadurch vorher, der µC ist schon in einem definierten zustand wenn D+/D- Kontakt bekommen).

Evtl helfen auch kleine Kondensatoren am Bus, so gefühlte 10-100pF?

Eventuell könnte man das Problem auch mit dem Watchdog lösen.
Der Master Controller hat einen Watchdog am laufen. Wenn der zuschlägt werden alle Slaves mit einer zusätzlichen Leitung resetet.
Das sollte das Sytem auf jeden Fall wieder zum laufen bringen.

gab es nicht eine möglichkeit den bus separat zu resetten? ich meine ich habe das im datasheet gelesen, aber funktioniert hatte es bei mir nicht, hab dem auch keinerlei bedeutung zugemessen als das ich mich witer damit beschäftigt hätte :p

francesco,

im Elektorheft 7-8/1998 wird auf Seite 79 eine galvanische Trennung zwischen I2C-Bus und -Teilnehmer vorgestellt. Damit lassen sich parasitäre Stromflüsse verhindern.

mare_crisium

Evtl TWI deaktivieren und dann wieder aktivieren (TWEN in TWCR).

Oder Fehlerbehandlung, etwa bei Status 0x00 (Bus error). Evtl denkt der Master bei Spikes auch, er hätte ne Arbitrierung verloren oder geht in den Slave-Mode?

Taucht das Problem nur auf, denn der Master am Senden ist?

Hier gibt's Hinweise zum "plug and play" mit dem I2C-Bus direkt von Philips

http://www.nxp.com/acrobat_download/.../AN10216_1.pdf

mare_crisium

Ich habe das TWI-Problem gelöst:

Durch Messungen habe ich herausgefunden, dass der SCL-Takt im Fehlerfall dauernd auf "1" bleibt. Masterseitig wartet das Programm auf das Bit TWINT { while (!(TWCR & (1<<TWINT))); // siehe Atmel Spec. }, das aber niemals mehr diesen Zustand erreicht.
Durch einen Watchdog { while ( (!(.....))) && !Watchdog) komme ich aus der Warteschleife wieder heraus und der Bus läuft auch wieder an.
Vielen Dank für eure Tipps.

francesco