Hallo, hat schonmal wer den FT2232H mit 20-30 MB/s betrieben? Ich frage mich die ganze Zeit, wie man die Datenmenge bei kontinuierlichem Betrieb am PC (z.B. Windows) verarbeiten will? Da kommt ja keine Maschine mit, oder? Gruß Sam
Warum soll da kein PC mitkommen? GBit-LAN, SATA sind nicht unbedingt langsamer :-)
Naja bei SATA ist das nicht unbedingt kontinuierlich. Da kann ich der Hardware sagen "warte mal kurz, ich hab jetzt grade keine Zeit". Aber beim USB gehen mir dann die Daten verloren.
jede USB Festplatte schafft heute 30Mbyte/s. Und dabei ist kein PC ausgelastet. dabei wird dann sogar noch geschrieben. Die Frage ist ja was du mit den Daten machen willst. Aber reine Datenrate von 30Mbyte/s ist auf jeden Fall nicht ein Problem.
der Intel Core i7 980 XE kann 107.55 GFLOP/S durchfuehren (wikipedia) also bleibt dir pro empfangenem byte ca 3000 flops (Gleitkommazahl-Berechnungen) das sollte doch genug Dampf sein, um auch was komplizierteres mit den daten anzufangen Das Programm muss halt ein paar Tricks verwenden, zB mulithreading oder so
OK, es geht um einen Sensor, der mir ca. 30 MBit/s an Daten liefert. Auf meiner Hardware kann ich ein paar kByte zwischen speichern und dann ab über den FT2232H. Wenn ich die Daten also nicht regelmäßig an den PC sende, dann sind sie verloren. Bei der Festplatte ist das nicht so (da sie ja auf der selbigen gespeichert sind). Am PC will ich die Daten entgegennehmen, filtern und in einem Fenster ausgeben. Aber das wird so nicht funktionieren, weil der PC vermutlich nicht nachkommt. Oder hat da jemand andere Erfahrungen gemacht bzw. hat einen Tipp, wie man sowas angehen könnte?
Sam schrieb: > Aber das wird so nicht funktionieren, weil der PC vermutlich > nicht nachkommt. Eher kommt deine Elektronik zwischen Sensor und FT2232 nicht hinterher. Was willst du denn dafür verwenden?
Sam schrieb: > OK, es geht um einen Sensor, der mir ca. 30 MBit/s an Daten liefert. Auf > meiner Hardware kann ich ein paar kByte zwischen speichern und dann ab > über den FT2232H. Wenn ich die Daten also nicht regelmäßig an den PC > sende, dann sind sie verloren. Bei der Festplatte ist das nicht so (da > sie ja auf der selbigen gespeichert sind). > > Am PC will ich die Daten entgegennehmen, filtern und in einem Fenster > ausgeben. Aber das wird so nicht funktionieren, weil der PC vermutlich > nicht nachkommt. Oder hat da jemand andere Erfahrungen gemacht bzw. hat > einen Tipp, wie man sowas angehen könnte? SSDs geben beim Lesen ein paar hundert Megabyte pro Sekunde aus. Der Ram noch viel mehr. Also hoer auf mit dem Ueberlegungen.
30MBit/s sind ja deutlich weniger als die 30MByte/s, die der FT2232H schafft. Du musst halt dann die Datenaufnahme, Datenfilterung und Datenanzeige entkoppeln und in unterschiedlichen Threads laufen lassen. Machen wir bei unsrer Anwendung natürlich auch, wir schaufeln mit den Cypress FX2 knapp 40MBye/s zum PC. Allerdings auf Anforderung mit BULK, da geht nix verloren. Für eine Live- Verarbeitung ist das aber auch mächtig viel. Ein Rechner mit TerraFlops klingt immer schnell, aber alles, was über externe Busse geht, ist wesentlich langsamer. Man kann einen Core i7 mit einem konstanten Datenstrom von 30MB/s locker soweit überfahren, dass ein paar Cores voll ausgelastet sind. 200MB/s von einer HDD auf die andere schaufeln ist dagegen keine Kunst...
Der ftdi treiber hat schon einen puffer, ein paar megabyte glaubich. Abholen musst du die Daten dann schon irgendwann. Wenn du dann ein neues Bild fertig geladen hast, musst du dem openGL treiber sagen, dass er es in seinen TexturRAM kopieren soll. Ab da muss der Prozessor dann sich nicht mehr damit abmuehen, das macht dann die GRAKA.
Sam schrieb: > Am PC will ich die Daten entgegennehmen, filtern und in einem Fenster > ausgeben. Aber das wird so nicht funktionieren, weil der PC vermutlich > nicht nachkommt. dazu muss man wissen - wie komplex die Filter sind. Ein PC kann ein Video mit 720x576x32bbp bei 25fps darstellen das sind 31Mbyte/s und damit ist er nicht ausgelastet, dazu kommt auch noch der Sound. Wenn deine Filter als nicht extrem Komplex sind, dann sind die 30Mbyte/s überhaupt kein Problem für eine aktuelle CPU.
Sam schrieb: > OK, es geht um einen Sensor, der mir ca. 30 MBit/s an Daten liefert. Am Rande gefragt: Was ist das für ein Sensor? Ansonsten: 30 MBit/sec sind knapp 4 MByte/sec, das ist eine Datenrate, die bessere SD-Karten als Schreibdatenrate hinbekommen. Ein auch nur mäßig aktueller PC schafft das locker; das auf dem PC laufende Programm sollte halt mit ausreichend dimensionierten Puffern arbeiten, um kurzzeitige "Schluckaufs" wegen Taskwechseln o.ä. zu kompensieren, und sinnvollerweise das Lesen per USB und das Weiterverarbeiten der gepufferten Daten in unterschiedlichen Threads organisieren.
@blob: Multithreading ist eine gute Idee. Da werde ich nicht drumherum kommen. Du sprichst von "ein paar Tricks" - welche denn noch? @Floh: Berechtigter Einwand. Die Hardware läuft auch noch nicht. Notfalls gehe ich mit der Sample-Rate runter. Aber auch bei 1 MByte bekomme ich vermutlich Probleme. @David:"Also hör auf mit den Überlegungen" - ich verstehe nicht, was du damit sagen willst. Das Problem ist nicht der Speicher, sondern der PC. Dadurch, dass Windows ein Multitasking-System ist, habe ich immer nur gewisse Zeitslots für meine Anwendung. Und wenn die dann nicht in der Lage ist, die Daten schnell genug aus dem USB Puffer auszulesen (weil z.B. grade irgendein anderer Task dazwischen funkt), dann werden diese Daten einfach überschrieben.
Sam schrieb: > Aber auch bei 1 MByte > bekomme ich vermutlich Probleme. jetzt hoer aber auf. da kann der 486 schon mehr!
probiers aus. wenn nicht, gibt es immernoch linux. ein echtes multitasking programm!
blob schrieb: > wenn nicht, gibt es immernoch linux. ein echtes > multitasking programm! naja dann ist windows doch besser, das ist das ganze Betriebssystem Multitasking fähig nicht nur ein Programm.
du hast nen zwischenspeicher in deinem PC. Du musst nicht jede ms ran. Ist aber auch kein Problem, solltest du nicht gerade youtube videos anschaun sondern wirklich nur das eine Programm laufen lassen. Wir gehen mal von einem frisch installierten XP aus! Ist klar, dass es nicht mehr geht, wenn du erstmal x spywareprogramme drauf hast. bei 1GHz bleiben dir 33 takte pro zu empfangendem byte. Davon muss natuerlich der ganze overhead abgezogen werden, den das taskgeswitche verbraucht und ich weiss auch nicht, ob mit jedem takt ein befehl ausgefuehrt wird, aber es sollte doch reichen! Kommt natuerlich drauf an, was du nun mit den Daten machen willst. Was ist das jetzt fuer ein sensor und meintest du MByte oder Mbit?
Peter II schrieb: > naja dann ist windows doch besser, das ist das ganze Betriebssystem > Multitasking fähig nicht nur ein Programm. nunja linux ist doch auch nur ein programm.
juhu keiner schreibt mehr. ich hab den thread gekillt. war eh quatsch. erzaehlt uns hier einen vom Pferd! und sowas pessimistisches. Warum sollte es denn nicht gehen? Und gesagt, was er genau will, hat er auch nciht. Sicher so ein top secret project.
Ich habe schon gewisse Erfahrungen mit einem HID-Gerät gemacht. Das Ganze lief mit ca. 10 kByte/s. Wenn ich da jeden Datensatz im Fenster ausgegeben habe und gleichzeitig im Netz surfte (also Fenster hin- und hergeschaltet wurden), dann konnte es vorkommen, dass ein paar Bytes verloren gingen. Bei der Ausgabe von nur jedem 100ten Datensatz war das kein Problem. Auch wenn der PC sonst nichts zu tun hatte funktionierte alles einwandfrei. Soviel zum Thema Multi-Tasking.
ja weil du bei jeder Ausgabe unter Windows das ganze Fenster neu zeichnen musst (mit GDI zumindest) da kommen bald ein paar GByte traffik zusammen, auch wenn du nur ein paar strichlein zeichnest. ist halt nicht ideal. Deshalb solltest du die datenaquise von der datenverarbeitung trennen und die ausgabe auf 10 mal/ sekunde beschraenken.
Sam schrieb: > Das > Ganze lief mit ca. 10 kByte/s. Wenn ich da jeden Datensatz im Fenster > ausgegeben habe und gleichzeitig im Netz surfte (also Fenster hin- und > hergeschaltet wurden), dann konnte es vorkommen, dass ein paar Bytes > verloren gingen. das ist eine Frage der ausgabe. Wie hast du es denn ausgegeben? GDI+ genutzt um einen Text auf den Bildschirm zu bekommen? Oder nur dumm ein Memofeld in VB erstellt und dort den Text immer angefügt? Es gibt halt verschiende möglichkeiten etwas darzustellen, aber keiner hat ihr eine Ahnung was du genau machen willst. Du bist der einzigste der immer behauptet es geht nicht. Wenn es nicht geht dann liegt es aber nicht am PC sondern an der Art und weise wie du es bis jetzt gemacht hast.
dann solltest du unbedingt nicht das eingabegeraet pollen, sondern mit ner callbackfunktion arbeiten. dh der ftdi treiber ruft deine funktion auf, sobald genuegend daten angekommen sind. So musst du nicht den eingang in einer Endlosschleife staendig abfragen und kannst im Hintergrund die Verarbeitung machen.
Zum "top-secret"-Projekt: es geht um eine Hardwareschnittstelle, die eine möglichst große Übertragungsrate am USB realisiert. Dabei spielt eher das Konzept, als die eigentliche Anwendung eine Rolle.
Ich habe damals einen Dialog erstellt und dann die Daten zeilenweise in einer Listbox ausgegeben.
Sam schrieb: > Ich habe damals einen Dialog erstellt und dann die Daten zeilenweise in > einer Listbox ausgegeben. das kann schon das Problem gewesen sein, bei einigen Programmiersprachen wird der neue String an den alten String angehängt, dafür muss aber der alte String in einen neuen Speicherbereich kopiert werde. Das müsste man schon sehen wenn es am ende immer langsamer wird. Aber wie schon oben geschrieben, man sollte eh die verarbeitung der Daten und die Anzeige entkoppeln, damit gehen auch keine Daten verloren wenn die Anzeige gerade mal nicht hinterher kommt. Und 30Mbyte/s als text auf einen Bildschirm darzustellen macht überhaupt keinen Sinn, weil es kein Mensch lesen könnte. Also sag entlich mal genau was wie oft dargestellt werden muss.
So absolut pauschale Aussagen "das geht auf jeden Fall" sind völlig unangebracht, denn Linux, Windows, MacOS sind alles keine echtzeitfähigen Betriebssysteme. Unter Windows XP haben wir mit dem kontunierlichem USB Streaming zwar im Mittel eine Datenrate von knapp 40MByte/s, allerdings geht das nur mit BULK und großen Puffern auf der Hardware, denn Windows setzt gerne mal für 50ms oder mehr den USB Transfer aus. (Linux übrigens auch). USB ist recht niedrig priorisiert und erst bei USB 3.0 wurde das Polling abgeschafft. Es kommt also auf die ganz spezielle Anwendung an. Auf jeden Fall muss man Daten sammeln, Daten verarbeiten, Daten speichern und Daten anzeigen voneinander trennen. Da braucht man einige Threads, die asynchron laufen. USB Datentransfer muss übrigens auch alles durch die CPU, DMA gibts erst bei USB 3.0 (EHCI kann zwar auch DMA, aber meines Wissens nicht unter Win). Da geht viel Last drauf. Wenn du dann die Werte noch in Float umrechnen musst, um deine Filter zu füttern, geht noch mehr CPU Last drauf. Daten nebenbei auf Festplatte speichern, nochmal etwas. Daten sinnvoll dezimieren, um auf die Anzeige zu bringen, auch nochmal CPU.
Was ich bislang herausgelesen habe ist, dass das Nadelöhr in der Datenausgabe liegt und eher nicht am USB bzw. der Datenpufferung. Ich muss das wohl einfach mal ausprobieren. Vielen dank für die rege Teilnahme.
Wobei mich Christian gerade wieder in meinem "Vorurteil" bestärkt hat.
Sam schrieb: > Wobei mich Christian gerade wieder in meinem "Vorurteil" bestärkt hat. du hattest schon probleme mit 10 kByte/s und konntest sie nicht lösen. Das da war bestimmt nicht USB das Problem.
Naja bei HID kann ich den Empfangspuffer auf 512 Pakete hochschrauben. Wenn man mal von 1ms/Paket ausgeht, dann reichen schon 0,5 Sekunden an "Nebenbeschäftigung" des PC's, um beim Auslesen nicht mehr nachzukommen.
Ich habe gerade mal den FT2232 angeschaut, dort steht nur etwas von USB 2.0 Full Speed (12M bits/second) compatible wie willst du da 30Mbyte/s oder doch 30Mbit/s übertragen?
FT2232H - das "H" habe ich im Thread-Titel vergessen, aber in meinem ersten Post findest Du es.
Sam schrieb: > dann reichen schon 0,5 Sekunden an > "Nebenbeschäftigung" des PC's, um beim Auslesen nicht mehr nachzukommen. ja und? 0.5 klingt zwar wenig ist über für einen PC eine ewigkeit. In der Zeit kann die CPU mehrfach in den Sleepmodus gehen! Brauchst doch nur mal die Maus anzuschauen, hast du dort jemals eine verzögernung von 1/2 sekunde beobachtet?
Peter II schrieb: > Sam schrieb: >> dann reichen schon 0,5 Sekunden an >> "Nebenbeschäftigung" des PC's, um beim Auslesen nicht mehr nachzukommen. > ja und? 0.5 klingt zwar wenig ist über für einen PC eine ewigkeit. In > der Zeit kann die CPU mehrfach in den Sleepmodus gehen! Brauchst doch > nur mal die Maus anzuschauen, hast du dort jemals eine verzögernung von > 1/2 sekunde beobachtet? Das Userland kann schonmal für die Zeit aussetzen, wenn ein Prozess den RAM vollhaut und das Paging einsetzt. Ja, solche Verzögerungen können auftreten, alles schon gesehen. Oder wenn du eine billige SSD hast, die dann mal für 500 ms nachdenkt. Such mal nach bestimmten OCZ-Festplattenserien, da haben viele Nutzer aufgeschrien, weil ihr Windows für diese Hunderte von Millisekunden komplett stehenbleibt. Es gibt viele Möglichkeiten, wieso ein „normales“ Betriebssystem für viele ms einen Prozess nicht mehr ausführt, deswegen gibt's halt keine Garantien für gar nichts. Wie viele Befehle moderne CPUs in der Zeit abarbeiten könnten, ist irrelevant, wenn man auf andere Komponenten wie die Festplatte oder einen Netzwerktranfer wartet. Der Verweis auf Echtzeitbetriebssysteme kam schon. Allerdings: In 99% der Fälle wird sowas mit Bulk-Transfers (wie sie der FT2232H benutzt) schon funktionieren, und im anderen 1% schieben sich dann alle Beteiligten den schwarzen Peter gegenseitig zu. ;)
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.