Software-Slave für I2C-Bus

[ZellRobi]

Kennt jemand eine Softwarelösung für einen I2C-Bus-Anschluß ?

Slave würde ausreichen.
Geht das überhaupt mit "normalen" Ports? Hier sehe ich Probleme mit den Taktraten und dem "gleichzeitigen" Lesen und Schreiben der Ports.

Den bestehenden Hardware-seitig unterstützten I2C-Bus möchte ich natürlich nicht verwenden.

Hintergrund: Die üblichen Controller haben lediglich einen I2C-Anschluß. Wenn man zwei realisiert, kann man "beliebige" Controller-Netzwerke zusammenstellen.

[cool-robotix]

Geht das überhaupt mit "normalen" Ports? Hier sehe ich Probleme mit den Taktraten und dem "gleichzeitigen" Lesen und Schreiben der Ports.

Ja, das geht auch mit "normalen" Ports, wobei man möglichst den Pin-Change Interrupt verwenden sollte. Gleichzeitig lesen und schreiben muss man nicht; d. Taktleitung (SCL) wird ja vom Master bereitgestellt und SDA wird entweder gelesen (Adresse oder SLA+W) ODER beschrieben (SLA+R) - vom Slave aus betrachtet. Schau mal in ein Atmel-Datenblatt, da ist die Kommunikation ziemlich gut beschrieben.

Mit der Fast-Mode (400 kHz) könntest du massive Geschwindigkeitsprobleme bekommen, zumindest ist mir dafür keine Software-TWI bekannt. 100 kHz sollten gehen.

Wie schnell soll es denn in der konkreten Anwendung sein?

[uwegw]

Wann immer möglich, würde ich den Slave als Hardware laufen lassen. Falls noch ein Master im selben µC gebraucht wird, den dann in Software. Der Master gibt das Timing vor, und der Slave muss sich danach richten. Daher ist der Master einfacher in SW umzusetzen.

Und worin soll eigentlich der Sinn von zwei separaten I2C-Anschlüssen liegen? Es ist ja eigentlich gerade der Witz an der Geschichte, dass man einfach sämtliche ICs parallel an einen Bus klemmen kann...

[Gock]

Dafür gibt es eine application note von Atmel:
www.atmel.com

[PicNick]

Schau mal, ob der Download dort funzt, wenn nicht, --> sprechen

Ist zwar für 2313, wurde aber auch schon auf anderen zum Laufen gebracht
https://www.roboternetz.de/wissen/in...ft-I2c_Library

[ZellRobi]

cool-robotix: "Wie schnell soll es denn in der konkreten Anwendung sein?"
Kommunikation kann eigentlich nie schnell genug gehen. Kann man als Slave nicht den Master "bremsen", wenn man den Takt (SCL) einfach unten hält ? Dann muss man auf den Interrupt nur schnell genug reagieren und SCL herunterzeihen, dann kann man sich intern auf das Ankommen der Daten vorbereiten und weiter geht es...

uwegw:"Wann immer möglich, würde ich den Slave als Hardware laufen lassen." Das muß ich mir mal durch die CPU gehen lassen ...

uwegw: "Und worin soll eigentlich der Sinn von zwei separaten I2C-Anschlüssen liegen"
Ich möchte Roboter bauen. Dann kann ich es mir nicht leisten, alles vollständig zu verstehen (Mechanik, Elektrik, Logik, Sensorik, ...).
Also möchte ich den Roboter aus vielen einzelnen Zellen zusammensetzen:
Eine Zelle für das Rad mit Motor: Zelltyp Radzelle
eine für den Drehkranz: Drehzelle oder Schanierzelle
eine Zelle für den Sensor x, eine für den Sensor y ,...
eine für die Logik, damit das einzelne sinnvoll zusammenwirken kann
oder wenn es komplizierter wird, dann nehme man halt zwei Logikzellen, oder drei, ...

Verstehst Du?
Wir müssen uns auf sinnvolle Schnittstelle einigen: Schnittstellen zwischen Zellen
Dann kann der, der von Mechanik etwas versteht, eine Radzelle entwerfen. Wir alle können Sie verwenden, denn sie passt zu den übrigen Zellen. Ein Anderer kümmert sich vielleicht um die gängigen Sensoren, ein Anderer um die Logik, eine Andere um Ein/Ausgabezellen, ...

Irgendwann haben wir einen Baukasten aus Zellen. Dann heißt es nur noch:
Man nehme 4 Radzellen, zwei Gelenkzellen, eine Stromversorgungszelle, die Sensorzellen, die Logikzelle, ...
Nun kann ich mich um das eigentliche Problem kümmern: Was sollte der Roboter denn nochmal können ??? Ach ja, das mache ich dann so ...

Wenn den ganzen Roboter ein einziger Bus durchzieht, kann das nicht mehr funktionieren. Controller sind so erfrischen billig geworden und so vielseitig, wir können für jede Zelle einen eigenen spendieren. Man verlagert Probleme in die Software, die ist aber viel flexiebler als Hardware. Dort kann man die Probleme eher lösen.

Also benötige ich für die Controller zwei Bus-Anschlüsse. Einer ist immer der Masteranschluß, der Andere der Slave-Anschluß. Nun verbinde ich einige der Zellen mit dem Master-Anschluß - gerade so, wie es die Aufgabe erfordert. Ich selbst bin Slave für einen Anderen... Mit zwei Bus-Anschlüssen je Controller ist die Welt nicht mehr so klein: Beliebige Netzstrukturen werden möglich...

cool-robotix, PicNick, Gock: Danke, da muß ich mich erst mal durchwühlen ...

[uwegw]

Gerade bei solchen modularen Systemen wäre es imho von Vorteil, wenn es nur einen gemeinsamen Bus gibt. So kann jeder Knoten mit allen anderen Kontakt aufnehmen. Und wenn man dann noch den I2C als Multimaster betreibt, sind alle Knoten quasi gleichberechtigt, und es gibt keine zentrale Steuerung, nach deren Ausfall nichts mehr geht. Also so, dass man einfach die Zellen zusammensteckt. Dann erkunden die einzelnen Controller, wer noch so mit ihnen am Bus hängt. Wenn allen die Topologie bekannt ist, wird evtl ein "Anführer" festgelegt, der das Gesamtverhalten vorgibt. Falls er plötzlich ausfällt, wird ein anderer Knoten zum Anführer.

Würde man den Bus in viele kleine Stücke teilen, die durch Controller getrennt sind, würde mit dem Ausfall eines Controllers der gesamte Bot ausfallen.

[ZellRobi]

Gerade bei solchen modularen Systemen wäre es imho von Vorteil, wenn es nur einen gemeinsamen Bus gibt. So kann jeder Knoten mit allen anderen Kontakt aufnehmen.

Ich befürchte nur, auf einem Bus ist das Gesamtsystem zu langsam. Wenn man die Möglichkeit zu Teilbussen hat, kann man die miteinander verbinden, die viel miteinander zu tun haben.
Die Anderen können sich über die Controller, d.h. in andere Teilnetze hinein unterhalten. Jeder Controller hat dazu ein Kommunikationsbetriebssystem, das die Übertragung sicherstellt. Also können doch alle miteinander ...

... nach deren Ausfall nichts mehr geht ...

Ausfallsicherheit kostet immer Redundanz. OK, wenn der Master auf einem Teilbus ausfällt, ist dieser Teilbus funktionsunfähig. Wenn Störungen auf dem Gesamtbus auftreten, ist auch der gesamte Roboter funktionsunfähig.

Die Frage ist doch, mit welchem Konzept ist man mehr auf der sichern Seite. Lösungen fallen einem immer wieder mal ein, für beide Konzepte.

Zum Glück können beide Ansätze mit der ZellIdee verwirklicht werden: Wer den einen Bus bevorzugt, verbindet halt alle Elemente an dem einen Bus. Immer grade so, wie es für die Anwendung am sinnvolsten ist.

[ZellRobi]

Dafür gibt es eine application note von Atmel:
www.atmel.com

Kannst Du mir genauer sagen wo?
Ich habe nur Software für Using the USI module as a I2C ... gefunden. Natürlich sehr Wertvoll, weil die Spezifikationen verwendbar sind. Kennst Du dort auch eine Softwarelösung für normale Ports?

[Gock]

Das ist ja krass!
ATMEL hat die Application Note AVR302 von der Homepage genommen!
Das hätte ich nicht gedacht. Der Titel war:
"AVR302: Software I2C™ Slave Implementation"
Es war in Assembler.
Vielleicht findest Du sie woanders im Netz oder nimmst das hier:
http://homepage.hispeed.ch/peterfleu...-software.html
Ist aber ein Master, den braucht man ja eher, aber vielleicht magst Du ihn umschreiben.
Auf älteren Atmel CDs dürfte sie noch drauf sein, vielleicht hab ich noch eine...