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?
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.
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.
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.
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.
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.
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.
