Kontinuierliche Datenrate Mikrokontroller -> PC über USB

Hallo,
> Daniel Hofer schrieb:
> Welche kontinuierliche Datenrate (soll ein Datenlogger werden)
Was soll er denn loggen, mit welchen Parametern?

>ist mit
> einem aktuellen PC mit Windows und einem STM32 möglich?
Mit Windows auf einem PC wäre mit USB2.0 eine Brutto-Datenrate von 
480MBit möglich. Praktisch einiges weniger.
Das wird dein uC aber womöglich gar nicht schaffen.

> Welche USB Device Class wäre empfehlenswert (=zuverlässige
> Datenübertragung in der richtigen Reihenfolge und kontrollierter Latenz)
Da Windows kein Echtzeit-OS ist, kannst du das mit der Latenz vergessen.
Da muß der uC selbst schon mal Zwischenspeichern.
Mit dem PC kannst du dann diese Datenpakete abholen.

> und wie würdet ihr das Programm auf dem PC schreiben? .Net (C#) ok?
> Ziel ist es, problemlos auch mehrere Datenlogger über einen USB Hub
> anzuschließen.
Dann teilen sich die Logger schon mal die Datenrate.
Aber im ungünstigen Fall hängen am gleichen USB-Host auch noch andere 
USB-Devices und nehmen Ressourcen weg.

Ich hab' sowas gemacht (auch mit einem STM32) und habe mit 11 MB/s keine 
größeren Probleme. Ein großer SRAM für den Mikrocontroller ist m.E. 
empfehlenswert, damit der ein bisschen was buffern kann.

Was ist Dir lieber? "Timestamps" oder "Isochronous Transfer"?

Was willst du denn genau wissen? Das ganze Setup zu beschreiben würde 
etliche Seiten füllen ;)
Der Controller, den ich verwende, ist ein LPC4333. Der Endpoint ist 
Bulk, einfach weil mir Isochronous zu kompliziert war. Ich nehme auf dem 
uC kontinuierlich 11 MB/s Daten auf, die in eine Art Ring-Puffer 
geschrieben werden, der aus 5 Blöcken mit je 16kB Größe besteht. Ist 
einer dieser Blöcke voll, wird ein Flag gesetzt und der Inhalt des 
Blocks über USB übertragen (man schreibt in so einen Write-Buffer und 
der eigentliche Transfer passiert dann asynchron im Hintergrund). Sobald 
die Übertragung beendet ist, wird das Flag wieder gelöscht und der Block 
kann von neuem beschrieben werden. Das funktioniert gut, solange der 
Computer ansonsten nur mäßig viel zu tun hat. Wenn der Computer 
ansonsten gerade viel zu tun hat, kann es vorkommen, dass er keine Daten 
abholt bevor alle 5 Blöcke voll sind, und dann gehen eben tatsächlich 
welche verloren. Ich vermute, das könnte man recht gut verhindern, indem 
man die Daten in einem Kernel-Modul in einen Buffer schreibt statt im 
Userspace; für meine Anwendung ist das aber egal, wenn da hin und wieder 
mal ein Paket fehlt. Fünfmal so viel SRAM zum Beschreiben würde aber 
sicherlich auch viel helfen.

Ein Virtual Com Port ist auch nur ein Bulk-Transfer

Für Bulktransfers stehen laut USB-Spezifikation maximal 80% der Bus-Zeit 
zur Verfügung, die sich alle Bulk-Endpoints teilen müssen.

kurzes kopfrechnen...

theoretisches netto, versteht sich

HAAALT!

der STM kann von haus aus nur USB full speed (12Mbit/s), kein USB High 
Speed (480Mbit/s), es sei denn, du packst ein externen USB-Phy drauf.

Daher dann der Butto Durchsatz geteilt durch 40, was dann 12MB/s 
entspricht
(sry, oben natürlich auch "brutto")

Potter schrieb:
> Abgesehen davon verabschiedet sich Dein Hub, sobald Du mehrer Geräte von
> diesem Typ dranhängst, weil der ja meist auch nur High-Speed kann - und
> zwar genau ein Mal.

Nee, die teilen sich dann die Bandbreite. Da verabschiedet sich nix.

Potter schrieb:
> Ich hatte mal eine Anwendung erstellt, die 24 MBytes/s an den PC sendet.
> Der Controller (FX2) hat da aber nichts anderes gemacht, als die Daten
> am Parallelport direkt in die USB Puffer zu schieben. Da ist dann keine
> Zeit mehr zu überlegen, ob die Daten auch sinnvoll sind. Das Auswerten
> muss dann am PC erfolgen. Und genau das ist auch die größere
> Herausvorderung.

Da braucht man halt schnelle Rechner. Wir haben hier Geräte entwickelt 
mit dem FX2 und dem FX3, da kommen auch 40MB/s bzw. 320MB/s in den PC 
und müssen verarbeitet werden. Alles machbar.

Auswerten geht auch, bei uns sind das Uiltraschallprüfgeräte, am PC 
werden dann live die entsprechenden Bnilddaten berechnet und angezeigt. 
Ist allerdings dann alles massiv parallel und auf der GPU, klar.

Daniel Hofer schrieb:
> Was ist das Maximum, das man mit einem Virtual Com Port erreichen kann?

Die Suche nach "ftdi maximum baud rate" ergibt "The maximum Baud rate 
achieveable with FTDI's current devices is 3M Baud."

Die Datenrate vom STM32 muss am USART dann auch genau 3M Baud sein.

Dafür kannst Du dann auch einen STM32 ohne USB-Controller nehmen, weil 
Du ja den USART nutzt.

Die Frage war aber ursprünglich
> Welche … Datenrate … ist mit einem … PC … und einem STM32 möglich?

Also mit oder ohne FTDI bzw. externen USB High Speed Phy?!

Little Basdart schrieb:
> der STM kann von haus aus nur USB full speed (12Mbit/s)

Also bei "80% Bus-Zeit"^^ 9.5M Baud Bulk-Transfer. Richtig?

> Damit dürfte die PC Software deutlich einfacher werden...

Einfach, falls Du z.B. einen FTDI-Treiber nimmst. Falls Du den Virtual 
Com Port über STM32-Firmware umsetzt, kannst Du auch gleich ein 
HID-Device nach Deinen Erfordernissen programmieren.

Daniel Hofer schrieb:
> Welche USB Device Class wäre empfehlenswert (=zuverlässige
> Datenübertragung in der richtigen Reihenfolge und kontrollierter Latenz)

Mit vertretbarem Aufwand: HID, sonst musst Du noch Windows-Treiber 
programmieren.
  PS: HID geht auch mit 480Mbit/s.

> und wie würdet ihr das Programm auf dem PC schreiben? .Net (C#) ok?

Diese Frage löst regelmäßig Glaubenskriege im Forum aus. C#.Net ist ok. 
Ich persönlich hätte die gleiche Entscheidung getroffen, aber das beste 
Tool ist oft das, was man am besten kennt.

Falls Du doch was mit externen USB-Phy und High Speed (480Mbit/s) 
machst, kann es erforderlich sein, einige Auswertungen mit "unmanaged 
code" zu programmieren.

Also wir benutzen Bulk und ohne Geräte Klasse. Quf PC Seite kommt der 
WinUsb Treiber zum Einsatz, Libusb wäre genauso einfach und ebenfalls 
fertig und signiert. Also nix selber Treiber programmieren und auch kein 
Stress mit x64. Auch wir nutzen C#, nur die unterste Ansteuerung der 
Winusb ist natürlich unmanaged. Das geht ganz gut, man muss halt bissl 
Nachdenken, dass man nicht immer alles Arrays dynamisch machtr und 
umkopiert.

Mein Board benutzt auch einen virtuellen COM-Port, auf die 11 MB/s kommt 
man damit durchaus.

@Sven B.: Das klingt interessant, da viel mehr als die "ftdi maximum 
baud rate"^^. Womit machst Du das?

Ist kein FTDI -- der uC selbst meldet sich als serielle Schnittstelle 
(das Interface steht in der Software). Hab' ich mehr oder weniger aus 
dem Demo-Projekt von lpcopen geklaut.