MultiMaster I²C oder wie würdet Ihr das lösen?

Hemi · 13. Juli 2017

Hallo zusammen,

ich habe da ein Problem, wo ich nicht weiß, wie ich das lösen soll...

UseCase: Ein Bussystem mit mehreren Knoten, einer davon ist mein Modul. Das Modul ist ein Odroid-Board mit der Anbindung an dieses Bussystem. Der Transceiver spricht "nach Aussen" (also zum Host-Controller) I²C.

Das Problem: Das Bussystem setzt voraus, dass die Knoten, die sich auf dem Bus befinden, innerhalb einer gewissen Zeit nach dem Power-On oben und angemeldet sind... Der Busmaster hält die Knotenliste vor, deswegen ist die "nachträgliche" Anmeldung nicht drin. Hier ist es aber so, dass Odroid eine Weile zum Booten braucht... und somit diese Zeit verstreicht...

Meine Idee: Man nehme ein Atmega, Attiny, oder sonstwas und lasse den Transceiver von ihm hochfahren, das Anmelden erledigt und etc. Dann, wenn Odroid hochgefahren ist, übernimmt er die Steuerung vom Transceiver (Odroid meldet sich beim Atmega und sagt ihm, dass er ab jetzt off-line ist). Es wäre dann ein MultiMaster-System, bei dem nur ein Master aktiv ist...

Kann das funktionieren?

addi · 13. Juli 2017

Hmmm...
Müsste meiner meinung nach funktionieren.
Beide, odroid und atmega, besitzen die gleiche i2c addr.
Odroid aktiviert sein i2c erst dann, wenn atmega weg ist.
Die kominaktion zwischen beiden müsste ueber gpio oder seriell erfolgen
Addi

Hemi · 13. Juli 2017

Ja, so in etwa habe ich es mir auch gedacht.

Aber warum eine I²C-Adresse beim Master? Bzw. Master hat doch gar keine I²C-Adresse?

Odroid zieht ein Pin vom Mega hoch/runter, wenn er fertig gebootet hat.

addi · 13. Juli 2017

Ich las es so genaess deiner beschreibung..odroid ist teilnehmer am bus, der von einem anderen master kontrolliert wird, sprich busmaster
Addi

Hemi · 13. Juli 2017

Nein, eben nicht...

Master 1 = Odroid
Master 2 (während Odroid bootet) = Atmega

Slave 1: Transceiver

Master auf dem I²C hat keine Adresse, nur die Slaves haben eine, bzw. zwei.

Ist Odroid hochgefahren, signalisiert er es dem Atmega und Atmega geht "off-line".

addi · 13. Juli 2017

Hmmm,
Du schriebst busmaster haelt die knotenliste vor. Ok.
Wer bestimmt denn nun das timeout, wenn der master nicht da ist bzw. Wer arbeitet die liste der verfügbaren knoten ab?
Oder anders gefragt, wer hat die Intelligenz über das verhalten der teilnehmer?
Addi

Hemi · 13. Juli 2017

Busmaster im Bus wo sich der Transceiver befindet, nicht im I²C Bus... Dieser Bus ist uninteressant für den Fall, da ist eine komplett andere Logik dahinter..

So meine ich das:

LotadaC · 13. Juli 2017

Hemi schrieb:
Attiny, oder sonstwas und lasse den Transceiver von ihm hochfahren,

Es gibt mMn keinen klassischen Tiny mit Master-fähiger Hardware-I²C.
Natürlich läßt sich Master-I²C mit etwas Softwareunterstützung über das USI, oder komplett in Software umsetzen - der I²C-Bus verbindet nur den Transceiver mit dem AVR/Odroid, muß also keine Multi-Master-Arbitrierung unterstützen.
Wie siehts mit Clock-Stretching aus (macht der Transceiver das/muß der AVR das unterstützen)?
Als "Hochsprachler" sollte das für Dich ja kein Thema sein - da gibts sicher 'ne Bibliothek zu...

Die neuen XTinies hingegen besitzen ein echtes I²C, wenn beschaffbar wäre also der Tiny814 was für Dich.

Wenn ich Dich recht verstanden habe, soll der AVR (via I²C) nach einem Powerup den Transceiver initialisieren/scharfschalten, und dann die Klappe halten. Keine weiteren Aktionen. Du mußt aber sicherstellen, daß der Odriod solange (während er hochfährt) nichts auf den Bus macht.

Hemi schrieb:
Ist Odroid hochgefahren, signalisiert er es dem Atmega und Atmega geht "off-line".

Ich würde es also eher andersrum signalisieren:
PowerUp-> AVR initialisiert (über I²C) denTransceiver -> AVR schaltet sein I²C ab und die Beine Tristate -> AVR aktiviert "Transceiver Ready"-Signal an den Odroid und ist raus.

Hemi · 13. Juli 2017

Also insgesamt ist der Ablauf so:
-> Das "Bus-System" wird vom Bus-Master hochgefahren (das blaue Etwas auf der linken Seite des Bildes) Ist der Bus oben, hat man relativ wenig Zeit den Knoten anzumelden. Wieviel genau muss ich in der Spec schauen
-> Der Transceiver kriegt es mit, dass der Bus oben ist (über seine RX-Leitung) und aktivert die Spanungsversorgung des Moduls, somit wird also das Modul geweckt.
-> Der Atmega/Attiny (oder was auch immer) fährt schnell hoch und Odroid wird auch gestartet
-> Der Atmega ist oben und initialisiert die Register vom Transceiver, DeviceID, KnotenID, tralala ... über I²C. Odroid bootet noch
-> Odroid ist oben und übernimmt die Kontroller über I²C und redet mit dem Transceiver. Atmega schaltet sein I²C-Modul ab und hält ab jetzt die Klappe, bis zum nächsten PowerOn.

So in etwa habe ich es mir vorgestellt. Attiny war jetzt nur ein Beispiel, ich kenne sie gar nicht, nur die Megas.

LotadaC · 13. Juli 2017

Hemi schrieb:
-> Odroid ist oben und übernimmt die Kontroller über I²C

Wie gesagt, ich würde stattdessen den AVR melden lassen, daß er mit der Initialisierung fertig ist (was sicher bereits der Fall sein wird, bevor der Odroid aus den Puschen gekommen ist). Wenn der AVR fertig ist, gibt er den Bus frei und signalisiert das einfach. Der Odroid prüft (pro Forma) ob der AVR fertig ist, bevor er seine I²C schärft. Dazwischen idled der Bus mit seinen Pullups.

Hemi schrieb:
Attiny war jetzt nur ein Beispiel,

Schon klar, bei 'nem Rechenriesen sollte es gar keine Probleme geben das umzusetzen. Interessant wäre es, einen Zwerg zu verwenden. Das ganze schreit ja förmlich nach dem Tiny4/5/9/10 (ADC brauchst Du nicht, 512Bytes Flash sind bestimmt zu wenig->ATtiny9 ?).
Keine Ahnung, wie opulent SW-I²C umgesetzt wird, und wie komplex das Transceiver-Init wäre. Dafür hätteste dann den kleinsten, konventionell verlötbaren AVR.
(Du kannst Dich natürlich auch am Tiny20 versuchen, der hätte immerhin 2K Flash...)

Mich würde mal interessieren ob das geht, bzw wieviel C nur für für'n simplen SW-I²C Master (nur ein paar Bytes senden) braucht.

Hemi · 15. Juli 2017

LotadaC schrieb:
Wie gesagt, ich würde stattdessen den AVR melden lassen, daß er mit der Initialisierung fertig ist (was sicher bereits der Fall sein wird, bevor der Odroid aus den Puschen gekommen ist). Wenn der AVR fertig ist, gibt er den Bus frei und signalisiert das einfach. Der Odroid prüft (pro Forma) ob der AVR fertig ist, bevor er seine I²C schärft. Dazwischen idled der Bus mit seinen Pullups.

Der AVR braucht keine Sekunde um hochzufahren und das alles zu initialisieren, da ist der Odroid noch nicht mal im Bootloader

(mein Banana braucht ca 8 Sekunden zum Login-Prompt im Bash, das iMX6-Board etwas schneller).
Idle auf dem I²C ist nicht, der blaue Bus hat 25MBit, da fliegen oft genug Sachen vorbei, die wichtig sein könnten

LotadaC schrieb:
Schon klar, bei 'nem Rechenriesen sollte es gar keine Probleme geben das umzusetzen. Interessant wäre es, einen Zwerg zu verwenden. Das ganze schreit ja förmlich nach dem Tiny4/5/9/10 (ADC brauchst Du nicht, 512Bytes Flash sind bestimmt zu wenig->ATtiny9 ?).
Keine Ahnung, wie opulent SW-I²C umgesetzt wird, und wie komplex das Transceiver-Init wäre. Dafür hätteste dann den kleinsten, konventionell verlötbaren AVR.
(Du kannst Dich natürlich auch am Tiny20 versuchen, der hätte immerhin 2K Flash...)

Mich würde mal interessieren ob das geht, bzw wieviel C nur für für'n simplen SW-I²C Master (nur ein paar Bytes senden) braucht.

Glaub, da wird der Tiny20 gnadenlos überfordert sein mit seinen 128Byte SRAM.

Um den Transceiver hoch zu fahren und zu initialisieren, muss man rund 12 Nachrichten über I²C schicken, bevor es an die "Applikation" weiter geht, also ist schon einbisschen Geschäft. Ob SMD oder THT ist egal, der Transceiver ist ein TQFP44 mit 0,80mm Pitch.

LotadaC · 15. Juli 2017

Hemi schrieb:
Idle auf dem I²C ist nicht, der blaue Bus hat 25MBit, da fliegen oft genug Sachen vorbei, die wichtig sein könnten

??
Nach dem Init (und bevor der Odroid warm wird) gehen (vom "Blaubus") ggf Telegramme beim Transceiver ein, die der AVR solange handeln muß?
Soll er die vom Transceiver eventuell ("Grünbus") entgegennehmen/abholen - und dann wenn der Odroid oben ist wie an diesen weiterleiten...

Oder meintest Du, der Transceiver muß (auch nach dem Init) auf irgendwelche Blaubus-Telegramme reagieren - was der AVR machen muß, bis der Odriod oben ist (dann muß dieser dem AVR bescheidgeben, klar)

addi · 15. Juli 2017

Hmmmm..
EIne etwas andere ansicht, der avr (z.b atmega 1284 wegen sram) bleibt permanent als master drin und schleusst die nachrichten zum odroid bzw. Puffered sie.
Addi

Hemi · 16. Juli 2017

LotadaC schrieb:
Oder meintest Du, der Transceiver muß (auch nach dem Init) auf irgendwelche Blaubus-Telegramme reagieren - was der AVR machen muß, bis der Odriod oben ist (dann muß dieser dem AVR bescheidgeben, klar)

Genau das. Nachdem der Transceiver "oben" ist und sich beim Bus-Master angemeldet hat, geht auf dem Blaubus die Kommunikation ja weiter und hier soll AVR erstmal lauschen und ggf. antworten, bis Odroid ist oben ist.

addi schrieb:
Hmmmm..
EIne etwas andere ansicht, der avr (z.b atmega 1284 wegen sram) bleibt permanent als master drin und schleusst die nachrichten zum odroid bzw. Puffered sie.

Das packt er nicht dauerhaft, glaube ich. Die Buskommunikation ist zu aufwendig für den AVR.

Suche

Suche

MultiMaster I²C oder wie würdet Ihr das lösen?

Hemi

Aktives Mitglied

addi

Mitglied

Hemi

Aktives Mitglied

addi

Mitglied

Hemi

Aktives Mitglied

addi

Mitglied

Hemi

Aktives Mitglied

LotadaC

Sehr aktives Mitglied

Hemi

Aktives Mitglied

LotadaC

Sehr aktives Mitglied

Hemi

Aktives Mitglied

LotadaC

Sehr aktives Mitglied

addi

Mitglied

Hemi

Aktives Mitglied