RS-485 im VM

Beiträge
779
Du liegst genau richtig:)
Allerdings sind die Leitungen, die vom Knoten abgehen, eher kurz, die längste ist vom Heckknoten in der Hutze zum Rücklicht.
Vorne liegt alles beisammen, im Schaltkasten in der Mitte auch, und beim Tiller ebenfalls. Beim rechten Mittelknoten sind die Leitungen zur RGB Unterbodenbeleuchtung auch noch rel. lang, dafür blinkt und bremst die aber mit , da die die Services ja mitliest:D
 
Beiträge
180
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 !
 
Zuletzt bearbeitet:
Beiträge
180
Ok, ich mache mal einen Vorschlag für ein Protokoll. Es ist an @nikolauzi s Vorschlag angelehnt, sieht aber ein zusätzliches Byte vor, das den Knoten adressiert.

Obwohl ich finde, dass das Auto-Bauding ein interessantes Feature ist, lasse ich das Sync Byte erst einmal weg. Man kann es bei Bedarf jederzeit wieder hinzunehmen, ohne am restlichen Protokoll etwas zu ändern.

Damit bleibt eine Nachricht vier Bytes lang:

message.png

Nachdem der Primary eine Nachricht verschickt hat, wartet er die Antwort ab.

Die Antwort des Knotens enthält als Node ID die Adresse des Primaries (z.B. einfach 0x00). Anstelle des Service sendet er die Knoten ID. Das Option Byte enthält einen einfachen Status (Ok oder Fehlercode).

Hier als Beispiel die Nachricht an Knoten 3, die den Blinker Nr. 1 auf "An" setzt:


protocol-01.png
 

Anhänge

  • protocol-01.png
    protocol-01.png
    8,5 KB · Aufrufe: 5
  • protocol-01.png
    protocol-01.png
    5,8 KB · Aufrufe: 5
  • protocol-01.png
    protocol-01.png
    35,9 KB · Aufrufe: 5
  • protocol-02.png
    protocol-02.png
    21,7 KB · Aufrufe: 4
Zuletzt bearbeitet:
Beiträge
180
Timeout / Fehlerbehandlung:

Für die Antwort setzt der Primary ein kurzes Timeout. Dies sollte nicht mehr als die zehn-fache Nachrichtenlänge betragen. ¹
Die Knoten müssen immer sofort antworten. ² Kommt keine Antwort, kann der Primary die Nachricht noch ein - oder zweimal wiederholen.
Kommt dann immer noch keine Antwort, signalisiert der Primary den Ausfall des Knotens (per LED / Display).

Falls der Knoten mit einem Fehlercode antwortet, wird, abhängig vom Code, die Nachricht noch einmal gesendet (Checksumme etc.) oder das Problem wird ebenfalls angezeigt. Der Status des Knotens wird abgespeichert und der Knoten wird ggv. nicht mehr angesprochen.


¹Beispiel: Bei 115 KBaud beträgt die Nachrichtenlänge 4 x 8 / 115200 = 278 uS. Ein sinnvolles Timeout läge dann zwischen 1 ... 3 ms.

² Falls der Service zum Beispiel die Abfrage von Sensoren etc. beinhaltet, die länger als das Timeout dauern würde, wird mit einer Nachricht die Abfrage gestartet und mit einer weiteren Nachricht, nach angemessener Wartezeit, der Wert abgerufen.
 
Zuletzt bearbeitet:
Beiträge
180
Grau ist alle Theorie ... :whistle:

Wie groß ist denn nun der Schaltungsaufwand für einen Knoten ?

Um dafür ein Gefühl zu bekommen, habe ich mal eine beispielhafte Schaltung für einen Knoten mit drei Ausgängen entworfen.
Die Mosfets an den Ausgängen schaffen 4A, das müsste für die Lampen, Blinker, Hupen etc. eigentlich reichen.

Der verwendete uC von ST lässt sich entweder per Arduino IDE oder mit der STMCube IDE programmieren. Dies geschieht über den SWD Port.

Vorgesehen sind ausserdem zwei RS-485 Ports mit jeweils 4 Pins. Der Idee dabei ist, die Ports an gegenüberliegenden Seiten der Leiterplatte anzuordnen. Der Bus geht dann auf der einen Seite rein und auf der anderen wieder hinaus. Im einfachsten Fall als vierpolige Flachbandleitung.


node-a-sch.png
 
Zuletzt bearbeitet:
Beiträge
180
Ein paar Anmerkungen vielleicht noch zu den Bauteilen.

Die Transistoren kommen im SOT23 Gehäuse (2.9 x 1.5 x 1 mm). Die Ausgangstransitoren kosten bei Reichelt 21 Cent, die Treiber 7 Cent.
Der uC hat ein TSSOP20 Gehäuse (6.4 x 4.4 mm). Das ist gerade noch Hand-lötbar. Kosten z.B. bei JLCPCB < 70 Cent.
Der RS-485 Treiber, SP3485CN, kostet bei Reichelt 1,20 €, bei JLCPCB 40 Cent.

Man sieht, die Kosten halten sich in Grenzen, die benötigte Platinenfläche auch.

Wichtig im Velomobil ist immer die Leistungsaufnahme. (Denn wer will schon, dass ihm der schicke RS-485 Bus den Akku leersaugt ;) )
Wie hoch ist also der Leitungsbedarf eines Knotens ?

RS-485 Treiber, Controller und der 3.3V Festspannungsregler haben jeweils einen Ruhestrom von ca 1 mA. Damit kann man davon ausgehen, dass der Knoten weniger als 5 mA aufnimmt. Bei 10 Knoten sind das 50 mA. Der Linearregler macht daraus direkt 50 mA @ 12V.
Man müsste also mit einer Leistungsaufnahme von 600 mW rechnen. Der Steuerknoten kommt noch obendrauf, aber eine Leistungsaufnahme < 1 W erscheint schon realistisch.
 
Zuletzt bearbeitet:
Beiträge
779
Dann ev. einen HT7133 als Spannungsregler (Ruhestrom 10uA, der 1117 geht glaube ich nur bis 12V Input?) und den obigen MAXIM Treiber mit 100uA. Dann lohnt sich auch der Sleepmode beim Controller und das ganze könnte dauerversorgt werden (z.B. Hupe/Blinker für Alarmanlage). Noch eine z.B. 4A Polyfuse in die Versorgung der Lasten als Kurzschlußschutz, safety first;) Erhöht auch die Verfügbarbeit bei Kurzschluß in einem Knoten. 6/8 pin Stiftleiste zur Knotenkonfiguration per Jumper (3/4 bit) über interne Pullups, werden nach dem Startup/Auslesen abgeschaltet, spart dann auch Strom.
 
Beiträge
180
Dann ev. einen HT7133 als Spannungsregler (Ruhestrom 10uA, der 1117 geht glaube ich nur bis 12V Input?) und den obigen MAXIM Treiber mit 100uA. Dann lohnt sich auch der Sleepmode beim Controller und das ganze könnte dauerversorgt werden (z.B. Hupe/Blinker für Alarmanlage).
Der HT7133 ist an der Stelle auf jeden Fall besser geeignet, als der 1117, das werde ich anpassen. Beim Treiber hatte ich einfach mal den billigsten von Reichelt genommen ;). Da die alle Pin-kompatibel sind, ist hier der Austausch besonders unproblematisch.

Noch eine z.B. 4A Polyfuse in die Versorgung der Lasten als Kurzschlußschutz, safety first;) Erhöht auch die Verfügbarbeit bei Kurzschluß in einem Knoten.
Full Ack.

6/8 pin Stiftleiste zur Knotenkonfiguration per Jumper (3/4 bit) über interne Pullups, werden nach dem Startup/Auslesen abgeschaltet, spart dann auch Strom.

... lässt sich das vielleicht vermeiden ? Der Platz am Rand der Platine ist knapp, und Jumper sind ziemlich groß, auch im Vergleich zu den restlichen Bauteilen. Vielleicht kann man die Knoten über RS-485 einzeln konfigurieren, bevor man sie einbaut ?
 
Beiträge
180
Aktualisierter Schaltplan:
  • Linearregler gegen HT7133-2 ausgetauscht
  • Polyfuse eingefügt
  • ADM483 ARZ als RS-485 Treiber (ähnliche Eigenschaften wie MAX487, 3.3V, günstig bei Reichelt)
  • Terminierung entfernt
  • Debugfunktion über UART1 entfernt
  • UART2 -> UART1
UART1 als zusätzlicher Debug-Port ist eigentlich überflüssig, SWD ist ja vorhanden.
UART1 bietet mehr Optionen als UART2, z.B. kann er Autobauding. Daher treibt er jetzt den RS-485 Bus.

Für die Terminierung habe ich mir überlegt, dass man sie auch auf eine separate, kleine Platine auslagern könnte.
Diese liesse sich dann flexibel an den Anfang und ans Ende der Busleitung setzen. Daher habe ich sie aus der Schaltung entfernt.

node-a.png

Falls Ihr noch weitere Optimierungsvorschläge habt, immer gerne her damit.

Ansonsten mache ich in den nächsten Tagen mal ein (doppelseitiges) Layout der Schaltung.
 
Zuletzt bearbeitet:
Beiträge
779
Ev. noch 3 oder 4 kleine Lötbrücken nach GND vorsehen (0603) für die Codierung, falls das per SW nicht klappt. Oder hat der uC ev. eine interne Seriennummer? Damit ließe der sich identifizieren bei einem Netzwerkscan (autodetect).
 
Beiträge
180
Der uC hat momentan ja noch 9 freie Pins. Ich werde dann mal ein paar davon mit (unbestückten) 0603 Widerständen gegen GND terminieren.
Dann kann man diese entweder für die Adressierung nutzen oder z.B. auch weitere Ausgangsstufen etc. damit freifliegend verbinden.
 
Zuletzt bearbeitet:
Oben Unten