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?
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.
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.
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?
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.
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.
> 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.
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
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.
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.
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.
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?
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.
> 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.
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.
> 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.
> 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.
> 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.
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.
> 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."
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.
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.
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
