Microcontroller dynamisch vernetzen

[Skorpio]

Guten Tag,
Ich wollte mit einem Kollegen die nanoleaf leuchten nachbauen und das ganze am Ende als open Source anbieten.
Da das Projekt noch am Anfang steht, läuft gerade die „Grundlagen Forschung“. Als Master soll ein ESP Modul dienen (vllt 32 oder 8266 mal schauen)
Das Problem welches ich gerade habe ist die Vernetzung einer Unbekannten Anzahl von Controllern über eine steckverbindung am ESP. Es gibt die Überlegung das per 1-Wire Protokoll zu lösen. Aber da weis ich nach aktuellem Kenntnisstand noch nicht vor stabil diese Art der Kommunikation ist.
Eine einfache Art mehrere unbekannte Controller anzusteuern ist über die spi Schnittstelle darüber wäre auch relativ einfach möglich die Form der Panele abzubilden.
Es gibt ja noch I2C dort dürfte aber ein ähnliches Problem auftreten wie bei der seriellen Kommunikation die Controller wissen zum Start nicht wie der andere heißt und würden alle beim Call vom Master reagieren bzw. den ersten Namen der vergeben wird annehmen.
Gibt es noch eine 5. Möglichkeit die ich bisher übersehen hab?
Oder hat jemand schon Erfahrungen mit dem 1-Wire gemacht und eine Empfehlung welche Lib sich dafür gut eignet um darauf aufbauend ein eigenes Protokoll zu schrauben?

Mit freundlichen Grüßen
Skorpio

[Ceos]

Also mein Nachbar hat sich ja auch in die Dinger verliebt und ich begreif nicht wieviel Kohle man in solche Dinger stecken kann wenn ich sie zumindest in einer vereinfachten Form selber rbauen kann (Plexiglas Dreieck mit ein paar APA102 LEDs und dann mit CS-losem SPI einfach die Daten reinschaufeln und die Stecker zwischen den Panelen so auslegen dass man sie nicht verpolen kann)

Diese einfache Lösung hat antürlich keinen Rückkanal und auch keine Formerkennung, wäre aber zumidnest eine wesentlich billigere Lösung als die Nano Leafs

Du triggerst mich gerade relativ hart

Ich hätte da sogar eine Idee wie man das mit 5 Drähten und rekursiver Verschaltung lösen könnte, das wären dann allerdings 5 Pins pro Stecker

Der ESP32 hat Bluetooth onboard (aber das zum funktionieren zu bringen hat mich zumindest unglücklich gemacht) für den 8266 und 8285(8266 mit internem Flash) gibt es immerhin µPython, was einem unendliche Freiheit im Controller bietet (perfekt für OpenSource und außerdem super einfach zu programmieren)

Und man kann es sicher auch easy für NodeMCU oder andere bereits auf dem ESP verwirklichten "OS" porten, so kann man neben der eigentliche Lichtfunktion auch ganz easy weitere Funktionen in den Controller packen (mini webbrowser und ein AP, sodass man keine App braucht sondern nur nen Browser mit WLAN)

[Skorpio]

Genau das soll das Endziel sein. Wir versuchen in erster Linie eine Platform zu schaffen auf der sich Leute mit weit mehr Erfahrung im Bereich der Programmierung austoben können. Aber eine Lösung die soweit lauffähig ist das ein Anfänger das ganze aufbauen und in Betrieb nehmen kann.

Es werden dafür auch Platinen hergestellt und als LEDs sollen rgbw LEDs verwendet werden. Ob jetzt apa102 sk6812 oder ws2812 sei erstmal dahin gestellt.
Da es ja auch mal mehr können soll als einfach nur ne etwas intelligenterer led streifen. Wollten wir uns direkt zu Beginn mit der Frage auseinander setzen eine aktive Komunikation zwischen den Modulen aufzubauen. Dies hat den Vorteil das jederzeit neue Teile angehängt werden können ohne ständig die Basis zu ändern.

[Ceos]

ich hatte dir schonmal ein Bild zukommen lassen, siehe inbox

[wkrug]

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.

[oberallgeier]

.. Einen Controller als Master zu verwenden ist relativ einfach ..

Unbestritten.

.. Einen Slave zu proggen dafür umso schwieriger, da dieser eine "einmalige" Seriennummer hat ..

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 :

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

[HaWe]

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

[Skorpio]

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

Also da liegt ein Problem der Überlegung. Es können theoretisch je nach zu beleuchtenden Teil mehrere Meter sein.
CAN kenne ich persönlich nur aus dem S7 Datenblatt aber keine genauen Spezifikationen.
Dem RS485 schaue ich mir mal genauer.
Da ich aktuell mehr im Urlaub als am Rechner bin beschränken sich viel Überlegungen noch im Kopf.

Eine dieser Ideen läuft darauf hinaus das der Master nur die Anzahl kennt der angeschlossenen Module und dann über eine Leitung alle Daten seriel herausschießt. Und die einzelnen Module holen sich nur die Farbe ab.

Vielen Dank für die großartige Hilfe jetzt schon

[Ceos]

Eine dieser Ideen läuft darauf hinaus das der Master nur die Anzahl kennt der angeschlossenen Module und dann über eine Leitung alle Daten seriel herausschießt. Und die einzelnen Module holen sich nur die Farbe ab.

Das deckt aber keine Verzweigungen ab oder man müsste eine Rückleitung mit einbauen und die Stecker so bauen, dass wenn kein Modul angeschlossen ist, der Rückpfad mit dem Sende Pfad kurzgeschlossen wird ... so hätte man quasi alle Module in Reihe, trotz das sie wie ein Baum verzweigt sind (als Algo ausgedrückt Tiefensuche mit fester Entscheindungsrichtung)

Wenn am 1ten LED Modul Port 1 keiner angeschlossen ist, geht der Sendepin auf den Empfangspin und der geht zum Sendepin von Port2 usw. (evtl. könnte man hier noch ein Logik Gate mit Schmitttriggereingängen als Signalkonditionierer dazwischenschalten ... da wir nur senden und nicht empfangen geht das auch wunderbar für I2C ... mit einem Open Drain Ausgang am Gate ... und man muss sich nicht die Bohne um Reichweite kümmern)

Also wenns möglichst einfach und billig sein soll wäre das der Weg der Wahl, mit Richtungserkennung braucht man dann schon einen Controller pro LED Modul ... dann könnte man auch einzelne Kacheln unabhängig voneinander und Lastfrei für den Master Blinken lassen

dennoch würde ich schon alleine wegen der Aktualisierungsgeschwindigkeit und flüssiger komplexer ansteuerung auf ein schnelles serielles protokoll wie SPI (wegen synchroner clock) oder UART mit clock setzen (RS485 ist nichts weiter als differentielle signalübertragung um gleichtaktstörungen zu filtern) aber CAN halte ich schon allein wegen des Overhead für übertrieben

[wkrug]

Eine dieser Ideen läuft darauf hinaus das der Master nur die Anzahl kennt der angeschlossenen Module und dann über eine Leitung alle Daten seriel herausschießt. Und die einzelnen Module holen sich nur die Farbe ab.

Da man dafür keinen Rückkanal braucht und es sich um eine Beleuchtungsanwendung handelt ist das eindeutig eine Aufgabe für DMX 512, das hardwaremässig auf dem RS 485 Protokoll beruht.
Das ist der Quasi Standard für Theater Beleuchtungsanwendungen.
Das System kann ohne Repeater 32 Knoten ansprechen und 512 Kanäle verwalten.
Maximale Buslänge bis zu 1000m.
Im Standard sind 5polige XLR Stecker definiert, die aber fast niemand verwendet.
Üblicherweise werden 3polige XLR Stecker und Buchsen verwendet.
Die Adressierung der 512 Kanäle findet im Master statt, die angeschlossenen Geräte werden im einfachsten Fall per DIL Schalter auf eine Startadresse adressiert und können im Prinzip beliebig viele Kanäle haben.
Bei RGB Anwendungen sid das üblicherweise 6= Master Dim, Rot, Grün, Blau, Effekt, Speed ( Anordnung nach Hersteller unterschiedlich ) .
Es gibt für diesen Standard fast alles, was man Beleuchtungstechnisch so braucht ( Dimmerpacks, PAR Stahler, LED Bars, Profilscheinwerfer, ... ).
Das Protokoll ist einfach und im Prinzip mit jedem Microcontroller USART realisierbar.
PC Interfaces und PC Software sind auch verfügbar - Google mal nach DMX Control, das es kostenlos gibt und bei dem man auch Eigenbau Beleuchtungsgeräte definieren kann.
Interfaces gibt's sehr viele, wir verwenden das von Digital Enlightment ( Bausatz oder fertig ) sowie das von EURO Lite ( Fertiggerät ).
Früher hatten wir auch mal das von DMX4All.