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.
Der Raspberry Pi hat eben schnarch-langsame I/O Schnittstellen. Da kann man (ohne viel Aufwand) nicht viel dran ändern.
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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
> 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.
> wer Leistung will,
nimmt Ethernet!
Und nicht dieses USB-Gehampel.
Auch Ethernet ist langsam, wenn man viele kleine Pakete überträgt.
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.