mikrocontroller.net

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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Niklas Gürtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

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

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: xyz (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-2 lesenswert
nicht 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.

: Bearbeitet durch User
Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht 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
Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-2 lesenswert
nicht 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.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht 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
Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht 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?

Autor: PittyJ (Gast)
Datum:

Bewertung
2 lesenswert
nicht 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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht 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

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Superschlumpf (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> wer Leistung will,

nimmt Ethernet!

Und nicht dieses USB-Gehampel.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch Ethernet ist langsam, wenn man viele kleine Pakete überträgt.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht 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.

Autor: Superschlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Superschlumpf (Gast)
Datum:

Bewertung
-1 lesenswert
nicht 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.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht 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.

: Bearbeitet durch User
Autor: Jim M. (turboj)
Datum:

Bewertung
1 lesenswert
nicht 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.

Autor: Superschlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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."

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht 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.

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.