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 :)
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.
> 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.
>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
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?
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.
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
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 ;)
>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.
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.
>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?
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.
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.
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
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.
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
>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?
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?
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....
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
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 ;)
> 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!
>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?
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.
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.
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.
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.
