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
SCPI wird gerne genommen. Ist nicht so überfrachtet und recht einfach zu parsen.
:
Bearbeitet durch User
Modbus ist ein krüppel. Die neuen sachen laufen alle mit json.
Moin, PPP oder SLIP, wenns der Overhead hergibt. Drueber dann SNMP oder HTTP fuers Webinterface oder whatever fancy... Gruss WK
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 :)
:
Bearbeitet durch User
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...
SCPI scheint exakt das zu sein, wonach ich gesucht habe :) Vielen Dank! Hier ein cooles Beispiel um eine LED zu dimmen: https://github.com/Vrekrer/Vrekrer_scpi_parser/blob/master/examples/SCPI_Dimmer/SCPI_Dimmer.ino Gruss
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...
Niklas G. schrieb: > Andererseits ist JSON ein ziemlicher Overhead. Stimmt. Ohne eine parser-lib würde ich das nicht versuchen.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.