Forum: Mikrocontroller und Digitale Elektronik dynamische Vergabe von TWI-Slave-Adressen


von M.B. (Gast)


Lesenswert?

Hallo,
ich habe einen TWI-Bus mit einer nicht definierten Anzahl von Slaves 
(Mega8). Das Problem dabei, ich will verhindern, dass Slave-Adressen 
doppelt vergeben werden.
Meine Überlegung ist nun, sobald ein neues Modul am Bus angekoppelt 
wird, meldet es sich am Master und dieser sucht aus einer Tabelle eine 
noch freie Slave-Adresse raus und teilt sie dem Slave mit. Der Slave 
schreibt diese Adresse ins EEProm, bootet neu und verwendet dann die 
neue Adresse.

Meine Frage dazu: Ist dieses Vorgehen sinnvoll und gibt es dazu fertige 
Konzepte? Gibt es evtl. einfachere/bessere/schönere Möglichkeiten, 
Slave-Adressen dynamisch zu vergeben?

Eine feste Vergabe von Slave-Adressen fällt aus, da mehrere identische 
Module am Bus betrieben werden, die unabhängig angesprochen werden 
müssen.

Danke schonmal für Anregungen, Kommentare und Hilfe :)

von Bastler (Gast)


Lesenswert?

Wie soll sich der Slave beim Master melden?
Slaves sind passiv!

von Bensch (Gast)


Lesenswert?

Schau dir doch mal die Datenblätter der verwendeten Slaves an, dann hast 
du die Antwort.

von M.B. (Gast)


Lesenswert?

Bastler schrieb:
> Wie soll sich der Slave beim Master melden?

Z.B. kann ich dem Slave bei der Grundprogrammierung eine feste Adresse 
vergeben, mit der er sich melden kann. Sobald er eine neue zugewiesen 
bekommt, wird diese im EEProm überschrieben und er hat eine neue. Ich 
verliere dadurch lediglich eine Slave-Adresse und kann damit nur noch 
127 Slaves anschliessen, was aber dicke reichen wird ;)

Zumindest ist das eine Möglichkeit, die ich nutzen kan, ob es bessere 
Möglichkeiten gibt, werde ich sehen.

von Bensch (Gast)


Lesenswert?

> Z.B. kann ich dem Slave bei der Grundprogrammierung eine feste Adresse
vergeben, mit der er sich melden kann. Sobald er eine neue zugewiesen
bekommt, wird diese im EEProm überschrieben und er hat eine neue.

Kannste machen, wenn du die ICs selbst herstellst....

Überleg dir mal Sinn und Zweck des I2C-Busses.

von Oliver (Gast)


Lesenswert?

>Z.B. kann ich dem Slave bei der Grundprogrammierung eine feste Adresse
>vergeben, mit der er sich melden kann.

Du kannst ihn höchstens dazu bringen, auf eine Message vom Master an 
diese Adresse zu reagieren. Aktiv melden kann sich ein Slave über TWI 
gar nicht. Das kann nur ein Master. Allerdings ist TWI ein 
Mulitmaster-Bus, und über General calls gibt es wohl eine Möglichkeit, 
wie sich ein weiterer Master  anmelden kann. Sobald der dann seinen neue 
Adresse bekommen hat, kann er ja zum Slave mutieren.

Alternativ könntest du eine zusätzliche "Meldeleitung" nutzen, über die 
ein Slave beim Master anklingeln kann, um eine Adresse anzufordern.

Oliver

von M.B. (Gast)


Lesenswert?

Bensch schrieb:
> Kannste machen, wenn du die ICs selbst herstellst....

Da es mein Projekt ist, gebe ich auch die Software vor, egal ob ich die 
programmiere oder eine Firma.

> Überleg dir mal Sinn und Zweck des I2C-Busses.

Um mehrere µC miteinander kommunizieren zu lassen. Kollidiert das 
irgendwie mit meinem Vorhaben oder wieso sollte ich mir nochmal extra 
Gedanken dazu machen?

von M.B. (Gast)


Lesenswert?

Oliver schrieb:
> Du kannst ihn höchstens dazu bringen, auf eine Message vom Master an
> diese Adresse zu reagieren.

Klar, hab mich nur falsch ausgedrückt. Beim ersten mal fragt der Master 
an, ob ein Slave mit der spezifischen Adresse existiert. Wenn ja, 
bekommt dieser eine neue Adresse und diese wird in der Tabelle 
eingetragen.
Der Slave fordert also auf Anfrage vom Master eine neue Adresse an.

von Frank B. (frank501)


Lesenswert?

M.B. schrieb:
> Der Slave fordert also auf Anfrage vom Master eine neue Adresse an.

Die korrekte Reihenfolge wäre so, das der Master den Bus auf eine 
bestimmte Adresse abklappert (z.B. 128) und wenn da ein Slave antwortet, 
der Master diesem die Neue Adresse zuweist.

Frank

von M.B. (Gast)


Lesenswert?

Wir können jetzt Erbsen über die Formulierung zählen oder uns dem 
eigentlichen Thema zuwenden. Mir wäre letzteres lieber.

Es geht mir vorrangig darum, ob dieses Konzept Sinn macht und/oder es 
bessere gibt die evtl. schon umgesetzt wurden. WIE ich das umsetze kann 
ich mir überlegen, wenn das primäre Problem gelöst ist ;)

von Heinz (Gast)


Lesenswert?

>Wir können jetzt Erbsen über die Formulierung zählen oder uns dem
>eigentlichen Thema zuwenden. Mir wäre letzteres lieber.

So lange Du nicht verstanden hast, wie I2C funktioniert, nützt das 
nichts.

von M.B. (Gast)


Lesenswert?

Heinz schrieb:
> So lange Du nicht verstanden hast, wie I2C funktioniert, nützt das
> nichts.

Erklär mir mal bitte, was ich daran nicht verstanden habe. Von deinen 
inhaltslosen Anspielungen kann ich mir nichts kaufen.

von Heinz (Gast)


Lesenswert?

>Erklär mir mal bitte, was ich daran nicht verstanden habe.

Beantworte mal diese Frage:
Wie stellt der Master fest, daß sich ein neuer Slave am Bus befindet?

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

Der Master merkt nicht, wenn Du ein Gerät an den Bus hängst. Dieses 
Gerät kann sich auch nicht so ohne weiteres beim Master melden.

Wenn mehrere Geräte mit der selben Adresse am Bus hängen, werden sie 
sich beim Antworten gegenseitig stören.

Du kannst aber ein neues und nicht initialisiertes Gerät mit einer 
immer gleichen Adresse (hier einfach "0" genannt) an den Bus hängen und 
dann eine Initialisierungsroutine startet. Diese scannt den Bus ab. 
Jedes angeschlossene Gerät muss nun reagieren und sich abfragen lassen.

Danach hat der Master eine Übersicht über die vorhandenen Adressen und 
kann nun einen Befehl an die Adresse "0" schicken, mit dem nun die neue 
Adresse gesetzt wird.

Im Multi-Master-Betrieb und wenn Du volle Kontrolle über Master und 
Slaves hast, könnte das eventuell auch das eigenständige Melden laufen. 
Jedoch darf der Master dann nicht die ganze Zeit den Bus beanspruchen, 
also öfter längere Pausen machen.

von M.B. (Gast)


Lesenswert?

Heinz schrieb:
> Wie stellt der Master fest, daß sich ein neuer Slave am Bus befindet?

Indem ich dem Master mitteile, er soll nach einem neuen Device suchen. 
Logischerweise bietet der Master diese Möglichkeit.
Du hast meine Frage aber noch nicht beantwortet, was ich am I2C nicht 
verstanden hab. Nur weil du neue Fragen stellst, wird deine Aussage 
nicht sinnvoller/klarer.

Christian H. schrieb:
> Du kannst aber ein neues und nicht initialisiertes Gerät mit einer
> immer gleichen Adresse (hier einfach "0" genannt) an den Bus hängen und
> dann eine Initialisierungsroutine startet.

So ist es gedacht. Ein Modul wird angesteckt, der Master vergibt die 
Slave-Adresse. Dann wird das nächste Modul angesteckt usw.
Da das Ganze nur einmal passiert, ist das kein Problem wegen des 
Zeitaufwandes. Ansonsten werden nur Module bei Defekt oder 
Softwareupdate getauscht, also nur einzelne. Somit vom Zeitaufwand auch 
kein Problem.

von Fabian B. (fabs)


Lesenswert?

Das kann so gehen.
Ich mache etwas ähnliches auf dem CAN-Bus, allerdings hat hier jedes 
Gerät selbst die Möglichkeit den "Configurier-Mich"-Zyklus anzustossen.

Du musst dann nur sicherstellen, dass zu einer Zeit nur ein 
unkonfiguriertes Gerät am Bus hängt.

Der Master muss dann nur eine Liste führen, welcher Slave (also welcher 
Typ) an welcher Adresse zu finden ist. Und du solltest eine Methodik 
einbauen um die aktualität dieser Liste zu prüfen, sonst gehen dir mit 
der Zeit die Adressen aus, wenn man wieder Knoten vom Netz genommen 
werden und damit eigentlich wieder welche frei wären. Ausserdem versucht 
der Master sonst u.U. unvorhandene Gegenstellen anzusprechen.

Gruß
Fabian

von M.B. (Gast)


Lesenswert?

Fabian B. schrieb:
> Und du solltest eine Methodik
> einbauen um die aktualität dieser Liste zu prüfen, sonst gehen dir mit
> der Zeit die Adressen aus, wenn man wieder Knoten vom Netz genommen
> werden und damit eigentlich wieder welche frei wären.

Ja, das hab ich eingeplant. Danke.

von Klaus (Gast)


Lesenswert?

Fabian B. schrieb:
> Ich mache etwas ähnliches auf dem CAN-Bus, allerdings hat hier jedes
> Gerät selbst die Möglichkeit den "Configurier-Mich"-Zyklus anzustossen.
>
> Du musst dann nur sicherstellen, dass zu einer Zeit nur ein
> unkonfiguriertes Gerät am Bus hängt.

Wenn die Geräte eine Seriennummer oder ähnliches haben (muss eindeutig 
identifizierbar sein) kann man dieses Problem auch umgehen und somit 
alle gleichzeitig aufschalten.

gruß klaus

von M.B. (Gast)


Lesenswert?

Der TWI-Bus lässt mehrere Slaves mit der gleiche Slave-Adresse zu?
Wo finde ich denn das in der Doku, damit ich dazu nachlesen kann?

von Tim (Gast)


Lesenswert?

>Der TWI-Bus lässt mehrere Slaves mit der gleiche Slave-Adresse zu?

Natürlich. Und solange der Master nur sendet, und die Slaves immer brav 
ACK sagen, merkt er das nicht ein mal.
Das TWI kann beim senden eine Kollision feststellen, aber nur wenn
2+ Master oder 2+ Slaves gleichzeitig unterschiedliche daten senden.

>Wo finde ich denn das in der Doku, damit ich dazu nachlesen kann?

Das ergibt sich doch aus dem Funktionsprinzip des TWI.
Wie soll der Master merken wenn 2 Slaves gleichzeitig den Bus
beim ACK auf 0 ziehen?

von Matthias L. (Gast)


Lesenswert?

>Wie soll der Master merken wenn 2 Slaves gleichzeitig den Bus
>beim ACK auf 0 ziehen?

Vielleicht, weil das Low lower ist?

;-)

von M.B. (Gast)


Lesenswert?

Tim schrieb:
> Wie soll der Master merken wenn 2 Slaves gleichzeitig den Bus
> beim ACK auf 0 ziehen?

Das ist soweit klar, aber da zwei Slaves wohl nie die gleichen Daten 
senden, dürfte das eine rein theoretische Möglichkeit sein, ausser man 
implementiert ein zusätzliches Protokoll, das zusätzlich zur 
Slaveadresse noch eine eindeutige ID nutzt. Der Master sendet also eine 
Slave-Adresse, mehrere Slaves reagieren drauf und lesen die Daten. 
Aufgrund dieser Daten weiss dann ein einzelner Slave, dass er gemeint 
ist.

In meinem Fall macht das aber IMO keinen Sinn, da der Master die 
eindeutige ID nicht kennt und somit keinen der Slaves explizit 
ansprechen kann. Oder hab ich da nen Denkfehler drin?

von Tim (Gast)


Lesenswert?

Habe mir das TWI nochmal angeschaut und festgestellt das es NUR beim 
senden als Master eine Kollision feststellen kann.
Es währe folgende Ablauf denkbar:

1. Die neuen Slaves werden Master und sagen "Bin neu hier, Ident NR: xxx
   (Seriennummer / echter Zufall)
   Dabei muss ein Master übrig bleiben, der rest stellt eine
   Kollision fest und hält die klappe.
2. Die Slaves schalten wieder in den Slave mode.
3. Master wählt alle Slaves an und sagt "der mit der Ident NR xxx
   bekommt die Adresse y"

Ohne Seriennummer wird das aber schlecht funktionieren....

Aber wenn du schon Steck Module hast, dann kodiere die Adressen doch
über die Steckplätze mit ein parr Pins....

Dann hat Modul im Steckplatz 2 immer die Adresse 2....

von avr (Gast)


Lesenswert?

Wenn man I²C richtig auslegt, also mit Pull-Up und die Leitungen
nur gegen GND zieht ist es gut machbar.

Es gibt einen "Master mit fester Adresse". Die Slaves habe beim Starten
noch keine Adresse.
Der Slave ohne Adresse testet, ob der Bus frei ist, macht sich zum
Master und fordert vom "Master mit Adresse" seine Adresse an.
Danach ist er als Slave erreichbar.

Die anderen Slaves warten halt bis der Bus für sie frei ist.
Das Warten sollte unterschiedlich (evtl. zufällig) sein, damit
jeder die Chance hat, den freien Bus zu erreichen.

Nach kurzer Startzeit haben sich alle beim "Master mit Adresse"
angemeldet, eine Adresse bekommen und das System ist einsatzbereit.

Ärger gibt es nur, wenn alle synchron Versuchen zu senden oder
ein Teilnehmer die Leitungen auf Ausgang mit HIGH schaltet
(lt. Spezifikation verboten, aber gerade bei Software-I²C
oft anzutreffen).

avr

von M.B. (Gast)


Lesenswert?

Tim schrieb:
> Aber wenn du schon Steck Module hast, dann kodiere die Adressen doch
> über die Steckplätze mit ein parr Pins....

Nein, keine Steckmodule sondern Module, die per I2C miteinander 
kommunizieren bzw. die Module kommunizieren mit dem Master.
Zwischen den Modulen liegen bis zu 3 Meter kabel ;)

von Bensch (Gast)


Lesenswert?

> Zwischen den Modulen liegen bis zu 3 Meter kabel ;)

Sowas hatte ich schon befürchtet...

Andere machen wegen 1m Kabel schon einen Affenzirkus- viel Spass!

von Matthias L. (Gast)


Lesenswert?

>Zwischen den Modulen liegen bis zu 3 Meter kabel ;)

Und da willst du allen Ernst I2C, also direkte Prozessorpins in der 
Gegend verlegen und Antenne spielen?

von avr (Gast)


Lesenswert?

I²C ist eigentlich für kurze Wege, also auf einer Leiterplatte
oder z.B. mehrere Platinen in einem 19" Gehäuse.
3 Meter ist ohne Treiber und mit mehreren Teilnehmern nicht
sinnvoll.
Entweder mit Treibern anfreunden:
http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=1651&uiTemplateId=NODE_STRY_PGE_T&paramCriteria=no

Oder z.B. RS485 etc. als Bus verwenden mit TXD und RXD.

http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=545&uiTemplateId=NODE_STRY_PGE_T

avr

von M.B. (Gast)


Lesenswert?

Dass die Leitungslänge Probleme machen könnte, hab ich gar nicht 
bedacht.
Hab zwar abgeschirmte Leitungen vorgesehen aber ich werde mir das 
Problem mal ansehen.

Welche Bus-Alternativen gibts denn sonst noch, die sinnvoll einsetzbar 
sind? Vorzugsweise natürlich ohne zusätzliche Hardware am AVR.
Singlemaster ist ausreichend, mindestens 50 Slaves.

Und nein, PICs, FPGAs o.ä. fällt aus, da ich aus verschiedenen Gründen 
bei AVRs bleiben will.

von Matthias L. (Gast)


Lesenswert?

Nimm Halbduplex RS485. (Heißt das dann RS422?)

Da gehört ein MAX485 oä Treiber dazu und fertig.

von Ulrich (Gast)


Lesenswert?

Ich habe jetzt nicht alles hier durchgelesen aber das was ich gelesen 
habe war teilweise ganz schön inkompetent. Wer keine Ahnung hat soll 
einfach die Klappe halten.

Ich habe sowas schon umgesetzt. Jedes Device hatte eine 16bit 
Seriennnummer im EPROM. Sobald es an den Bus gehängt wurde, hat es 
automatisch den "master" nach einer freien ID gefragt diese Übernommen 
und danach auf weitere Pollanfragen des Masters gewartet.

Das Device das die Verbindung aufbaut benötigt gar keine ID!!!!!!!! 
Deshalb kann der Slave ohne ID in den Master-mode gehen und den 
eigentlichen Master als Slave ansprechen(die Master I2C- ID muss 
natürlich bekannt sein.)

Dinge wie firmwareupgrade über den Bus usw. wurde alles mehr oder 
weniger Erfolgreich implementiert. Und die einzigste ID die festgelegt 
war, war die vom Master.

Wer das Gegenteil behauptet lügt!!! Oder weiß nicht das er keine Ahnung 
hat.

von Bensch (Gast)


Lesenswert?

> Oder weiß nicht das er keine Ahnung hat.

Wer im Glashaus sitzt, .....

von M.B. (Gast)


Lesenswert?

Matthias Lipinsky schrieb:
> Da gehört ein MAX485 oä Treiber dazu und fertig.

Ich hab noch ein paar SN75176 rumliegen, die sollten dafür gehen. 
Zumindest bei DMX512 leisten die gute Dienste. Ich werde es mal testen.

von M.B. (Gast)


Lesenswert?

Ich hab jetzt mein System auf RS485 umgestellt. Die Testsoftware läuft.
Die serielle ist auch leichter zu implementieren und per Softuart kann 
ich auch den Master an den PC hängen.

Danke an alle, die geholfen haben.

Bitte 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
Noch kein Account? Hier anmelden.