mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Cypress USB Controller


Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: sechnullfuenf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der USB Controller ist ein Ding, der PC Treiber das Andere. Mir scheint 
der USB Controller das Einfachere zu sein.

Autor: Uwe Bonnes (Firma: TU Darmstadt) (uwebonnes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Mir ist noch unklar, [...] welches Datum von welchem ADC kommt.
hä?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke mal er meint Daten.

Autor: Uwe Bonnes (Firma: TU Darmstadt) (uwebonnes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@snowman: Ein Datum, viele Daten

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Düsentrieb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olly Krings (rossi75)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian G. (badscher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian G. (badscher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian G. (badscher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.