Welche kontinuierliche Datenrate (soll ein Datenlogger werden) ist mit einem aktuellen PC mit Windows und einem STM32 möglich? Welche USB Device Class wäre empfehlenswert (=zuverlässige Datenübertragung in der richtigen Reihenfolge und kontrollierter Latenz) 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.
Daniel Hofer schrieb: > und kontrollierter Latenz je nachdem was auf dem PC gerade passiert, kannst Du die "kontrollierte Latenz" knicken.
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"?
Mir ist schon klar das zwischengepuffert werden muss. @scummos: Könntest du bitte Details verraten? Genau sowas brauche ich....
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.
Was ist das Maximum, das man mit einem Virtual Com Port erreichen kann? Damit dürfte die PC Software deutlich einfacher werden...
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")
Daniel Hofer schrieb: > Welche kontinuierliche Datenrate (soll ein Datenlogger werden) ist mit > einem aktuellen PC mit Windows und einem STM32 möglich? > Welche USB Device Class wäre empfehlenswert (=zuverlässige > Datenübertragung in der richtigen Reihenfolge und kontrollierter Latenz) Du mußt dich schon entscheiden: Latenz kontrollieren (isochroner Transfer) oder Daten sicher übertragen (bulk Transfer). Beides gleichzeitig geht nicht. Nicht bei USB, nicht bei Windows und auch bei keinem anderen OS oder Bussystem. GRUNDLAGENKENNTNISSE
Daniel Hofer schrieb: > Mir ist schon klar das zwischengepuffert werden muss. Aber auch nur dann, wenn Dein Controller nicht schnell genug ist, um neue Daten zu liefern. Es wäre mal Interessant zu wissen, was Du überhaupt vor hast. Es ist nämlich durchaus ein Unterschied, ob Du die Daten kontinuierlich senden willst (ich nenns mal 'in Echtzeit'), oder ob da auch mal Pausen dazwischen sind. 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. 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.
Da fehlt noch ein f irgendwo. Hier isses: f
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.
Christian R. schrieb: > Nee, die teilen sich dann die Bandbreite. Da verabschiedet sich nix. Theoretisch schon. Christian R. schrieb: > 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. Sagt auch keiner, dass es nicht machbar ist. Aber die Daten an den PC zu schaufeln ist alle Mal einfacher, als sie dann in der genannten Menge am PC auszuwerten.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.