Kommunikationsprotokoll zwischen Gerät und PC

SCPI wird gerne genommen. Ist nicht so überfrachtet und recht einfach zu 
parsen.

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 :)

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 :)

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.