Multi-Controller-Projekt: Welcher Bus?

N'Abend zusammen,

ich mache mir gerade ein paar Gedanken zu einer Projektidee. Dabei werde ich wohl mehrere Controller-Boards einsetzen (eins für Sensoren, eins für Steuerungsaufgaben, einen Master, und mal sehen was noch so kommt...). Aus diversen Gründen (Timing, Übersichtlichkeit, etc.) möchte ich das gern getrennt halten.

Was mir noch fehlt ist der konzeptionelle Ansatz für den Bus zwischen den Controllern. I2C wollte ich ab dem jeweiligen Controller für die jeweiligen Aufgaben mit nutzen. Damit wäre der Standard-I2C-Bus an den jeweiligen Controllern weg. Alles an einen I2C-Bus will ich aus obigen Gründen nicht. Was also tun? Nen 2. I2C-Bus auf jedem Controller an anderen Pins implementieren? Oder ein ganz anderes Protokoll/Konzept?

Ich bräuchte da mal paar Denkanstöße....

LG Uwe

Schließe mich der Frage an :D

Hallo,

hab mit mehreren µC zusammen noch nichts gemacht. Aber paar Gedanken zur Frage sind vorhanden.

Der µC kann ja nicht wirklich mehrere Dinge zur gleichen Zeit erledigen. Deswegen macht es keinen Sinn unbedingt mehrere Busse zu verwenden. Er würde die dann auch nur im Wechsel nacheinander abarbeiten.

Ich würde vielleicht danach gehen wie weit weg die µC und Sensoren etc. voneinander arbeiten und liegen sollen. Für alle die eng zusammen stehen kannste ruhig I2C verwenden. Oder wenn paar IC’s SPI verwenden dann auch das. Für größere bauliche Abstände dann eher RS232/RS485 oder Ethernet oder WLAN …

Nur würde ich so wenig Busse wie möglich einsetzen, nur so viel wie nötig.

Zuerst mal wie weit sind die verschiedenen Controller voneinander entfernt? Wieviel Daten müssen verschickt werden? Grüße Uwe

Doc_Arduino:
Hallo,

hab mit mehreren µC zusammen noch nichts gemacht. Aber paar Gedanken zur Frage sind vorhanden.

Der µC kann ja nicht wirklich mehrere Dinge zur gleichen Zeit erledigen. Deswegen macht es keinen Sinn unbedingt mehrere Busse zu verwenden. Er würde die dann auch nur im Wechsel nacheinander abarbeiten.

Ich würde vielleicht danach gehen wie weit weg die µC und Sensoren etc. voneinander arbeiten und liegen sollen. Für alle die eng zusammen stehen kannste ruhig I2C verwenden. Oder wenn paar IC’s SPI verwenden dann auch das. Für größere bauliche Abstände dann eher RS232/RS485 oder Ethernet oder WLAN …

Nur würde ich so wenig Busse wie möglich einsetzen, nur so viel wie nötig.

Da wurde schon alles gesagt.

Doc_Arduino: Der µC kann ja nicht wirklich mehrere Dinge zur gleichen Zeit erledigen. Deswegen macht es keinen Sinn unbedingt mehrere Busse zu verwenden. Er würde die dann auch nur im Wechsel nacheinander abarbeiten.

Soweit klar. Es geht mir dabei auch mehr um Verteilung / Entflechtung von Aufgaben. Wie mache ich das dann aber logisch, z. Bsp. bei I2C. das ist ja Master-Slave-basiert. In meinem Konzept wären die einzelnen Controller jeweils Master für ihren Aufgabenbereich, gleichzeitig aber Slaves für die Kommunikation zum Hauptcontroller, der wiederum Master wäre. Elektrisch dürfte das an einem Bus nicht sauber funktionieren, oder?

Doc_Arduino: Ich würde vielleicht danach gehen wie weit weg die µC und Sensoren etc. voneinander arbeiten und liegen sollen. Für alle die eng zusammen stehen kannste ruhig I2C verwenden.

Momentan würde ich sagen max. 2 Meter. I2C wäre mir für alles schon die liebste Variante, aber siehe oben...

Doc_Arduino: Oder wenn paar IC's SPI verwenden dann auch das. Für größere bauliche Abstände dann eher RS232/RS485 oder Ethernet oder WLAN ...

Hm. LAN/WLAN wäre mir vom technischen Overhead her etwas viel, wobei das ggfs. durchaus noch gänge. RS232 ist ja eher Punkt-zu-Punkt und fällt damit eigentlich raus. RS485 könnte gehen, muss ich mir mal näher ansehen.

Doc_Arduino: Nur würde ich so wenig Busse wie möglich einsetzen, nur so viel wie nötig.

[/quote]

Das sowieso.....

uwefed: Zuerst mal wie weit sind die verschiedenen Controller voneinander entfernt?

Max. 2 Meter.

uwefed: Wieviel Daten müssen verschickt werden?

Schwer zu sagen. Im Wesentlichen Messwerte (Sensordaten) und Steuerwerte (Servos, Motorsteuerung).

Hallo,

mit 2m fällt I2C flach.

Controller_1 >> Controller_2 || Controller_2 >> Sensoren etc. Master Slave || Master Slave

sollte kein Problem sein, Problem könnte es werden wenn Controller 1 und Controller 2 sich als Master und Slave abwechseln sollen, soll auch funktionieren, wird aber schwieriger. In deinem Fall spricht jeder Controller ganz gezielt seine Slaves an. Dabei kehrt sich nichts um. Was ich nicht weis ist, was passiert, wenn Controller 2 mit seinen Sensoren kommuniziert und Controller 1 gleichzeitig von ihm etwas will. Normalerweise merkt er das der Bus gerade besetzt ist, wartet und muß es nochmal versuchen. Muß man bestimmt im Code lösen.

RS485 wurde für größere Entfernungen konzipiert. Als Leitung würde ich einfaches CAT5/CAT6 Netzwerkkabel verwenden. Da sind die Adern auch schon paarweise verdrillt und geschirmt. Arbeit ja auch mit Differenzpegeln, wenn du die genauso wie gedacht, also nicht wahllos, anklemmst, haste schon einmal einen saubere Vernetzung.

Doc_Arduino: Hallo,

mit 2m fällt I2C flach.

Was nicht ganz stimmt. Es gibt Portexpander (P82B517). Damit geht es deutlich weiter.

Was ich nicht weis ist, was passiert, wenn Controller 2 mit seinen Sensoren kommuniziert und Controller 1 gleichzeitig von ihm etwas will. Normalerweise merkt er das der Bus gerade besetzt ist, wartet und muß es nochmal versuchen. Muß man bestimmt im Code lösen.

Das macht das Businterface automatisch. Aber: Gerade die AVR neigen im Multimaster Betrieb zu Deadlocks.

HotSystems: Was nicht ganz stimmt. Es gibt Portexpander (P82B517). Damit geht es deutlich weiter.

Es ist ein Port extender und heißt P82B715. Den braucht es dann an allen längeren I2C Strecken aber nicht mehrer in Reihe!

im Sinn: Master - Kabel kurz - Slave - Kabel kurz - Slave- P82B715 - Kabel lang - P82B715 - Kabel kurz - Slave - Kabel kurz - Slave

es geht auch : Master - P82B715 - Kabel lang - P82B715 - Kabel kurz - Slave - Kabel kurz - Slave - Kabel lang - P82B715 - Kabel kurz - Slave - Kabel kurz - Slave

Grüße Uwe

uwefed: Es ist ein Port extender und heißt P82B715. Den braucht es dann an allen längeren I2C Strecken aber nicht mehrer in Reihe!

Ja, Sorry...Tippfehler. Danke für die Berichtigung.

Hier noch eine einfache Bauanleitung.

Danke, ich werde mal in Ruhe über das Ganze nachdenken....

vieledinge: In meinem Konzept wären die einzelnen Controller jeweils Master für ihren Aufgabenbereich, gleichzeitig aber Slaves für die Kommunikation zum Hauptcontroller, der wiederum Master wäre. Elektrisch dürfte das an einem Bus nicht sauber funktionieren, oder?

Es wurde schon geschrieben, das Wort "Bus" impliziert mehrere parallele Akteure, die durch das Protokoll vor Verwirrung geschützt werden. Hier im Forum wurde von mehreren Mastern (ich glaube drei) am selben Bus berichtet. Ob es zu Deadlocks kommt, hängt dann von der Qualität der Protokollimplementierung ab. Mehrere Master brauchen dann so wie die Slaves Adressen, um sich ansprechen zu können. Ein Bus bedeutet ein Adressraum.

Parallel zum I2C können noch Melde-/Interruptleitungen dazu genutzt werden, daß sich ein Slave-Controller beim Master-Controller meldet "Hallo, ich habe Daten!".

Hier im Forum wird auch der CAN-Bus als Kommunikationslösung erwähnt.