1 wire würde ich nicht machen.
Einen Controller als Master zu verwenden ist relativ einfach.
Einen Slave zu proggen dafür umso schwieriger, da dieser eine "einmalige" Seriennummer hat.
Mir würde da RS 485 in den Sinn kommen, oder je nach Anwendung auch CAN.
Es kommt halt auf die Menge der zu übertragenden Daten und die Art der Steuerung an.
Diese nanoleaf leuchten kenn ich gerade nicht.
Unbestritten... Einen Controller als Master zu verwenden ist relativ einfach ..
Vielleicht versteh ich da was falsch, aber ich sehe kein Problem, keine Schwierigkeit das in I²C zu machen. Mein Master im archie (im Bild R5 Master mit Softwareversion x76) startet I²C mit ner Abfrage ".. wer ist denn alles da ..?" über einen von mir begrenzten Adressbereich. Da melden sich die Slaves, entweder alle (die von Bedeutung sind). Im Beispiel hier: ArmRechts-Controller, KopfController, MotorController, ArmLinks-Controller und Cirp-Controller :.. Einen Slave zu proggen dafür umso schwieriger, da dieser eine "einmalige" Seriennummer hat ..
......Bild hier
oder es sind einige nicht verbunden, dann sieht die Meldung so aus für ArmRechts-Controller, KopfController und ArmLinks-Controller.
...... Bild hier
Im Master werden dann Flags gesetzt, mit denen die entsprechende Kommunikation ein- oder ausgeschaltet wird.
Gaaanz normales I²C-Verfahren, abgesehen davon, dass der Kabelbaum nen ziemlich guten Meter lang ist. Das Beispiel ist mit der identischen Hardware gezeigt, nur dass beim zweiten Bild der I²C-Anschluss von Motor- und CIRP-Controller gelöst war bevor archie - der Master - wieder gestartet wurde.
Ciao sagt der JoeamBerg
@Skorpio:
I2C halte ich auch grundsätzlich für kein Problem.
Aber wie lang darf oder muss denn die Verbindung zwishen den Masters und Slaves sein können?
Das wäre wichtig zu wissen.Zitat von HaWe
Aus Zeitmangel beschäftige ich mich gar nicht mit den ESP-Dingern, aber hat der ESP32 nicht auch CAN ?
Das ist von seiner Herkunft ja dafür gedacht im Auto dezentral Controller zu vernetzen. Es gibt auch Anwendungen in der Automation (CANopen) oder Schifffahrt (NMEA2000) oder auch für autonome Roboter und Drohnen:
https://uavcan.org/
Nur so eine Idee ...
CAN zu programmieren per C++ ist für Anfänger zu exotisch - das kennt keiner.
Die Arduino IDE ist auch das einzige, was ich für anfängertauglich halte.
Für ESP8266 habe ich auch noch keine Arduino CAN lib gesehen, auch wenn ESP8266 mit Arduino eingeschränkt anfängertauglich wäre,
andererseits für ESP32 mag es welche geben, aber den halte ich wiederum nicht für anfängertauglich, und dessen cores sind ja auch noch lange nicht ausgereift.
Allerdings kann vlt der Arduino Due auch CAN - aber trotzdem, CAN halte ich für zu exotisch.
I2C hingegen halte ich zwar für einfach und anfängertauglich (Arduino Wire lib mit allen möglichen Arduino MCUs), aber nur bei kurzen Entfernungen (vlt 2m insg. schätzungsweise) -
ansonsten ist ja WiFi das Standard-Netzprotokoll bei ESP8266:
Vorteil: der Server braucht die einzelnen Clients nicht zu kennen, die melden sich einfach bei einer festen IP Adresse an.
Die erlaubten Variablennamen müssten allerdings stattdessen zur Kommunikation vorher (z.B. per fester Liste) vordefiniert sein, um die übergebenen bzw. zurückgegebenen html-strings auf dem html-Server und den Clients auswerten zu können.
Geändert von HaWe (13.08.2018 um 19:01 Uhr)
Man kann auch I2C machen und nur die Physik von CAN nutzen, das ist das Prinzip hinter diesen Treiberchips, die I2C über große Distanzen ermöglichen.
Die Verkabelung von CAN und RS485 sind bis auf Details sehr ähnlich.
RS485 wurde ja oben schon genannt. Vorteil wäre es ist nur eine Variante einer seriellen Schnittstelle, Nachteil gegenüber CAN ist, dass es nicht damit umgehen kann, wenn mehrere Teilnehmer gleichzeitig anfangen zu reden. Ein Protokoll aus dem Beleuchtungsbereich, was RS485 nutzt, wäre DMX, dafür gibt es viel für Arduino & Co.
Bei der Aussage mit der einmaligen Seriennummer beim Slave war der 1 wire Bus gemeint.
CAN wäre für mich die erste Wahl, wenn alle Controller im prinzip Master sind die Ihre gewonnenen Daten auf den Bus legen, ohne den eigentlichen Empfänger zu kennen.
Kollisionserkennung ist bei CAN automatisch mit eingebaut. Priorisiert wird hierbei über die Nachrichten ID.
Die Daten werden im Prinzip vom Knoten der die Daten verarbeitet rausgefiltert.
Beispiel GPS: Ein GPS Empfänger legt seine Positionsdaten auf den Bus, wer diese Daten auswertet interessiert diesen Knoten erstmal nicht.
Es gibt zwar auch bei CAN call Aufrufe, bei denen Daten abgefordert werden können - Ist aber eigentlich nicht der übliche Standard.
Die Verkabelung sieht bei CAN und RS 485 ähnlich aus, das Protokoll ist aber ein gänzlich anderes.
Das DMX Protokoll ist eigentlich ein schlechtes Beispiel, da es hier nur einen Master gibt, der Daten sendet, aber keine empfängt ( simplex Betrieb ).
Das geht nur, wenn man von den Slaves keine Rückantwort braucht.
Bei Elektor haben die Leutz auch mal ein Hausbus System entwickelt.
Auf welcher Basis das läuft hab ich gerade nicht auf dem Schirm, dafür gäbe es aber fertige Librarys auch für AVR Controller - Kannst ja mal gucken.
Essenz:
Wenn es um ein Protokoll mit mehreren Mastern und mehreren auswertenden Knoten geht würde ich CAN verwenden.
Wenn es um ein reines Single Master Protokoll mit weniger als 32 Teilnehmern geht würde ich RS 485 vorziehen, oder wenn die Buslänge gering ist I²C.
SPI geht nur mit einem Master bei kurzen Verbindungen und relativ wenigen Slaves, ist dafür aber schnell.
1 wire halte ich für problematisch, weil das Timing beim Slave nicht ganz ohne ist, es fixe einmalige Adressen gibt und eigentlich keine mir bekannte Library für Slaves.
Geändert von wkrug (14.08.2018 um 06:52 Uhr)
das klningt aber alles nicht sehr anfängertauglich mit CAN und DMX.
Anfänger können kein Eclipse und kein AVRStudio sondern eher nur Arduino IDE/API mit Wire() (i2c), Serial() (UART) und maximal (!) WiFi mit ESP8266 und html (WiFiServer-Libs) mit vorgerfertigten Beispielcodes zum copy+pasten, aber das ist bereits das höchste der Gefühle.
Berechtigungen
Zitieren
Lesezeichen