RS-485 im VM

Mir ist aufgefallen, dass das vorgeschlagene Protokoll mit den 4-Byte Paketen schon Ähnlichkeiten mit Modbus hat, aber noch nicht bis zu Letzt definiert ist. Vielleicht könnte man es ja absichtlich so auslegen, dass es auch mit Modbus auf dem selben Bus parallel laufen kann, ohne dass sich die Geräte stören. Bei Modbus sind die kürzesten Datenpakete 8-Byte lang. Daher wären die Datenpakete schon mal grundsätzlich unterscheidbar. Das Ende eines Datenpakets wird (bei Modbus) durch eine Pause von der Dauer von mindestens 1,5 Byte Länge erkannt. Zwischen den Bytes innerhalb eines Datenpaketes dürfen also keine solchen Lücken sein. Der Slave darf dann frühestens mit der Antwort beginnen, wenn die Pause eine Länge entsprechend 3,5 Byte erreicht hat. Auch der Master darf ein weiteres Paket frühestens nach einer solchen 3,5-Byte-Pause senden.

Diese Zeitliche Paketerkennung kann auf Mikrocontrollern mit einem Timer und Interupts gemacht werden. Auf PCs ist das in der Regel nicht möglich, weshalb ein PC zwar als Master aber nicht als schneller Slave geeignet ist.

Mein Vorschlag wäre also die Paket Erkennungsregeln von Modbus zu übernehmen. Die alternative die mir sonst einfällt ist, einfach die Bytes bis 4 zu Zählen und dann auszuwerten. Aber dann kann das Problem auftreten, dass ein Slave aus der Synchonisation geraten kann, welches irgendwie gelöst werden müsste.
 
Zuletzt bearbeitet:
Was wäre Deiner Meinung nach der Vorteil, Modbus im Velomobil zu haben ?
Schwebt Dir dabei ein bestimmter Anwendungsfall vor ?

Ich hätte eigentlich am liebsten ein möglichst einfaches Protokoll ...
 
Zuletzt bearbeitet:
Gute Frage :unsure:. Modbus ist eines der Feldbuss Protokolle mit denen ich schon Erfahrungen gesammelt habe. Ich finde es ist relativ einfach zu verstehen, und viele Entwickler kennen es ohnehin schon. Dann ist es relativ effizient und mächtig. Es ist tolerant, gegenüber Erweiterungen, gegenüber unvollständigen Implementierungen, oder bedingt auch gegenüber anderen Protokollen, auf dem selben Bus. Bei möglichen Fällen, in denen das Minimalprotokoll nicht mehr ausreicht, z.B. Firmware update, könnte Modbus verwendet werden. Für die einfache Lichtsteuerung wird es jedoch nicht notwendig sein.
 
Immerhin gibt es für alle relevanten Plattformen (ESP32, STM32, Arduino, RPI, Linux, Win, Mac) frei verfügbare Implementierungen.
Die für den STM32 sieht garnicht so schlecht aus und würde wohl auch auf dieser Minimalhardware laufen.

Andererseits braucht man schon bei Modbus RTU 8 Bytes, um ne Lampe anzuschalten. Nicht besonders effektiv ...
Modbus ASCI, was eigentlich schöner wäre, weil einfacher per Konsole zu debuggen, ist noch ineffektiver.

Was möglicherweise interessant wäre, sind die schon (für schmales Geld) verfügbaren Hardwaremodule. (z.B. ebay, "Modbus" eingeben).
 
Ich habe gerade einen Blick in das Datenblatt des STM32G030F6P6 aus Deinem Minimalcontroller geworfen. Der lässt schon einiges an Möglichkeiten zu. Der hat z.B. einen integrierten Temperatursensor, der über das Busprotokoll kalibriert werden könnte. Gegebenenfalls könnten dann auch temperaturabhängige Aktionen konfiguriert werden. z.B. Eiswarnleuchte, Lüfter, Sonnenalarm. Der Speicher ist ausreichend groß und sogar eine Hardwarebeschleunigung für CRC Berechnung ist vorhanden.
 
Dagegen spricht aus meiner Sicht nichts. Meinungen ?
Ein Timeout ist ja sowieso nötig, 1.5 Byte der letzten Baudrate machen Sinn, hatte bei mir 2Byte drin, die aber nach einem korrekt empfangenen Knotenrequest verworfen werden, da man ja in Sync ist, d.h. ein Knoten kann sofort auf einen Knotenrequest (mit korrekter Checksum) antworten. Dann kann auch kein anderer bei Multimaster reinfunken, quasi ein atomic handshake;)
 
Ich habe gerade einen Blick in das Datenblatt des STM32G030F6P6 aus Deinem Minimalcontroller geworfen. Der lässt schon einiges an Möglichkeiten zu. Der hat z.B. einen integrierten Temperatursensor, der über das Busprotokoll kalibriert werden könnte. Gegebenenfalls könnten dann auch temperaturabhängige Aktionen konfiguriert werden. z.B. Eiswarnleuchte, Lüfter, Sonnenalarm. Der Speicher ist ausreichend groß und sogar eine Hardwarebeschleunigung für CRC Berechnung ist vorhanden.
Hast Du auch überprüft, ob der Speicher des STMG030F6P6 für eine schlanke Modbus Protokollimplementierung ausreicht ?
Diese Implementierung setzt z.B. FreeRTOS ein und dürfte schon deshalb gewisse Speicheranforderungen haben.

Aber eine "Weiche" für Modbus einzubauen und Modbus zu implementieren sind ja zwei verschiedene Dinge.
Ersteres setzt ja nur voraus, dass man die Modbus Timeouts verwendet. Letzteres kann dann ja jemand anderes machen :LOL:

Kann man das vielleicht in etwa so darstellen ?

modbus-01.png

Wobei im zweiten Fall die ersten vier Bytes natürlich schon als Teil der Modbus Message betrachtet werden.
 
Zuletzt bearbeitet:
Ein Timeout ist ja sowieso nötig, 1.5 Byte der letzten Baudrate machen Sinn, hatte bei mir 2Byte drin, die aber nach einem korrekt empfangenen Knotenrequest verworfen werden, da man ja in Sync ist, d.h. ein Knoten kann sofort auf einen Knotenrequest (mit korrekter Checksum) antworten. Dann kann auch kein anderer bei Multimaster reinfunken, quasi ein atomic handshake;)
Beim aktuellen Protokollvorschlag wäre ja jede Nachricht ein Knotenrequest.
Das, was bei Deinem Protokoll ein Knotenrequest war (von der Funktion her ein Ping, um regelmässig zu prüfen, ob der Knoten noch online ist ?), wäre hier eine normale 4-Byte Nachricht mit dem Service "Ping".

Der Knoten würde dann einfach genau diese Nachricht an den Knoten 0 zurückschicken.
 
Ja, zum einem war das der Alive Check, daß der Knoten noch da ist, zum anderen das Abrufen der Akkuspannung, Strom, Licht. Wobei man das auch als generellen Service Request machen könnte :unsure:
Bei direkter Ansprache des Knotens würde ich bei dem jeweiligen Knoten kein Timeout machen, da der ja zum Reden aufgefordert wurde, der Rest hält's Maul;)
 
Bei direkter Ansprache des Knotens würde ich bei dem jeweiligen Knoten kein Timeout machen, da der ja zum Reden aufgefordert wurde, der Rest hält's Maul;)
Falls es sich aber um eine Modbus Nachricht handelt, könnte das erste Byte dieser Nachricht ja zufällig eine valide Knotenadresse sein.
Würde der Knoten dann nach dem vierten Byte sofort antworten, würde er den Rest der Modbus Nachricht überschreiben.
Daher sollte er zumindest eine bestimmte Zeit warten, ob noch ein 5. Byte nachkommt, denke ich.
 
Die Frage ist natürlich: braucht man hier wirklich den Modbus? Bringt das irgendeinen Vorteil, das vorzuhalten, oder führt man, wenn es nötig ist, nicht lieber ein Kommando ein wie: Achtung, jetzt kommt eine überlange Nachricht für Knoten x. Alle anderen ignorieren die und warten eh auf einen Timeout (Weil der Empfangszähler erst nach einem Timeout auf 0 gesetzt wird).
Einen richtigen Grund für Modbus sehe ich hier gerade nicht :unsure:
 
Ok, ich versuche dann mal, den bisherigen Stand der Protokolldiskussion zusammenzufassen:
  • Wir könnten Modbus als zusätzliches Protokoll ermöglichen, wenn wir die beiden Modbus Timeoutbedingungen einhalten.
    • Das wäre nicht schwer.
    • Das Protokoll wäre durch die Timeouts robuster, als wenn man nur die Anzahl der empfangenen Bytes zählen würde.
  • Modbus und der "atomic Handshake" schliessen sich gegenseitig aus.
    • Der "atomic Handshake" ist kürzer als eine komplette Nachricht, das bringt aber m.E. keinen so großen Vorteil.
    • Das 4-Byte Protokoll ist, besonders bei der avisierten Baudrate von 115200, sehr schnell. Wir müssen also keine Zeit sparen.
  • Mögliche Use Cases für Modbus wurden genannt, lassen sich aber ebenfalls im Rahmen des 4-Byte Protokolls realiseren:
    • Kalibrierung des A/D Wandlers:
      • Lässt sich wahrscheinlich alternativ mit mehreren Schreib/Lese Registern realisieren.
      • Der Temperatursensor des Chips misst ohnehin nur die Temperatur des Chips ;) ...
    • FW-Update:
      • Die Funktionen der Knoten sind recht elementar. Die FW solllte daher so einfach sein, dass Updates nicht nötig sind.
      • Generell wird die Notwendigkeit des FW-Updates bei so einfachen Schaltungen m.E. überschätzt.
      • Zur Not ist ein FW-Update immer über die SWD-Schnittstelle möglich
Kurzum, ich wäre dafür, schon die Modbus Timeouts zu implementieren, weil sie ohnehin Sinn machen, aber die eigentliche Modbus Implementierung einfach als Möglichkeit für die Zukunft offenzulassen.

Des weiteren würde ich gerne auf die "atomic Handshakes" verzichten, weil sie aus meiner Sicht eine Protokollausnahme darstellen, indem sie die klare Strukturierung in 4-Byte Nachrichten mit definierten Timeouts dazwischen durchbrechen würden.
 
"Atomic Handshake" wäre für Multimaster gut, dann gibt es eine sichere Antwort auf eine Anfrage. Timeout wäre ja ok, aber 0.5 Byte weniger, als der Rest, damit ist die Antwort sicher und es gibt keine Kollisionen. Ansonsten bräuchte man noch einen längeren Nachrichten Stack, damit eine vorherige Anfrage einer Antwort sicher zugeordnet werden kann.
 
Andererseits ...

Die Ping Requests sind das, was die meiste Zeit über den Bus läuft. Oder anders herum gesagt, wenn der Primary nicht gerade Ping Requests sendet, ist es die meiste Zeit still auf dem Bus und alle Knoten können in einen low Power State ("Sleep Mode") gehen.

Würde man also für die Ping Requests einen 2-Byte Kurzbefehl einführen, z.B. :

<Knotenadresse><Service: Ping>

würde das die Wach-Zeit des Systems fast halbieren. Der Stromverbrauch wäre nahezu halbiert.

Das Timeout könnte man sich dann in der Tat auch schenken, wie @nikolauzi schon erläutert hat.

P.S.: Als weiteren Kurzbefehl würde ich vielleicht noch :

<Broadcastadresse><Wakeup from Deepsleep>

mit einem besonders langen Timeout definieren. Damit hätte man die Möglichkeit, alle Knoten in einen Deepsleep Mode zu versetzen, in dem sie nur noch wenige uA Strom benötigen.
Die Aufwachzeit aus dem Deepsleep ist ziemlich lang, daher das extralange Timeout.
 
Zuletzt bearbeitet:
Multimaster Betrieb wäre vielleicht interessant für Tasten/Tastenfelder oder allgemein für Eingabegeräte.

Wenn man sich vorstellt, dass es einen Knoten am Tiller (oder an den Lenkstöcken) gibt, an den alle Tasten angeschlossen sind, dann müsste der Master zumindest diesen Knoten relativ häufig pollen. (alle 100 ms ?).

Wenn man dem Knoten am Tiller erlaubt, selbständig Nachrichten an den Master zu schicken, wenn eine Tasten gedrückt werden, würde man sich das Polling sparen, aber man hätte de Fakto zwei Master.

Aber vielleicht liesse sich das ja relativ einfach realisieren ?
 
Kann, muß aber nicht. Bei einem Tiller würde man das vielleicht so machen.

Im Falle einer Panzerlenkung wäre es praktischer, in jedem Schaltknauf einen Knoten zu haben. Hätte man z.B. im linken Schaltknauf den Master, müsste man ansonsten von den Tastern im rechten Schaltknauf einzelne Leitungen zum linken legen.

Ich würde, glaube ich, dem Master ein kleines Display spendieren und in ein separates Gehäuse setzen.
Auf dem Display kann man die vorhandenen Knoten, ihren Status, Temperatur/Luftfeuchtigkeit/Akkustand und Uhrzeit anzeigen.

In den Schaltereinheiten, endtweder am Tiller oder an den Lenkstöcken, hätte man dann jeweils nur ganz einfache Knoten, die die Tasten einlesen und bei Tastendruck ne Nachricht an den Master senden.
 
Im Falle einer Panzerlenkung wäre es praktischer, in jedem Schaltknauf einen Knoten zu haben. Hätte man z.B. im linken Schaltknauf den Master, müsste man ansonsten von den Tastern im rechten Schaltknauf einzelne Leitungen zum linken legen.
Je nachdem, wie die Knöpfchen aufgeteilt sind. Wenn es keine Telegramme gibt, in denen Informationen von beiden Lenkhebeln zugleich stehen, ... äh, muss es aber geben, denn spätestens das Bremslicht sollte ja auf beide Bremsen reagieren.
Man muss sich halt überlegen, was man da bei komplexeren Bedienstrategien (dimmen?) sendet. "Knopf gedrückt" und "Knopf losgelassen"?
 
Zurück
Oben Unten