Ok, also die Kabel zu den Komponenten sind an keiner Stelle besonders lang.
Aber jedenfalls sind die Knoten ziemlich auf die Gegebenheiten und Anforderungen in Deinem Velomobil zugeschnitten, denke ich mir.
Mir würden eher etwas allgemeinere Knoten vorschweben, die man flexibel miteinander kombinieren könnte. Ich erkläre am Schluss, wie ich darauf komme ...
Beispiel:
Ein Knoten, der drei Ausgänge schalten kann. Das wäre also im einfachsten Fall ein uC, der drei Mosfets in Open Drain Schaltung steuert. Da es kaum Mehraufwand ist, kann man PWM vorsehen, dann kann man die Ausgänge auch dimmen.
Damit könnte man einen
Kellermann Atto steuern und bei Bedarf einzelne Ausgänge runterdimmen.
Für einen weiteren Atto nimmt man einfach noch so einen Knoten.
Wegen des einfachen Aufbaus ließe sich der Knoten gut miniaturisieren. Ich glaube, dass man die reine Elektronik locker auf ca 2 cm² bekommen könnte, was wiederum den Einbau erleichtert. (Das setzt voraus, daß der uC in einem kleinen Gehäuse verfügbar ist.)
Für Rück/Bremsleuchten sowie Blinker im Heck kann man identische Knoten verwenden.
Wie spricht der Primary jetzt diese Knoten an, die ja alle identisch sind ? Damit die Knoten für den Primary unterscheidbar werden, brauchen sie eine eigene Knotenadresse, oder ?
Ich würde also die Knoten nach Typen sortieren. Der Knoten Typ "Schalter/Dimmer 3 Ausgänge" hätte die Basisadresse 0x3x.
Weitere verbaute Knoten dieses Typs erhielten aufsteigende Adressen : 0x30, 0x31, ...
Da kein Mensch in seinem Velomobil mehr als 8 Blinker braucht, wäre bei 0x37 Schluss. Danach wären Adressen frei für den nächsten Knotentyp.
Für die 8 verschiedenen Adressen reichen 3 Bits. Lötbrücken vielleicht, oder Adresse von aussen programmieren -> Flash
Wichtig ist, dass die Knoten aus Sicht des Primaries unterscheidbar sind. Dann lässt sich das System weitestgehend durch den Primary initial konfigurieren.
Konfiguration des Systems:
Also die Grundkonfiguration, die nur bei der ersten Inbetriebnahme durchgeführt wird, oder nachdem eine neuer Knoten hinzugefügt wurde.
Die Knoten haben einen Service, über den sie Auskunft über ihre Services geben. Der Primary sendet an alle erlaubten Knotenadressen eine Diagnosenachricht. Erhält er eine Antwort, fragt er die verfügbaren Services ab und legt diese in einer Liste ab.
Ein Ausschnitt aus dieser Liste würde z.B. so aussehen:
Blinker0 Knoten 30
Blinker1 Knoten 31
Blinker2 Knoten 32
...
Rücklicht0 Knoten 30
Rücklicht1 Knoten 31
...
RGB Output0 , Knoten 90
...
Mittels einer
Servicesoftware wird dann ein Mapping zwischen Funktion ("Blinken Links") und den Services hergestellt und im Master abgespeichert (Flash). Die Servicesoftware kann entweder auf einem Notebook laufen, das über einen RS-485 Dongle mit dem Netzwerk verbunden wird. Oder auf dem Master selbst, wenn dieser z.B. über ein TFT verfügt.
Wozu der ganze Aufwand ?
- Trennung von Verdrahtung und Konfiguration
- Das würde den Einbau der Elektrik vereinfachen, zum Beispiel in RO: Erst einbauen, dann per Diagnosesoftware konfigurieren
- Flexibilität: man baut die Komponenten ein, die man braucht, und kann sie alle problemlos einbinden
- Erweiterbarkeit: Ein zusätzlicher Knoten lässt sich jederzeit nachträglich einfügen, ohne, dass ein uC neu programmiert zu werden braucht
- Möglichkeit, Knoten(Module) verschiedener Hersteller miteinander zu kombinieren
P.S.: Ich habe mir auch überlegt, wie man die zusätzlichen Knotenadressen in Deine
@nikolauzi s 4-Byte Struktur hineinbekommt.
Eine Möglichkeit wäre, sie irgendwie in das Service-Byte mit einzubauen.
Eine andere Möglichkeit wäre, entweder nur Knotenadresse oder Service-Id zu übertragen, auf demselben Byte. Die Knotenadresse benötigt man streng genommen nur zur Initialisierung.
Oder man hijackt das Sync-Byte und verzichtet dafür auf die Baudratenanpassung.
Das war jetzt ziemlich viel, fürchte ich. Bitte gerne kommentieren !