Hallo zusammen
Ich habe eine neue Hardware entwickelt, welche per UART bzw. USB-Seriell
mit dem PC verbunden werden kann.
Die Frage welche sich mir nun stellt ist, ob es bereits irgendwo auf
Github sinnvolle Kommunikationsprotokolle gibt?
Modbus wäre hier z.B. ein Kandidat. Ich könnte ja theoretisch alles über
ModBus bzw. in Register ablegen. Aber ich habe das Gefühl, dass es im
Jahr 2022 evtl. etwas "neueres" gibt?
Klar, ich könnte mir auch etwas eigenes stricken... aber ich setze gerne
auf bestehendes wenn möglich.
Danke schonmal für eure Vorschläge.
Gruss
Simon
Da mache ich doch direkt mal wieder Werbung für ein eigenes
USB-Protokoll statt UART. USB bringt schon vieles mit, gesicherte
Übertragung mit Prüfsumme und Retry, Paketierung, mehrere Kanäle
(Endpoints), Flusskontrolle (keine Pufferüberläufe oder Datenverlust
möglich), eingebautes Anfrage-Antwort-Protokoll für "normale" Befehle
(Control Endpoints), und natürlich mehr Bandbreite. Das nimmt dir viel
Implementierungsaufwand ab, weil das meiste davon schon in Hardware
passiert bzw. auf PC-Seite im Treiber. Wenn man es richtig macht muss
man auf PC-Seite auch keinerlei Treiber installieren/konfigurieren und
der Nutzer muss auch keinen Port auswählen (was bei Seriell immer nötig
ist). Weniger Hardwareaufwand ist es auch. Ist auch nicht so angestaubt
wie Modbus :)
Pepe T. schrieb:> Die neuen sachen laufen alle mit json.
Danke für die Antworten. Und wie stellst du bei json das Ende der
Übertragung sicher? JSON wäre ein Layer überhalb der
Übermittlungsschicht.
Zuden, wie würde ein JSON protokoll aussehen?
1
{
2
"request1":"voltage",
3
"request2":"version"
4
}
oder wie würdest du dies machen?
Peter D. schrieb:> SCPI wird gerne genommen.
Danke, muss ich mir anschauen. Kenne ich noch nicht.
Dergute W. schrieb:> PPP oder SLIP,
Danke, muss ich mir auch anschauen.
Niklas G. schrieb:> Da mache ich doch direkt mal wieder Werbung für ein eigenes> USB-Protokoll statt UART.
Einverstanden. Aber nicht alle MCUs können USB nativ...
Simon schrieb:> Danke für die Antworten. Und wie stellst du bei json das Ende der> Übertragung sicher? JSON wäre ein Layer überhalb der> Übermittlungsschicht.
Ein HTTP Request = eine Übertragung.
Wo soll da ein Problem sein?
Alles andere übernimmt die TCP/IP Schicht.
Nachteil: Du brauchst einen kompletten TCP/IP Stack mit Webserver. Aber
wenn das Gerät das hergibt spricht nichts dagegen.
Simon schrieb:> Danke für die Antworten. Und wie stellst du bei json das Ende der> Übertragung sicher?
Ans Ende ein 0-Byte packen, oder sicherstellen dass alle Bytes ohne
Lücken direkt gesendet werden und das Ausbleiben eines weiteren Bytes
als Ende interpretieren (manche Controller haben da einen Interrupt
für), oder das JSON-Objekt kontinuierlich parsen und das schließende }
erkennen, oder natürlich am Anfang des Pakets die Länge mitschicken.
Andererseits ist JSON ein ziemlicher Overhead.
Simon schrieb:> Dergute W. schrieb:>> PPP oder SLIP,>> Danke, muss ich mir auch anschauen.
Das ist IMO auch kein besonders moderner Ansatz. Wenn schon Netzwerk,
dann USB mit Ethernet-"Simulation", ähnlich wie der Raspberry oder
Beaglebone es machen. Bei den Modem-Protokollen muss der User auf
PC-Seite ja auch erstmal die Einwahl starten, bei USB-Ethernet ginge das
nahezu vollautomatisch, und schneller ist es sowieso.
Simon schrieb:> Einverstanden. Aber nicht alle MCUs können USB nativ...
Nicht alle, aber sehr viele, zumindest USB-FS. Im Zweifelsfall würde ich
mir fast schon überlegen den USB-Seriell-Adapter durch einen USB-fähigen
selbstprogrammierten Controller zu ersetzen, um auf USB-Seite ein
"vernünftiges" Protokoll zu haben und es anwendungsspezifisch auf UART
umzusetzen, ähnlich zu den aktuellen Arduinos.
Simon schrieb:> SCPI scheint exakt das zu sein, wonach ich gesucht habe :)
Leider auch ASCII und mit Parsing-Aufwand...
Pepe T. schrieb:> Stimmt. Ohne eine parser-lib würde ich das nicht versuchen.
Natürlich braucht man einen Parser. Aber meistens stricken die Leute
dann irgendein Protokoll selber und den parser wacklig dazu. Das spart
dann nichts.
Dann lieber ein bekanntes Protokoll mit vielen verfügbaren Parsern.
Pepe T. schrieb:> Stimmt. Ohne eine parser-lib würde ich das nicht versuchen.
Und es braucht eine relativ komplexe/dynamische Speicherverwaltung.
Seriell benutzen weil man einen sehr einfachen Controller ohne USB hat
aber dann ein kompliziertes Datenformat wählen ist... widersprüchlich?
IMO ist der übliche Ansatz mit USB-Seriell-Adapter eine Vereinigung der
Nachteile beider Systeme. Darauf etwas modernes aufsetzen zu wollen hat
was von "die Krücke aufhübschen".
Aber wir sollten mal was über die gewünschten Features, Bandbreite,
Leistung des Controllers erfahren.
Niklas G. schrieb:> Seriell benutzen weil man einen sehr einfachen Controller ohne USB hat> aber dann ein kompliziertes Datenformat wählen ist... widersprüchlich?
Anpassung an die heutige python generation :)
Simon schrieb:> Ich habe eine neue Hardware entwickelt, welche per UART bzw. USB-Seriell> mit dem PC verbunden werden kann.>> Die Frage welche sich mir nun stellt ist, ob es bereits irgendwo auf> Github sinnvolle Kommunikationsprotokolle gibt?
Also erstens: Du bist ein HELD!!
Und zweitens: dazu müßtest du Github durchsuchen. Dieses Forum wäre dazu
die falsche Adresse.
So. Du hast also einen Controller, den du vom PC aus über UART und USB
gleichermaßen ansprechen willst. Nun denn, das ist nicht unüblich.
Wenn es menschlich gut lesbar sein soll, dann mache es auf der µC-Seite
einfach zeilenorientiert, eben so wie eine normale übliche
Kommandozeile. Wie du die auseinander nimmst und wie du auf fehlerhafte
oder unverstandene Kommandozeilen reagierst, ist deine Sache.
Wenn es nur zur Kommunikation zwischen zwei Maschinen dienen soll und
dle menschliche Lesbarkeit keine große Rolle spielt, dann kommt auch
eine Art Ableger der UPN in Frage. Also Kommandos, die aus einzelnen
Buchstaben bestehen und Parameter zu diesen Kommandos als Dezimalzahlen.
Die werden den Kommandobuchstaben vorangestellt. Kein Echo.
Niklas G. schrieb:> Da mache ich doch direkt mal wieder Werbung für ein eigenes> USB-Protokoll statt UART.
Das würde beim USB einen passenden Treiber im PC bedingen und dieser
müßte neuerdings auch signiert sein. Ich würde von so etwas lieber
absehen und stattdessen ein möglichst gut eingeführtes Protokoll nehmen,
z.B. VCP.
W.S.
W.S. schrieb:> Das würde beim USB einen passenden Treiber im PC bedingen und dieser> müßte neuerdings auch signiert sein.
Das ist ab Windows 8 mitgeliefert in Form von WinUSB. Man muss lediglich
den WinUSB Deskriptor im Gerät implementieren und kann dann direkt von
der Anwendung heraus auf das Gerät zugreifen. Keine
Treiber-Installation/Konfiguration nötig. Unter Linux ist das alles
sowieso kein Problem. Unter Android geht es auch super.
W.S. schrieb:> Ich würde von so etwas lieber absehen und stattdessen ein möglichst gut> eingeführtes Protokoll nehmen, z.B. VCP.
VCP ist kein Protokoll sondern ein umgangssprachlicher Begriff für
verschiedene USB-Serial-Protokolle inklusive USB-CDC-ACM. Was aber wie
gesagt auch nicht das gelbe vom Ei ist.
