Forum: Mikrocontroller und Digitale Elektronik Raspberry Pi Virtual COM Port Datenrate


von Florian (Gast)


Lesenswert?

Hallo,

ich möchte Sensordaten von einem Nucleo 32 (STM32L4) zum Raspberry Pi 
mittels USB übertragen. Dabei ist der USB Anschluss auch gleichzeitig 
die Stromversorgung des Boards. Nun zu meinem Problem:

Ich brauche eine Datenrate von min. 150 KBytes/sek. und das erreiche ich 
auch an meinem Windows PC. Jedoch bekomme ich am Pi nur maximal 128 
KBytes/sek. Das gleiche gilt auch für den Arduino Clone der einen CH340G 
besitzt. Windows -> 200KBytes/sek. Raspberry -> 59KBytes/sek. Im übrigen 
kann ich mehrere Boards parallel laufen lassen ohne das die Datenrate 
zusammenbricht. Es scheint so als seien Kapazitäten im Bus vorhanden.

Weiß jemand woran das liegen kann?
Hat schon mal jemand höhere Datenraten über VCP am Raspberry erreicht?
Gäbe es bessere Übertragungswege?

von PittyJ (Gast)


Lesenswert?

Kann man das nicht über Usb direkt machen? Auf dem Nucleo einen 
USB-Slave implementieren und dann einfach Bulk-Transfer machen. Damit 
sollten mehrere MBytes/Sek gehen.

von Niklas Gürtler (Gast)


Lesenswert?

Genau, bei einem "richtigen" USB-Gerät hat man mehr Kontrolle über die 
Übertragung. Siehe dazu z.B. mein
USB-Tutorial mit STM32, das müsste auch zum STM32L432KC passen. Du 
musst nur schauen wie du eine USB-Buchse an den Controller bekommst.

von Stefan F. (Gast)


Lesenswert?

Der Raspberry Pi hat eben schnarch-langsame I/O Schnittstellen. Da kann 
man (ohne viel Aufwand) nicht viel dran ändern.

von Jim M. (turboj)


Lesenswert?

Florian schrieb:
> Das gleiche gilt auch für den Arduino Clone der einen CH340G
> besitzt. Windows -> 200KBytes/sek. Raspberry -> 59KBytes/sek.

Bei welcher Baudrate? 200KB/s über einen UART sind enorm fix.

Aber 200KB/s über echtes USB sind eher langsam. Man bedenke auch das am 
RPi interne Peripherie am USB mit dran hängt, die den Bus ausbremsen 
kann.

Das dürfte man bei vielen kleinen Paketen (<64 Byte) deutlich merken. 
Wie sehen Deine USB Pakete aus?

von PittyJ (Gast)


Lesenswert?

Stefanus F. schrieb:
> Der Raspberry Pi hat eben schnarch-langsame I/O Schnittstellen. Da kann
> man (ohne viel Aufwand) nicht viel dran ändern.

Zumindest über USB bekommt man beim Rapsi aber einiges an Daten rüber. 
Ich habe da USB-Sticks dran, die ganz performant funktionieren.

Warum jeder immer nur virtuelle Comports benutzen möchte, verstehe ich 
nicht.
Selbst Fullspeed (USB 1.1) bietet doch schon 12 Mbit/Sekunde. Da muss 
man eben nur mal den passenden Slave programmieren.
Viele Chiphersteller (z.B. NXP) bieten sowas schon als Sample-Code an.

von xyz (Gast)


Lesenswert?

Die virtuelle COM ist eben einfach und universell nutzbar.
Damit kann man auch einfach die App (PC) programmieren und einbinden 
ohne sich über Treiberinstallationen Gedanken zu machen.

von Stefan F. (Gast)


Lesenswert?

> Warum jeder immer nur virtuelle Comports benutzen möchte,
> verstehe ich nicht.

Mir sind folgende Vorteile bekannt:

- Funktioniert mit jedem Betriebssystem auf die gleiche Weise
- Man muss keinen Windows/Linux/Mac Treiber programmieren
- Man muss keinen unsignierten Treiber benutzen
- Man kann die Schnittstelle leicht manuell testen
- Man hängt nicht von spezieller Hardware ab, die man in ein paar Jahren 
vielleicht nicht mehr kaufen kann
- Wird von (fast) jeder Programmiersprache direkt unterstützt

Natürlich gibt es auch Nachteile.

> Da muss man eben nur mal den passenden Slave programmieren.

Das fällt Dir vielleicht leicht. Du vergisst vielleicht, dass die 
Spezifikationen von USB jahrelang für Laien gar nicht zugänglich waren 
und danach nur für viel Geld. Hinzu kommt, dass sie mehrere tausend 
Seiten umfasst, das schreckt den durchschnittlichen Hobbyelektroniker 
schon ab.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Stefanus F. schrieb:
> - Funktioniert mit jedem Betriebssystem auf die gleiche Weise
Dank libusb bei USB kein Problem (mehr). Die Win32-API's für COM-Ports 
sind doch noch ziemlich anders als die von POSIX.

Stefanus F. schrieb:
> - Man muss keinen Windows/Linux/Mac Treiber programmieren
Dank libusb bei USB nicht nötig.

Stefanus F. schrieb:
> - Man muss keinen unsignierten Treiber benutzen
Dank libusb+WinUSB unter Windows nicht mehr nötig, unter Linux sowieso 
nicht.

Stefanus F. schrieb:
> - Man kann die Schnittstelle leicht manuell testen
Das stimmt.

Stefanus F. schrieb:
> - Man hängt nicht von spezieller Hardware ab, die man in ein paar Jahren
> vielleicht nicht mehr kaufen kann
Das Problem besteht bei VCP's doch ganz genauso... Und die UART's 
verschiedener Controller unterscheiden sich auch.
Tatsächlich haben viele Controller ähnliche USB-Peripherien; die "OTG" 
Peripherie der STM32 ist von Synposys gekauft und vermutlich auch in 
Controllern anderer Hersteller zu finden. Unter Nutzung abstrahierender 
Bibliotheken wie z.B. derer von Segger erledigt sich das Problem 
ohnehin.

Stefanus F. schrieb:
> - Wird von (fast) jeder Programmiersprache direkt unterstützt
libusb hat auch Bindings für diverse Sprachen; viele Sprachen können 
auch C-API's ansprechen.

Stefanus F. schrieb:
> Hinzu kommt, dass sie mehrere tausend
> Seiten umfasst, das schreckt den durchschnittlichen Hobbyelektroniker
> schon ab.
Deswegen gibt's ja Tutorials :P

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

Der libusb Treiber ist allerdings nicht signiert, er lässt sich unter 
Windows 8 und 10 nur mit einem dirty Hack installieren, der wiederum 
Sicherheitsrisiken mit sich bringt. Diese Prozedur kann man einem 
Endanwender nicht zumuten.

Ansonsten mag ich libusb. Schade, dass Microsoft ihn nicht zur 
Standardausstattung von Windows macht.

> libusb hat auch Bindings für diverse Sprachen

Was aber die Installation bzw. Nutzung weiterer Libraries erfordert. Das 
ist wieder zusätzlicher Aufwand, den man bei USB-USART nicht hat und 
somit ein Plus-Punkt für USB-UART.

Ich kann auch mit dem Auto Brötchen kaufen. Trotzdem ist für mich das 
Fahrrad zum Brötchenkaufen handlicher.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Stefanus F. schrieb:
> Der libusb Treiber ist allerdings nicht signiert
Den braucht man auch gar nicht mehr. libusb kann direkt ohne 
irgendwelche Installation alle Geräte ansteuern, für die der 
WinUSB-Treiber geladen wurde. Das kann man für beliebige Geräte mithilfe 
des Geräte-Managers oder des Programms "Zadig" erreichen, oder durch 
Hinzufügen eines bestimmten USB-Deskriptors, sodass...

Stefanus F. schrieb:
> Diese Prozedur kann man einem
> Endanwender nicht zumuten.
... der Endanwender da überhaupt nichts von mitbekommt und alles sofort 
funktioniert. Siehe dazu auch das Tutorial

Stefanus F. schrieb:
> Schade, dass Microsoft ihn nicht zur
> Standardausstattung von Windows macht.
Die wollen halt ihr eigenes WinUSB pushen.

Stefanus F. schrieb:
> Was aber die Installation bzw. Nutzung weiterer Libraries erfordert. Das
> ist wieder zusätzlicher Aufwand, den man bei USB-USART nicht hat und
> somit ein Plus-Punkt für USB-UART.
Welche Sprachen haben denn nativ ein COM-Port-Binding (welches auch 
taugt, also asynchrone Kommunikation und Einstellen der Baudrate usw 
unterstützt)?

Dafür musst du bei UART immer eine User-Schnittstelle zur Auswahl des 
Ports implementieren (nicht sehr nutzerfreundlich), das entfällt bei USB 
sofern man immer nur von 1 Gerät ausgeht.

: Bearbeitet durch User
von Johnny B. (johnnyb)


Lesenswert?

Florian schrieb:
> ich möchte Sensordaten von einem Nucleo 32 (STM32L4) zum Raspberry Pi
> mittels USB übertragen.

Wenn Die Datenrate nicht ausreicht, könntest Du das Problem auch lösen, 
indem Du die Datenmenge reduzierst.
z.B. Sensordaten nur senden wenn es eine Änderung gab, die 
Messwertauflösung auf das nötigste reduzieren, die Werte effizient 
übertragen (z.B. Binärdaten statt Strings), etc.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Stefanus F. schrieb:
> dass die Spezifikationen von USB jahrelang für Laien gar nicht zugänglich waren 
und danach nur für viel Geld.

Wie kommst Du auf diese interessante Idee?

von PittyJ (Gast)


Lesenswert?

Stefanus F. schrieb:
>
> Das fällt Dir vielleicht leicht. Du vergisst vielleicht, dass die
> Spezifikationen von USB jahrelang für Laien gar nicht zugänglich waren
> und danach nur für viel Geld. Hinzu kommt, dass sie mehrere tausend
> Seiten umfasst, das schreckt den durchschnittlichen Hobbyelektroniker
> schon ab.

Die Implementierung mit dem NXP Beispielcode hat mich 2 Tage gekostet. 
Zu STM kann ich nicht sagen.
Wer aber Krücken wie Virtuelle Comports benutzt, der sollte sich nicht 
über langsame Datenraten beschweren.

Ich habe schon seit mehreren Jahre freie USB Dokumentation, die aus dem 
Netz herunterladbar ist. Bei
http://www.usb.org/developers/docs/
ist viel zu finden. Hier gilt auch: wer Leistung will, der muß eben auch 
mal nachdenken.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Im Jahr 2000 waren auch schon Spezifikationsdokumente frei auf usb.org 
verfügbar, wie archive.org verrät:

https://web.archive.org/web/20000815090217/http://usb.org:80/developers/docs.html

von Stefan F. (Gast)


Lesenswert?

> Wie kommst Du auf diese interessante Idee?

Weil ich es erlebt habe. Vor 20 Jahren war das der Grund, dass mein Chef 
einen Entwicklungsauftrag ablehnen musste.

Wobei ich es auch mit Doku wohl auch nicht hinbekommen hätte. Aber das 
war damals noch nicht klar.

von Superschlumpf (Gast)


Lesenswert?

> wer Leistung will,

nimmt Ethernet!

Und nicht dieses USB-Gehampel.

von Stefan F. (Gast)


Lesenswert?

Auch Ethernet ist langsam, wenn man viele kleine Pakete überträgt.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Stefanus F. schrieb:
> Auch Ethernet ist langsam, wenn man viele kleine Pakete überträgt.

Vor allem, weil beim R-PI das Ethernet über USB angebunden ist.

von Superschlumpf (Gast)


Lesenswert?

> Auch Ethernet ist langsam, wenn man viele kleine Pakete überträgt.

Unfug. Selbst ein (Winz-)STM32F107 schafft mit Paketgroessen von
64 byte (+Header) mehrere MB/s ueber sein Fastethernet.

von Superschlumpf (Gast)


Lesenswert?

> Vor allem, weil beim R-PI das Ethernet über USB angebunden ist.

Ja, Inselaffentechnik.
Man nehme eine GPU, verwende davon nur den Huelfsprozessor und
das "UniveSelle Huelfsprotokoll" dazu.

von Stefan F. (Gast)


Lesenswert?

> Selbst ein (Winz-)STM32F107 schafft mit Paketgroessen von
> 64 byte (+Header) mehrere MB/s ueber sein Fastethernet.

Ja schön, das nützt Dir auf dem Raspberry Pi aber nichts, und das schon 
gar nicht in einem Netz mit viele Teilnehmern, wo gar WLAN und 
Video-Streaming Player auch noch ein Wörtchen mitreden vollen.

von Jim M. (turboj)


Lesenswert?

Stefanus F. schrieb:
> Der libusb Treiber ist allerdings nicht signiert, er lässt sich unter
> Windows 8 und 10 nur mit einem dirty Hack installieren

Das ist schlich falsch. Die .sys Datei ist ordnungsgemäß signiert, der 
Hack ist nur für die .inf Datei nötig weil da die (gerätespezifische) 
VID/PID drin stehen muss.

Und da wird mittels Zadig/libwdi einfach ein frisches Zertifikat 
generiert und installiert, das hinterher niemand hat und so auch nicht 
missbrauchen kann. Funzt so auch auf Win10.


LibUSB auf dem RPi wäre auch mein Lösungsansatz, denn mittels dessen 
Asyncron- Funktionen könnte man da vermutlich einiges rausholen. Die 
Idee dabei sind mehrere Puffer "in-flight" zu benutzen, also mehrere 
Transaktionen hintereinander zu submitten. Das Handling ist dann aber 
nicht mehr völlig trivial, insbesondere bei Fehlern.

von Superschlumpf (Gast)


Lesenswert?

> nicht in einem Netz mit viele Teilnehmern

Nochmal Unfug. Selbst ein kleiner Soho Switch, z.B. 8 Port Gbit
von HP hat eine nonblocking Switching Kapazitaet von 16 Gbps.

Der runzelt bei bei einem Back-to-Back Fastethernettransfer
noch nicht mal den A.

> Raspberry Pi

Bei dem Intellogo haette man frueher gesagt: "Wir haben das Problem
eingekreist."

von Dr. Sommer (Gast)


Lesenswert?

Du kannst ja mal Bescheid geben wenn du eine Plattform entwickelst, die 
ähnlich leistungsfähig und einfach nutzbar wie der R-PI und gleichzeitig 
so billig ist und sich weltweiter Beliebtheit erfreut. Die Argumente für 
den PI, und übrigens auch für USB, liegen nicht in großer Leistung, 
sondern im Preis und der einfachen Anwendung.

von Florian (Gast)


Lesenswert?

Die USB Peripherie vom Controller direkt zu nutzen wäre natürlich ein 
Ansatz. Bei meinem Sensor handelt es sich bereits um eine eigens 
entwickelte Platine, dann kann man den Mikrocontroller einfach da mit 
drauf setzen. Über das USB-Tutorial bin ich schon mal gestolpert. Das 
ist natürlich ein "bisschen" komplizierter müsste aber machbar sein.

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

Hi

Evtl. sind es aber auch irgendwelche Einstellungen der Schnittstelle 
oder das Programm das zum senden/empfangen verwendet wird auf dem PI. 
Hast du Mal mit stty/cat/echo getestet?

Matthias

Bitte 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
Noch kein Account? Hier anmelden.