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 :)
Wie soll sich der Slave beim Master melden? Slaves sind passiv!
Schau dir doch mal die Datenblätter der verwendeten Slaves an, dann hast du die Antwort.
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? Wo finde ich denn das in der Doku, damit ich dazu nachlesen kann?
>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?
>Wie soll der Master merken wenn 2 Slaves gleichzeitig den Bus >beim ACK auf 0 ziehen? Vielleicht, weil das Low lower ist? ;-)
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?
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¶mCriteria=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
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.
> Oder weiß nicht das er keine Ahnung hat.
Wer im Glashaus sitzt, .....
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.