I2C Soft und Hard in BASCOM

[slavezero]

Hallo,

ich möchte mehrere Mega8 an einen Mega2561 über I2C anschliesen. Der Mega2561 ist Master und die M8 werden über die Pins PortC.4 und C.5 (Hardware I2C) mit dem M2561 verbunden. Soweit alles ganz normal.
Nun möchte ich aber an jedem der M8 verschiedene Sensorern, RTC usw. auch an I2C anschliesen. BASCOM bietet dazu die Funktion (?) <shiftout>, <shiftin>.
Kann ich dazu jeden Port-Pin verwenden? z.B. PortB.6 und B.7 oder gibt es da Einschränkungen?

tschüß sz

[linux_80]

Hallo,

Shiftin/out ist aber nicht für I2C zu brauchen,
die ist eher als Ersatz für SPI gedacht.

Bzw. wenn Du das als 2. Schnittstelle verwenden willst, stört das den I2C nicht, sollte in der Zeit was bei I2C anstehen, muss dieser halt warten, bis zuende geshiftet wurde.

[slavezero]

Hi Linux,
erstmal danke für die schnelle Antwort.
Jetzt kommen meine 2 großen Aber:
1tens: wie kann ich das dann lösen?
bzw.
2tens: ich benutze <shiftout> schon einige Zeit um I2C an zu steuern. Auf die Idee brachte mich P. Küsters (http://www.display3000.com/) mit seiner Ansteuerung der "Handy" Displays. und das funkioniert sehr gut.
klar muss man nach dem senden (<shiftout>) auf empfangen (<shiftin>) umschalten, aber das muss ich bei jeder synchronen 2Draht Datenübertragung. oder übersehe ich was?

tschüß sz

[Vitis]

du kannst doch die I2C-Slaves auf einem Bus hintereinander hängen.
Wozu brauchste 2 TWI?

[slavezero]

Nur ganz grob: ich habe an verschiedenen Orten jeweils einen Temperatur-, Feuchte-, Druck- usw. Sensor; insgesamt an jedem Ort ca. 10 Stk. Alles I2C/ TWI. Deren Daten erfasse ich mit je einem Mega8. Diese Mega8 "entscheiden" jetzt was geschen soll: Regen on/off, Licht on/off usw. Und nur wenn "Probleme" auftreten oder es "Neuigkeiten" gibt unterhalten die sich mit einem Mega2561.

Für meine Anwendung macht es einfach Sinn, dezentrale Rechenknechte mit identischer Hard- u. Software mehrmals aufzubauen und denen in Form eines Mega2561 einen Master vor die Nase zu setzen. Das Bussystem der Prozessoren untereinander kann ich auch mit einem RS485 Bus lösen. Aber die Distanzen sind nicht so das ich es brauchen würde.

Meine Frage war eigentlich, ob ich für <shiftout, shiftin, shiftclock> jedes PortPin verwenden kann oder ob es Einschränkungen gibt.

[Murdoc_mm]

Hi,

ich muss zuerst sagen das ich mich mit I2C überhaupt nicht auskenne und nur ein paar Grundlagen gelesen habe. Also nur um sicherzugehen das ich dein Problem richtig verstanden habe: Alle Teilnehmer (Atmegas, Sensoren) hängen am gleichen Bus und würden sich gegenseitig stören wenn die einzelnen Stationen ihre Sensorwerte abfragen.

Wenn das soweit richtig ist dann lass doch die Atmegas (den 2561 und die 8ter) immer erst bevor sie ihre Werte auslesen oder überhaupt kommunizieren an alle eine Meldung schicken das sie jetzt den Bus besetzen (z.B. Meldung: Atmega8_Küche belegt Bus) und nachdem sie ihre Werte haben den Bus wieder freigeben (Atmega8_Küche gibt Bus frei). Wenn du alle yC zu einer Gruppe zusammenfasst und die Sensoren alle unterschiedliche Adressen haben sollte das doch funzen, oder?

Gruß

[TheHawk]

I2c unterstützt doch multimaster

[Vitis]

klar kann man sich n Multimasterprotokoll auf TWI zusammenzimmern, aber bei Entfernungen im x Meter Bereich und der Anzahl von Elementen würde ich das auch nicht machen, dann besser zwischen den verschiedenen Knoten Busleitungen und an die Sensoren dann separat. Die Leitungslänge und die Bustopologie spielen was die Übertragungsrate angeht da schon ne nicht zu vernachlässigende Rolle. Für die Kommunikation zwischen den Knoten favorisiere ich persönlich die 485 oder CAN - Buskoppler (kann man auch ohne CAN-Baustein verwenden) aber mit TWI bei niedriger Taktrate wird es vermutlich auch funktionieren. Wichtig halt, die Übertragungsrate moderat wählen. Und da kommt dann auch, das ist ja ganz praktisch die langsamere software TWI ins Spiel. Prinzipiell kannst Du auch einfach über Pin togglen und Pin auslesen die einzelnen Bits auf zwei beliebigen Pins Deines µC rausklackern und reinzwurbeln, das ist gar kein Problem.