Hi, ich beschäfftige mich gerade mit der Datenübertragung mittels USB. Ziel bei meine Projekt ist es, digitalisierte Daten mittels USB an einen PC zu übertragen. Hierbei handelt es sich um 4 ADC's =>Datenmenge ca. 2MByte/s. Da später jedoch auch andere ADC's eingesetzt werden sollen, können die Produkte von FTDI nicht mehr verwendet werden. Aus diesem Grund viel mein Blick auf den CY7C68014A. Wer hat mit diesen Baustein Erfahrungen und kann mir ein bisschen was dazu erzählen? Es sollen also von 4 ADC'S die Daten zum USB Controller gehen und dann per USB gesendet werden. Was muss ich hierfür tun? Müssen Treiber für Windows selber entwickelt werden, oder reichen die von der Cypress Homepage aus? In wieweit muss mit den internen 8051 gearbeit werden und wie wird dieser ggf. programmiert? Welchen Zeitaufwand würdet ihr bei mittelmäßigen Kennnissen in diesem Bereich schätzen? Danke schonmal.
Noch ein kleiner Zusatz. Die maximalste Datenrate die durch andere ADC's entstehen können liegt bei ca. 8MByte/s. Auch für Hinweise auf andere USB Controller, mit welchen man schnell zu Ergebnissen kann bin ich sehr dankbar.
Der USB Controller ist ein Ding, der PC Treiber das Andere. Mir scheint der USB Controller das Einfachere zu sein.
Schau mal unter Gnuradio, USRP und SSRP nach. Dass alles sind Projekte, die den FX2 als Datenpumpe einsetzen. Je nach PC USB Chip werden auch mal 40 MByte/s am PC empfangen. Ich will auch etwas aehnliches machen, stolpere dabei aber noch ueber das Problem, den Datenstrom zu strukturieren. Mir ist noch unklar, wie ich am PC herausbekommen, welches Datum von welchem ADC kommt.
Danke für die Tipps....werd ich mir gleich mal anschauen. Das mit dem Datenstrom struktuieren wird auch noch auf mich hinzukommen, da ich später am PC alle vier Kanäle wieder trennen möchte.
Ich habe mich jetzt noch weiter intensiv gesucht und gelesen (auch hier im Forum ;-)). Hab aber trotzdem einige Fragen bzw. bin mir nicht sicher ob ich es richtig verstanden habe. Um den Baustein verwenden zu können benötige ich eine Firmware. Diese Firmware wird bei anstecken des USB Kabels in den PC zum Cypress Chip übertragen. Hiermit können auch die entsprechenden Funktionen die ich mit dem 8051 ausführen möchte in den Baustein geladen werden, da diese in der Firmware gespeichert sind. Die Firmware wird mir von Cypress in Form der CyUSB.dll zur Verfügung gestellt. Diese bietet kann entsprechende Funktionen um Register etc. des 8051 zu beschreiebn oder ähnliches. Was bietet mir die Firmware von Braintechnology anderes? Muss ja einen Grund haben warum diese 40€ kostet. Ich hoffe ihr könnt meinen Ausführungen bestätigen oder ggf. korrigieren.
Also, die Firmware musst du selber scheiben. Standardmäßig wird nix auf den 8051 übertragen. Es gibt aber von Cypress jede Menge Beispielsoftware für die 8051 Firmware. Die kannst du dann mit der kostenlosen Version des µVision selber schreiben. Ist nicht besonders schwer. Die Firmware von Braintech ist halt schon fertig. Ahso, man kann es so einstellen, dass die Firmware beim Anstecken in den RAM des Cypress geladen wird, eleganter ist es aber, die im externen EEPROM zu speichern und dann lädt der sich selbst die Firmware da raus, und meldet sich gleich passend nach deinen Vorgaben am Windows. Such mal hier im FPGA FOrum, da hatten wir das mal. Zwar mit 68013, aber ist ja der gleiche Chip. Die DLL, die es gibt, geht nur für managed Code, also auf .NET BAsis, C# oder VB.NET. Für C++ gibts eine statische Lib, klappt aber mit der auch gut. Ohne selbstgeschriebene Firmware oder eben die von Brain ist der 8051 dumm und macht gar nix.
Den Thrad im VHDL Forum hab ich gelesen, war zum Teil sehr aufschlussreich. Also scheint die Variante mit Braintechnology nicht schlecht zu sein. Aber was biete mir bzw. stellt mir die die CyUSB.dll von Cypress eigentlich zur Verfügung?
könnte man nicht ein usb-ide interface nehmen, externe usb2 gehäuse gibts ja schon ab 10eu... + kein treiber-problem, meldet sich ja als drive an daten-transfer mit read-sector xx ... + keine programmierung des ez-usb, is ja schon drin
Na die DLL stellt dir die Kommunikation mit dem Chip an sich zur Verfügung. Das ist ja kein Gerät, wofür Windows-API Funktionen existieren. Irgendwie musst du ja deine Daten von und zum USB Gerät schaufeln. Das macht die DLL.
Spricht den grundsätzlich etwas gegen die Braintechnology Variante, außer das es ein paar Euros kostet? Ich denke mal ein zwei Tag Zeiteinsparung kann man sich somit schon "erkaufen".
Wenn das für deine Anwendung passend ist, dann ist es ja OK. Bei uns hatte das irgendwie nicht gepasst, deswegen haben wir ne eigene Firmare geschrieben. Außerdem wollen wir unser Zeug auch mal verkaufen, da wirds dann mit 40€/Gerät schon bissl teuer. Achja, denk dran, wenn du das USB Gerät irgendwie veräußern willst, brauchst du zwigend eine eigene Vendor ID, die mit min. 2000 US$ zu Buche schlägt.
Christian R. wrote: > Achja, denk dran, wenn du das USB Gerät irgendwie veräußern willst, > brauchst du zwigend eine eigene Vendor ID, die mit min. 2000 US$ zu > Buche schlägt. es gibt einen "händler" in den niederlanden, er hat sich eine VID geakuft und verkauft die PIDs Blockweise. Insgesamt haben wir alle was davon. Die Adresse: voti.nl oder voti.nl/pids.
Hallo, Ich würde gerne diesen Thread wiederbeleben da dieses Thema für mein Problem anscheinend sehr gut geeignet ist. Mein CycloneII FPGA ließt aus einem ADC(AD7656-1) mit 200kSps die 6 Kanäle, je zu 16bit aufgelöst, aus und speichert diese auf einem chipinternen ausreichend großen FIFO zwischen. Diese Daten wiederum werden mit 12,5MHz(80ns) zum USB Controller übertragen Ich habe einen vorkonfigurierten USB Controller (CY7C68013A) der eigentlich auf highspeed getrimmt sein sollte. eine Testsoftware ließt, möglichst kontinuierlich, diese Werte aus, die dann mit Matlab einfachst ausgegeben werden. Mit anliegenden Sinussignalen verifiziere ich die Qualität der Datenakquise. Und genau da liegt mein Problem. Bei 6 akqurierten Kanälen ist die Übertragung zu langsam, d.h. die Eingangssignale werden nicht vollständig Übertragen. es scheint gerade so zu sein, dass die Samplefrequenz (200kSps * 6 Kannäle * 2 byte = 2,4Mbyte/s) zu schnell für die USB übertragung(bis zu 50Mbyte/s angeblich) ist. Und so das Signal teilweise abgeschnitten wird. Nach einigen Test bin ich mir fast sicher, dass es nicht an der Hardware liegen kann. meine Frage ist nun, was muss ich auf Seiten der software beachten um eine schnellst mögliche Datenübertragung zu gewährleisten. Grüße, Flo
Wie groß ist "ausreichend groß" deines Puffers-FIFOs? Wir erreichen die 40MB/s, die maximal möglich sind, dauerhaft auch nicht. Eine kontinuierliche Dauer-Transferrate von 35...38MiB/s schaffen wir, allerdings mit riesigen FIFOs...nämlich 128ki Worte. Dann kommts drauf an, wie du ausliest. Wenn du immer nur 512 Byte pro Lesebefehl verlangst, erreichst du maximal 4MB/s etwa. Du musst gleich riesengroße Blöcke lesen, vielfache von 512 Byte, dann wirst du schneller. Dann musst du noch die KernelTransferSize hochsetzen, 128kiByte ist laut unseren versuchen ein guter Wert. Wir haben hier ein ständiges Master-Slave Spiel, der PC startet die Messung und fordert die Daten an, damit schaffen wir nur bei der genannten starken Pufferung hohe Transferraten. Alles im allen haben wir aber einige Monate probieren müssen, das FPGA-Design ist auch entscheidend, da gibts viele viele Fallstricke und Bremsen.
super, danke für die schnelle Antwort Christian R. schrieb: > Wie groß ist "ausreichend groß" deines Puffers-FIFOs? Wir erreichen die > 40MB/s, die maximal möglich sind, dauerhaft auch nicht. Eine > kontinuierliche Dauer-Transferrate von 35...38MiB/s schaffen wir, > allerdings mit riesigen FIFOs...nämlich 128ki Worte. 16384x16bit ist das FIFO groß > Dann kommts drauf an, wie du ausliest. Wenn du immer nur 512 Byte pro > Lesebefehl verlangst, erreichst du maximal 4MB/s etwa. Du musst gleich > riesengroße Blöcke lesen, vielfache von 512 Byte, dann wirst du > schneller. die EP buffer sind nur 2x 512byte groß, wie soll da zum einen mehr rein und zum anderen wie soll ich da mehr als vorhanden rauslesen? Habe eben mal 5120 byte auf einen Streich auslesen wollen und nach den 512byte kommt erst mal nichts brauchbares dabei raus. Außerdem würden mir 4MB/s vollkommen langen wenn ich mich vorhin nicht verrechnet habe. g > Dann musst du noch die KernelTransferSize hochsetzen, 128kiByte ist laut > unseren versuchen ein guter Wert. Wie mach ich das? :) > Wir haben hier ein ständiges Master-Slave Spiel, der PC startet die > Messung und fordert die Daten an, damit schaffen wir nur bei der > genannten starken Pufferung hohe Transferraten. Alles im allen haben wir > aber einige Monate probieren müssen, das FPGA-Design ist auch > entscheidend, da gibts viele viele Fallstricke und Bremsen. wie gesagt, ich schreibe die USB buffer von der hardwareseite aus mit 12,5MHz voll, was reichen sollte. Für 2 anäle funktioniert das systema uch wunder bar. Nur bei mehr als den zwei geht der datendurchsatz flöten.
Florian G. schrieb: > super, danke für die schnelle Antwort > > Christian R. schrieb: >> Wie groß ist "ausreichend groß" deines Puffers-FIFOs? Wir erreichen die >> 40MB/s, die maximal möglich sind, dauerhaft auch nicht. Eine >> kontinuierliche Dauer-Transferrate von 35...38MiB/s schaffen wir, >> allerdings mit riesigen FIFOs...nämlich 128ki Worte. > > 16384x16bit ist das FIFO groß Hm, sowas in der Größe haben wir hier bei einem kleineren Gerät. Ich hab gerade mal gemessen, damit schaffen wir eine durchscnittliche Dauer-Transferrate von knapp 30MiByte/s. Der FX2 ist auf dem IN Endpoint Quad-Buffer, also 4x512 Byte. Angeliefert wird mit 40MHz externem Takt. >> Dann kommts drauf an, wie du ausliest. Wenn du immer nur 512 Byte pro >> Lesebefehl verlangst, erreichst du maximal 4MB/s etwa. Du musst gleich >> riesengroße Blöcke lesen, vielfache von 512 Byte, dann wirst du >> schneller. > > die EP buffer sind nur 2x 512byte groß, wie soll da zum einen mehr rein > und zum anderen wie soll ich da mehr als vorhanden rauslesen? Habe eben > mal 5120 byte auf einen Streich auslesen wollen und nach den 512byte > kommt erst mal nichts brauchbares dabei raus. Das geht, zumindest mit dem CyUSB Treiber und der CyAPI. Du kannst fast beliebig viele 512Byte Blöcke auf einmal anfordern, der Treiber wartet dann, bis er die zusammen hat und kommt damit (oder mit TimeOut) zurück. Klappt perfekt bei uns. Wir bauen z.B. einen Block auf 16 mal Messdaten variabler Länge (typisch jeweils 10.000 Samples) zusammen und setzen erst ganz am Ende das PacketEnd. Diesen ganzen Block kann man mit einem einzigen Lesebefehl abholen. > Außerdem würden mir 4MB/s vollkommen langen wenn ich mich vorhin nicht > verrechnet habe. *g* Das langt eben nicht, um 2,4MB/s ohne Aussetzer zu übertragen, muss deine Transferrate um einiges höher sein.... >> Dann musst du noch die KernelTransferSize hochsetzen, 128kiByte ist laut >> unseren versuchen ein guter Wert. > > Wie mach ich das? :) Dafür gibts in der CyAPI einen Befehl. >> Wir haben hier ein ständiges Master-Slave Spiel, der PC startet die >> Messung und fordert die Daten an, damit schaffen wir nur bei der >> genannten starken Pufferung hohe Transferraten. Alles im allen haben wir >> aber einige Monate probieren müssen, das FPGA-Design ist auch >> entscheidend, da gibts viele viele Fallstricke und Bremsen. > > wie gesagt, ich schreibe die USB buffer von der hardwareseite aus mit > 12,5MHz voll, was reichen sollte. Für 2 anäle funktioniert das systema > uch wunder bar. Nur bei mehr als den zwei geht der datendurchsatz > flöten. Damit bekommst du maximal 25MB/s in den FX2, wenn du das 16 Bit Interface nutzt. Sollte reichen.
Achso: Wenn du natürlich vorher genau weißt, wieviele Daten pro Block anliegen, kannst du die auch genau abholen, also nicht unbedingt auf 512 Byte Grenze. Aber der Treiber kommt dann sowieso zurück, sobald das PacketEnd gesetzt wurde, gilt ein Transfer als abgeschlossen.
Christian R. schrieb: > Achso: Wenn du natürlich vorher genau weißt, wieviele Daten pro Block > anliegen, kannst du die auch genau abholen, also nicht unbedingt auf 512 > Byte Grenze. Aber der Treiber kommt dann sowieso zurück, sobald das > PacketEnd gesetzt wurde, gilt ein Transfer als abgeschlossen. vielen Dank soweit für deine Antworten. Und ich glaube genau dieser Ansatz ist für mich der entscheidene. z.Z. lade ich 240x16 Wörter /480byte) in den EP buffer und setze danach das pkt_end. Mein FPGA erkennt durch flagb ob das FIFO voll ist, wenn nicht schiebt er das nächste 480byte paket hinter her, automatisch. Jetzt ist mir noch nicht klar. wenn ich das pkt_end nach den 480byte setze, kann ich dann gar nicht mehr als 480bye mit einem Leseanweisung holen? so sehen nähmlich z.Z. meine Testergebnisse aus. Oder soll ich einfach das pkt_end erst gar nicht anlegen und den fpga einfach den EP FIFO bis unter den Rand füllen lassen?
Stimmt. Sobald das PktEnd gesetzt ist, endet die Transaktion. Du musst also erst nach x Paketen das PktEnd setzen, um schneller zu werden. Wenn du immer nur so wenig Daten pro Paket hast, kann der nicht schnell werden, denn dann hast du einen ganzen MicroFrame (125µs) für deine 480Byte verschwendet. Weglassen geht aber auch schlecht, das kommt zu ganz seltsamen Treiber-Verhalten dann. Du kannst ja testweise mal einen zusätzlichen Zähler in den FPGA bauen, der erst nach 10 Paketen oder so das PktEnd setzt. Und dann kannst du gleich 4800Byte pro Transaktion anfordern.
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.