[STM32] USB-Buffer erhöhen?

[Mampf F. (mampf)]

Guten Abend,

die USB Full-Speed Device Library von ST funktioniert ja recht gut, 
allerdings scheint zB USB CDC recht lahm zu sein.

Soweit ich weiß, ist der USB-Buffer 64Byte groß und alle 1ms kann ein 
Paket gesendet werden, was 64kB/s ergibt.

Kann man den Buffer erhöhen oder gibt es da Hardware-Einschränkungen?

CDC ist mir eigentlich nicht so wichtig - wenn es einen flotteren 
Transfer-Modus gibt, könnte ich auch den verwenden.

Hat jemand Ideen?

Vielen Dank!
Mampf

[Niklas Gürtler (Gast)]

Mampf F. schrieb:
> CDC ist mir eigentlich nicht so wichtig - wenn es einen flotteren
> Transfer-Modus gibt, könnte ich auch den verwenden.

Ja natürlich, du kannst USB auch nutzen ohne einen Serial Port zu 
emulieren. Wie sollen sonst USB Festplatten, Mäuse, Kameras... 
funktionieren? Natürlich muss die PC-Software dann entsprechend darauf 
zugreifen. Dafür kannst du das Protokoll dann genauer kontrollieren. 
Siehe dazu z.B. mein
USB-Tutorial mit STM32.

[Karl (Gast)]

Mampf F. schrieb:
> Soweit ich weiß, ist der USB-Buffer 64Byte groß und alle 1ms kann ein
> Paket gesendet werden, was 64kB/s ergibt.

Das ist nicht richtig. Mein stm32 schaufelt ca 8 MiB/s über ein CDC 
Interface. Da limitiert der Treiber von Windows. Mit FS sind es gut 800 
kiB/s. Nicht so weit weg von der theoretischen Bandbreite.

[Mampf F. (mampf)]

Karl schrieb:
> Mampf F. schrieb:
>> Soweit ich weiß, ist der USB-Buffer 64Byte groß und alle 1ms kann ein
>> Paket gesendet werden, was 64kB/s ergibt.
>
> Das ist nicht richtig. Mein stm32 schaufelt ca 8 MiB/s über ein CDC
> Interface. Da limitiert der Treiber von Windows. Mit FS sind es gut 800
> kiB/s. Nicht so weit weg von der theoretischen Bandbreite.

Oha! Hmm, welche USB Lib hast du da verwendet?

[Mampf F. (mampf)]

Niklas Gürtler schrieb:
> Siehe dazu z.B. mein
> USB-Tutorial mit STM32.

Krasses Tutorial! Sehr gut gemacht! :)

[Niklas Gürtler (Gast)]

Mampf F. schrieb:
> Krasses Tutorial! Sehr gut gemacht! :)

Danke, ich hoffe es ist von Nutzen :)

[Jim M. (turboj)]

Mampf F. schrieb:
> Soweit ich weiß, ist der USB-Buffer 64Byte groß und alle 1ms kann ein
> Paket gesendet werden, was 64kB/s ergibt.

Das ist nicht korrekt. Bei USB Bulk kann alle Nasen lang ein 64 Byte 
Paket gesendet werden, da gehen maximal ~1MByte/sec über die Leitung.

Und das geht IIRC bei passender PC Programmierung auch über den normalen 
Windows CDC Treiber rüber.

Ansonsten gäbe es auch noch WinUSB oder LibUSB.

[Mampf F. (mampf)]

Hmm, ich glaub ich hab dann wohl irgendwas anderes falsch gemacht :)

Muss das nochmal testen!

Viele Dank für eure Erfahrungen!

[Karl (Gast)]

Mampf F. schrieb:
> Oha! Hmm, welche USB Lib hast du da verwendet?

CubeMX.

[Mampf F. (mampf)]

Aaalso ich hab das jetzt nochmal getestet ...

Mit ca. 8kB Daten PingPong gespielt.

Das dauert sowas 68ms, was eine Datenübertragungsrate von etwa 235kB/s 
wäre.

Das ist nicht gut, aber evtl kann ich damit leben ...

Evtl ist mein Problem, dass ich das Linux ttyACM Device verwende, 
welches Baud-Raten scheinbar vollständig ignoriert.

Hat jemand zufällig unter Linux schonmal schnelleres CDC hinbekommen?

Viele Grüße,
Mampf

[Niklas G. (erlkoenig)]

Mampf F. schrieb:
> Evtl ist mein Problem, dass ich das Linux ttyACM Device verwende,
> welches Baud-Raten scheinbar vollständig ignoriert.

Die Baudraten werden einfach über den Control Endpoint an das USB Device 
weitergegeben. Du musst auf dem Controller darauf reagieren und die 
Baudrate des UART's einstellen. Auf die USB-Übertragung selbst hat die 
Baudrate überhaupt keinen Einfluss. Wenn du die Daten gar nicht auf 
einen UART umleitest sondern direkt im Controller weiter verarbeitest, 
spielt die Baudrate gar keine Rolle.

Das Problem ist halt dass du über einen virtuellen Com-Port die Puffer 
und  Timings nicht direkt kontrollieren kannst; das ganze ist halt eine 
ziemliche Krücke.

[Mampf F. (mampf)]

Niklas G. schrieb:
> Wenn du die Daten gar nicht auf
> einen UART umleitest sondern direkt im Controller weiter verarbeitest,
> spielt die Baudrate gar keine Rolle.

Ah okay, verstanden :)

> Das Problem ist halt dass du über einen virtuellen Com-Port die Puffer
> und  Timings nicht direkt kontrollieren kannst; das ganze ist halt eine
> ziemliche Krücke.

Wäre ein anderer Transfer-modus besser?

CDC hab ich nur genommen, weil es funktioniert - wenn auch nicht 
besonders schnell.

Aber unter der Haube läuft eh ein Binäres Protokoll mit State-Maschine 
:)

[Niklas G. (erlkoenig)]

Mampf F. schrieb:
> Wäre ein anderer Transfer-modus besser?

Naja, was verstehst du unter Transfer-Modus? USB-CDC-ACM ist eine 
USB-/Klasse/, also ein vordefinierter Gerätetyp. Wenn du den nicht 
nutzt, hast du kein ttyACM-Gerät mehr, und musst irgendwie anders 
zugreifen. Würdest du beispielsweise die Klasse "MSC" (Mass Storage 
Class) implementieren, würde der Zugriff stattdessen über fopen, fwrite 
usw. erfolgen. Wenn du keine Standard-Klasse implementierst könntest du 
über die libusb-Funktionen zugreifen. Vorhandene PC-Programme müssten 
dann angepasst werden. Du musst wissen was du hier brauchst...

Mampf F. schrieb:
> Aber unter der Haube läuft eh ein Binäres Protokoll mit State-Maschine
> :)
Bei direkter Nutzung der USB-Funktionen würde die FSM ggf. sogar 
vereinfacht, weil du keine Paket-Erkennung und Handshake/Flusskontrolle 
mehr brauchst, weil die USB-Hardware das schon macht.