www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Projekt: Cypress USB FX2 an FPGA; Timing Analyse für FSM


Autor: FPGA-Fragender (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich bin gerade dabei einen Cypress CY7C68013A FX2 High Speed USB 2.0 an 
einen FPGA Spartan 3 anzubinden.

Hier der Link zum Technischen Manual:

http://download.cypress.com.edgesuite.net/design_r...

Die Datenkommunikation kann beim FX2 auf 3 Arten passieren. Für den 
geforderten Mindesdurchsatz von 15 MByte/s bis 20 MByte/s kommt nur die 
Anbindung als SLAVE-FIFO in Frage.

Unter Umgehung des FX2 internen Mikrocontrollers und der GPIO 
programmierbare State Machine werden die Fifo Speicher direkt vom FPGA 
gelesen bzw. geschrieben.

Nun hab ich die entsprechenden Datenblätter durchgearbeitet und die 
vielen Timing Diagramme analysiert.

Beispiel: Im o.g. Manual Seite 50

10.17.1 Single and Burst Synchronous Read Example

In der Anlage hab ich einen ersten Timing Entwurf. Der mein Verständnis 
der Signale untereinander reflektiert. Ob das aber wirklich stimmt ?


Grundkonzept:
=============

Der Takt des FPGA beträgt 50 MHz. Der maximale Eingangstakt des FX2 
beträgt 48 MHz. Ich möchte den Takt des FPGA teilen den FX2 mit 25 Mhz 
synchron zum FPGA Takt laufen lassen.

Durch den doppelten FPGA Takt ist es dann leichter möglich auf die 
entspechenden Timing Mindest und Maximal Zeiten einzugehen.

Ich hoffe, dass noch mehr an diesem Thema interessiert sind und wir 
mglw. gemeinsam eine lauffähige FSM auf der FPGA Seite entwickln können.

Wenn jemand bereits eine lauffähige Lösung in VHDL hat wäre das 
natürlich super. Ich hab leider auch nach vielem suchen nichts gefunden.

Also in der Anlage ist das Timing Diagramm von mir und hier die 
Erklärung dazu.

t=0
SLCS wird aktiv Low und leitet den Lesevorgang ein
FiFo ADR wechselt gleichzeitg auf die zu lesende Endpoint Fifo Adresse
t SFA mit mind. 25 ns wird mit 60 ns eingehalten
t=A
nach spätstens t XFLG = 10,7 ns nehmen die zu dem Endpoint gehörenden 
Flags die gültigen Werte an. ( Beispiel: Fifo ist leer, voll usw. )
t=A + 5
nach spätstens t XFD = 15 ns nehmen die zu dem Endpoint gehörenden Daten 
gültige Werte an. ( Sind duch Output Enable aber noch nicht freigegeben 
)
t=1
der Wert der Flags wird vom FPGA synchron mit steigender Flanke 
eingelesen ( ja nach Wert geht die State Machine des FPGA in einen neuen 
Folgestate )
aufgrund der Tatsache, dass kein aktives SLRD Signal anliegt, wird mit 
der aufsteigenden Flanke von IFCLK der interne Fifo Adresszähler nicht 
weitergezählt
t=2
Der Fifo ist nicht leer das SLRD Signal wird aktiv. Die Geforderte t SRD 
= 13 ns (minimal ) wird mit 20 ns eingehalten
SLOE wird aktiv geschaltet, die Daten werden nach spätestens t Oeon=10 
ns gültig.
t=C
Die Daten sind jetzt aktive auf dem Datenbus und können in den FPGA mit 
der nach 10 ns folgenden Flanke übernommen werden.

T = 3
Die gültigen Daten werden in den FPGA übernommen.

IFCLK hat steigende Flanke und SLRD ist aktiv mit gülitger t SRD 
vorlaufzeit. Somit wird der interne FiFO Counter weitergezählt
T =D+5
Die Flags nehmen evtl. einen neuen gültigen Wert an ( es könnte sein der 
FIFO ist jetzt leer geworden ).
T XFLG = max 14 ns wird eingehalten, weil die Flags erst 6 ns später vom 
FPGA mit Flanke eingelesen werden.

Die Daten nehmen nach t XFD = 15ns (maximkal) die neuen Werte an, auf 
welche der weitergezählte FIFO Counter zeigt

t=4
Die Flags werden vom FPGA übernommen und in der State machine 
ausgewertet.
t = 5
Die Daten werden vom FPGA mit steigender Flanke übernommen.
t= 6
Die FIFO Adressen könne für den nächsten Lese oder Schreibzugriff 
geändert werden t FAH = 10 ns ( minimal ) wird mit 20 ns eingehalten

SLRD = wird inaktiv.
T RDH = 4 ns ( minimal ) wird mit 20 ns eingehalten.

Ich hoffe jemand hat bis hierher gelesen.

Ich bin für jede Hilfe dankbar, denn alleine krieg ich das nicht hin.

Wer kennt sich mit dem Baustein aus ?

Im Forum wurde zwar schon darüber diskutiert, aber noch nie im Detail, 
wie man eine passende FSM dazu entwirft.

Gruß vom FPGA-Fragenden

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh genau das will ich auch machen. Bis jetzt hatte ich den Cypress SX2, 
aber dafür gibt es so gut wie keine Windows Treiber, deshalb werde ich 
auch auf den FX2 umsteigen müssen. Ich werde mich morgen ein wenig damit 
geschäftigen, dann könnten wir gemeinsam am Projekt arbeiten

Grüsse

Sebastian

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sebastian,

freut mich echt, dass sich doch noch jemand gemeldet hat.

Das o.g. Timing Diagramm zu zeichnen hat mich ein paar Stunden gekostet, 
aber ich dachte das wäre mal ein guter Einstieg, um sich über die 
Problemantik zu unterhalten.

Bei dem o.g. Lösungsvorschlag gibt es meiner Meinung nach noch einen 
Hinkefuss.

Auswerten der Flag Signale
===========================

Die 3 Flag Signale geben an, ob der über die Adressleitungen ausgewählte 
FIFO entweder:

- leer
- voll
- einen vom Anwender festgelegten Füllstand hat

Nun wollte ich eigentlich bei der FSM eine Lösung finden die

- einerseits einen schnellen Bulk Datenfransfer zulässt
  ( Burst schreiben, lesen )
- vor jedem Lese bzw. Schreibzugriff die Flags abfragt.

Also eine Lösung die z.B. folgendes zulässt.

Schreibe so lange Daten im Burst Mode vom FPGA in den Controller bis das 
Flag FIFO = voll aktiv wird.

Das Problem besteht nun darin, dass die Flags wie Du im Timing Diagramm 
erkennst eine relativ hohe Delay Time haben 15 ns .

Mit t=4 wird der Status gültig eingelesen mit t=5 das SLRD Signal bei 
FIFIO = leer wieder deaktiviert. Das ist allerdings zu spät. Der Zugriff 
würde einen unerwarteten Fehler auslösen. ( welchen ?? keine Ahnung, ist 
nicht dokumentiert )

1. Lösungsvorschlag

FPGA Takt verdoppeltn auf 100 MHz, dann wäre ein Zwischenschritt 
vorhanden in dem man taktsynchron das SLRD bei einem Fehlversuch zu 
lesen deaktivieren könnte.

2. Lösungsvorschlag

Nur Lesen und schreiben in ganzen Frame Größen = 512 Byte

Am Anfang des Transfers die Flags prüfen uns alle Daten nacheinander 
ohne Abfrage der Flags übertragen. ( ob das günstig ist ??? )

Soweit mal meine Gedanken

Gruß vom FPGA-Fragenden

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab da auch mal eine recht grundsätzliche Frage dazu. Muss ich mir 
für die Anbindung des 68013 an einen FPGA/CPLD im Slave-FIFO Modus auch 
die Firmware für den 8051 Core selber schreiben? Irgendwie hab ich auf 
der extrem grottigen Cypress Seite dazu nicht besonders viel gefunden.

Oder gibts da eine Firmware, die ich da einfach reinladen kann?

Und wie passiert der Firmware-Upload beim 56-Pin Gehäuse? Wird der jedes 
Mal per USB hochgeladen? Gibt man das dann im Treiber-File an? Oder kann 
man die Firmware im externen I2C EEPROM ablagen?

Stehe bald auch vor der Aufgabe, den 68013 an einen Spartan 3(E) 
anzuschließen, um von einem Messsystem schnell Daten in den PC zu 
übertragen.

Danke im Voraus für Infos.

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

wie Du aus meinen bisherigen Beiträgen entnehmen kannst bin ich selbst 
kein Profi.

Trotzdem mal ein paar (hofftenlich richtige) Antworten

1. Muss ich mir für die Anbindung des 68013 an einen FPGA/CPLD im 
Slave-FIFO Modus auch die Firmware für den 8051 Core selber schreiben?

Nein ! Es genügt ( unter Windows ) zuerst eine Sys Treiber zu 
installieren und dann entweder über die alte EZUSB.dll  oder den neueren 
CyUSB.dll mit dem Sys Treiber und damit direkt mit der Firmware des 
68013 zu kommunizieren.

Alternativ kann man auch Libusb für Windows benutzen. ( Open Source )

Die CyUSB.dll kann in verschiedenen Hochsprachen z.B C# direkt 
eingebunden werden. ( Die API dafür kann auf der Cypress homepage 
runtergeladen werden )

Das Setzen von entsprechenden Registern veranlasst den Baustein dann in 
den verschiedenen Modi zu arbeiten.

2. Und wie passiert der Firmware-Upload beim 56-Pin Gehäuse? Wird der 
jedes
Mal per USB hochgeladen? Gibt man das dann im Treiber-File an? Oder kann
man die Firmware im externen I2C EEPROM ablagen?

Die Firmware kann beim hochlaufen des Bausteins entweder aus dem EEPROM 
oder über USB geladen werden. Ohne EEPROM geschieht das Hochladen nach 
jedem Reset. ( Soweit mein Kenntnisstand )

Gruß vom FPGA-Fragenden

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke schon mal für die Antworten. Klingt erst mal gut, aber:

>> Die Firmware kann beim hochlaufen des Bausteins entweder aus dem EEPROM
>> oder über USB geladen werden. Ohne EEPROM geschieht das Hochladen nach
>> jedem Reset. ( Soweit mein Kenntnisstand )

Woher nimmt der PC die nötige Firmware? Ganz ohne wird der 8051 ja nicht 
funktionieren. Ist die beim Treiber integriert? Oder gibts die irgendwo 
in den Tiefen der Cypress Homepage...?

Autor: Christian Peters (kron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darf ich mal fragen, womit du das Timingdiagramm gemacht hast? :)

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian R.

Soweit ich das weiß wird das Ram des 8051 mit der Firmware vom Sys 
Treiber des PC direkt "getankt" und bekommt nach diesem Vorgang ein Go.

Den Vorgang bzgl. USB Enumeration und Re-Enumeration hast Du ja 
hoffentlich schon gelesen, richtig ?

Du könntest Dich mal nach der alten Version EZUSB von Cypress umschauen. 
Der QuellCode für diesen Treiber wurde von Cypress wohl offen gelegt.
( ob allerdings nur die Dll oder auch der Sys Treiber ?? Wo man den 
findet ? Doku ? keine Ahnung !!

@Christian Peters

Ganz Simple mit Excel. Dauerte allerdings lange und ist umständlich. Für 
meinen Zweck wars trotzdem OK.

Gruß vom FPGA-Fragenden

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, habe begonnen, mich durch das Technical Reference Manual zu 
arbeiten. Allerdings nur nebenbei erst mal, da hab ich nicht gleich 
alles verstanden. Wollte mit dem USB an sich eigentlich so wenig wie 
möglich zu tun haben, das ist für uns nur Mittel zum Zweck.

Muss mal Cheffe sagen, dass ich so nen Demoboard brauche...

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte lasse dich nicht von den japanischen Text abstrecken, sondern 
schau Dir den VHDL Code an. Der Code ist nicht fuer den FX Chip, sondern 
für den FTDI Chip im FIFO Mode, aber ich hoffe es hilft Dir weiter.

Ansonsten Demo Board mit FX2 Chip + VHDL Code findet man bei einigenen 
Distris für wenig Geld.

Gruß,
Dirk

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ FPGA-Fragender

Leider hatte ich bis jetzt keine Zeit gefunden noch mal das Datenblatt 
durchzulesen.

Bis jetzt hatte ich den SX2 von Cypress. Dieser Chip macht genauch das 
gleich wie der FX2 nur kann ich nichts am µP-Programm verändern, sondern 
nur Einstellungen der Endpoints vornehmen. Jedoch hatte ich sehr große 
Problem mit dem Cypress-Treiber. Ich hatte keine vernünftige DLL bei 
Cypress gefunden und somit war es für mich nicht möglich eine 
Anzeigesoftware zu schreiben. Ich hoffe das dies durch die neuen 
DLL-Funktionen besser geworden ist.

1. Hast Du schon Erfahrungen mit dem Einbinden der neuen DLL-Funktionen 
gemacht?

2. Wie gut ist die Beschreibung der einzelnen DLL-Funktionen (wie z.B. 
Initialisierung, lesen und schreiben der Daten über USB)

3. Ist auf dem Cypress-Chip schon eine fertige Firware drauf oder muss 
man diese erst von der Cypress Homepage laden und dann aufspielen

4. Könntest Du mal Deine Konfiguration der Register posten (wie die 
Endpoints eingestellt sind, welcher Übertragungsmodus usw.)

5.Mit dem FPGA-Code kann ich sicherlich weiterhelfen, jedoch brauch ich 
nioch einige Tage Zeit für die Einarbeitung (installiere zu Hause gerade 
Windows neu).

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FPGA-Fragender

@Dirk
Danke für den Link. Hab mir die Sache mal angesehen. Ich bin 
zwischenzeitlich zu der Erkenntnis gelangt, dass einfach nichts drum 
herum führt das Technical Manual für die Hardware und Regerenze Manual 
für den Chip ( 450 Seiten ) komplett durchzuarbeiten. Dann weiß man am 
Ende auch was man tut !!!

Hier der Link

http://download.cypress.com.edgesuite.net/design_r...



@Sebastian
1. Hast Du schon Erfahrungen mit dem Einbinden der neuen DLL-Funktionen
gemacht?

Nein !!

2. Wie gut ist die Beschreibung der einzelnen DLL-Funktionen (wie z.B.
Initialisierung, lesen und schreiben der Daten über USB)

Prinzipiell wird das alles gut erklärt, aber wie üblich Theorie / Praxis 
sind 2 getrennte Dinge.


Die DLL Dateien sind für die Visual Linie von Microsoft zugeschnitten.

Können also mit Visual BAsic 2005, oder C++ oder C# problemlos 
angesprochen werden.

( Für UNIX gibt es LibUsb als Alternative. LibUsB win 32 ist ebenfalls 
verfügbar, allerdings werd ich das ganze zuerst mal mit den 
Orginalbeispielen in C# angehen )

Das hat mich dazu geführt, jetzt die Programmiersprache C# extra für das 
Projekt zu lernen. ( Wieder so ein Thema, na ja, hab mich für das 
Gesamtprojekt ( USB ist ja nur ein kleiner Teil ) auch komplett neu in 
VHDL einlernen müssen, das war allerdings "trocken Brot über Wochen" )

Also
- SW von Microsoft downloaden
- installieren
- C# tutorial durcharbeiten
- die Cypress dll mit API einbinden
- und die Online Doku der API lesen
- Beigefügte Beispiele nachvollziehen

Leider ist C# für mich gewöhnungsbedürtig.

In der Online Doku werden alle Methoden, Ereignisse usw. gut erklärt. 
Und auch Beispiel-code angeführt. Dieser allerdings nur in C#, was mich 
auf C# statt Visual BAsic geführt hat.

Du kannst dir die Developer Suite oder wie das Ding sich nennt von der 
Cypress Homepage runterladen dann siehst Du wie die API aufgebaut und 
erklärt wird.

Es ist schon gut das ganze mit einer modernen Prog Sprache wie z.B. C# 
anzugehen, weil es IN JEDEM FALL notwendig sein wird auf der PC Seite 
mit mindestens 2 Threads ( =unabhängige Prozesse oder so ähnlich ) zu 
arbeiten.

1. Thread ist nur mit dem Einlesen der Daten per USB beschäftigt.
Also Bedienung der Interrupr Routine sobald neue USB Datenpakete zur 
Entgegennahme anliegen. ( Event Handler )

2. Weiterverarbeitung der DAten ( Visualisierung bzw. Nachverarbeitung 
und Speichern auf die Platte)

------------------------------------------------------------------------ 
-

3. Ist auf dem Cypress-Chip schon eine fertige Firware drauf oder muss
man diese erst von der Cypress Homepage laden und dann aufspielen


Also nochmals zur Erklärung für jeden der hier mitlesen wird.

Mein Infostand nach wirklich sehr viel lesen:

Der Cypress Chip kann

- aus externem Eprom
    1. die Firmware komplett ( =Anwenderprog für z.B. Messtechnik )
    2. spezielle Hersteller ID = Vendor ID = VID einlesen

    ( bedeutet dann quasi für Windows z.B. ich bin eine USB Transversal
    Mega Kamera mit 10 MBit Auflösung und brauche deshalb genau den und
    den Treiber ) Dadurch werden Treiber konflikte ausgeschlossen

- mit externem Erpom ( z.B. nur 16 Byte groß )
   1. nur spezielle Hersteller ID = Vendor ID = VID einlesen sonst 
nichts
   ( d.h. keine weitere Firmware )

- ohne externes Eprom direkt über USB Sys Treiber geladen werden.
   ( Firmware kommt als Standard Firmware über den sys Treiber )
   besitzt aber auch nur Standardfunktionen

In diesem Fall:

1. Numeration
Baustein meldet sich an Windows als allgemeiner Cypress USB Baustein an 
und Windows ordnet den Cypress Sys Treiber aufgrund der standardmäßig 
hinterlegten VID usw. zu.

( Hallo ich bin ein USB Gerät von Cypress hole den passenden Sys Treiber 
.... )

2. Renumeration
Der Sys Treiber kann nun alle Konfigurationen als Standardwerte in das 
Ram des 8051 schreiben. => Standard Firmware.

Reconnect vortäuschen:

Aufgrund der internen Möglichkeit des Cypress Bausteins einen Connect / 
Disconnect durchzuführen, kann nun ein Plug and Play erneut vorgetäuscht 
werden.

Windows erkennt also dass das ursprüngliche USB Gerät entfernt wurde und 
ein neues USB Gerät hinzugefügt wurde. Jetzt allerdins wird das Gerät 
als fertig konfiguriertes, betriebsbereites USB Gerät erkannt, von 
welchem die Endpoints gelesen und geschrieben werden können usw.

Auf dieses Gerät kann nun für die API der DLL Datei über den SYS Treiber 
zugegriffen werden. !!!


WENN NUN ZUSÄTZLICH z.B. das GPIO Interface benutzt werden soll oder der 
8051 für irgendwelche Mess oder Regelanwendungen, dann muss die SW für 
diese Anwendung selbstverständlich in das RAM des 8051 übertragen 
werden.
( = Eigene FIRMWARE )

------------------------------------------------------------------------ 
-
------------------------------------------------------------------------ 
-

4. Könntest Du mal Deine Konfiguration der Register posten (wie die
Endpoints eingestellt sind, welcher Übertragungsmodus usw.)

Wuuuuaaaaahhhhhh !!!    Maaaaaammmmmi !!!

Ich hatte eigentlich gedacht, dass hier irgendwie so ganz entfernt 
vielleicht eine Form von Teamarbeit entsteht.   :-))

Ich hab noch nicht ein einziges Register im Cypress Chipp programmiert, 
weil noch eine Hardware Lieferung aussteht, auf die ich warten muss.

Gruß vom FPGA-Fragenden

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibt es ein Cypress USB 2.0 High Speed Modul inklusive eines 
Treibers. Die DLL's sind für unterschiedliche Sprachen wie C++. Die 
Beschreibung der einzelnen Funktionen sind eingentlich sehr gut

http://www.braintechnology.de/braintechnology/usb_...

Autor: FPGA-Fragender (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sebastian,

ich hab jetzt mal einen ersten Entwurf für die FSM aufs Papier gebracht.

( Das Zeichnen dauert mal wieder länger wie alles andere, na ja )

Beschreibung:

Es wird ein EP für lesen und einer für schreiben fest vorgegeben.

Der Master muss sich in meinem Fall also nicht um das auswählen des EP ( 
Adresse ) kümmern, weil beim lesen automatisch der Endpoint für Lesen 
und beim schreiben eben der definierte für schreiben ausgewählt wird.

Es ist vorgesehen nur in BULK Größen also 512 Byte zu übertragen.

Die Full Empty Flags werden also nur einmalig vor einem Block geprüft.

Der Master kann jedoch die Daten wie von einem Stream lesen bzw. 
schreiben.

Sobald eben 512 Bytes voll sind, erkennt die State machine den Zustand 
und fragt die Flags neu auf Empy/Full usw. ab.

Der Master bekommt ein toggelndes Acknoledge, welches er zur Abfrage für 
die eigene Steuerungslogik benutzen kann.

Gruß vom FPGA-Fragenden


Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, das heißt also, wenn ich nur den Slave-FIFO Modus nutzen will, muss 
ich keine Firmware für den Cypress schreiben, sondern lasse den einfach 
seine Standard-Firmware per USB holen und beschreib die Register 
passend.

Soweit ich das verstanden habe, kann man die Register-Einstellungen in 
ein Script legen und beim USB-Connect reinladen lassen. Das müsste ja 
dann ziemlich einfach sein.

Ich werd mal ein Demoboard mit dem 68013 bestellen und dann das 
Interface in einen CPLD oder Spartan gleich reinbauen und simulieren. 
Details darf ich dann natürlich keine sagen, aber paar Tipps gerne.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So habe mich mal eingelesen. Dabei bin ich zu folgenden Fragen gekommen:

1. warum verwendest Du keinen 16 Bit breiten Datenbus dies würde doch 
die doppelte Datendurchsatz bringen

2. sehe ich es richtig das Du nur 2 Enpoints verwenden willst. (einen 
fürs lesen und einen fürs schreiben) Dadurch geht doch eine menge 
Performance verloren, denn während Du beim Auslesen der Enpointdaten 
bist (FPGA liest Daten aus den Endpoint aus) kann der PC über die 
USB-Leitung keine neuen Daten senden, da der Speicher gerade ausgelsen 
wird.

Nehmen wir mal an Du willst Daten vom FPGA in Richtung PC übertragen. Du 
schreibst die Daten in einen ENDPOINT. Wenn dieser voll ist werden die 
Flags gesetzt. Jetzt muss der PC fragen ist der ENDPOINT voll dann hole 
die Daten vom Endpoint ab. Da Windows aber kein Echtzeitbetriebssystem 
ist fragt der Treiber den Füllstand des ENPOINTS unregelmäßig ab. Im 
schlimmsten Fall kommt der Treiber erst sehr spät an die Reihe, weil der 
PC gerade voll ausgelastet ist und ein anderer Prozess eine höhere 
Priorität besitzt. Somit bleibt das FLAG (FIFO ist voll) gesetzt. 
Deshalb musst Du die Daten im Block RAM des FPGAs immer 
zwischenspeichern. Der Zwischenspeicher müssen natürlich größer werden 
wenn Du nur einen ENDPOINT benutzt. Benutzt Du mehrere ENDPOINTS so 
kannst Du die Daten im nächsten ENDPOINT speichern, somit sind die 
ENDPOINTS die Buffer für die USB-Überragung. Jedoch würde ich trotzdem 
per Block-Ram im FPGA zwischenpuffern, damit wirklich keine Daten 
verloren gehen.

Dein Timing-Diagramm muss ich mir noch mal genau anschauen und 
überprüfen ob es so wirklich realisierbar ist. Dies wird aber sicher 
noch 2 Tage dauern bis ich dazu komme. Anschließend werde ich meine 
Lösung vorstellen.

Grüsse

Sebastian

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, das mit den Zwischenpuffern braucht man meiner Ansicht nur, wenn 
man ein Streaming mit konstant hoher Datenrate implementieren will. 
Dafür gibts aber extra Streaming Endpoints und auf OS-Ebene wird 
Bandbreite dazu reserviert. Nennt sich isochrones Streaming.

Will man sicheren Datentransfer in Blöcken, ist die o.g. Methode sicher 
sinnvoll, dann macht man mit der Abarbeitung im (Mess-)System erst 
weiter, wenn der FIFO vom OS geleert wurde. Ansonsten kanns ja passieren 
man überfährt Windows total mit Daten, die dann irgendwo im Nirvana 
landen.

Kommt halt auf die Anwendung drauf an.

Bei dem, was ich implementieren muss, wird vom PC ein Kommando 
geschickt, dann eine Messung gestartet, die Werte sowieso in einem FIFO 
direkt hinter dem ADC mit 80MHz eingesampelt. Ist der ADC-FIFO voll, 
oder die Sample-Anzahl, die vorgegeben wurde, erreicht, werden die Daten 
Blockweise vom FPGA ausgelesen und an den Cypress geschickt. Erst wenn 
alle Daten am PC angekommen sind, wird ein neues Aufnahmekommando (bei 
Bedarf) geschickt.

Dieses will ich mit einfachsten Mitteln ohne große Einarbeitung in die 
Tiefen des USB erreichen.

Bisher läufts über ein FireWire 400 Modul von Orsys, ist aber teuer und 
erlaubt nur iso-streaming, dabei können Daten verloren gehen.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe im Internet noch was sehr schönes gefunden

http://www.quickusb.com/store/media/QuickUSB_User_...

Nehmt Euch die Zeit und schaut Euch dieses PDF an. Dort sind sehr 
interessante und vor allem wichtige Informationen über die 
unterschiedlichen Betriebsarten. Die Beschreibung ist recht 
verständlich. Ich habe schon mit einen FTDI-USB IC gearbeitet. Jedoch 
sind nur 1MB/s mit diesem Chip möglich. Quickusb bietet unter anderem 
eine Firmware an, die den FTDI-Chip emuliert, jedoch die Datenrate um 
den Faktor 10 erhöht. Dies finde ich sehr interessant, da ich den 
FTDI-Chip schon mal angesteuert habe.

Grüsse

Hans

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich hab jetzt mal auf einem anderen Projekt einen 68013 ohne EEPROM 
an den PC angeschlossen, meldete sich mit USB Kennung VID 04B4 und PID 
8613 an. Inf-File angepasst, Namen, Firma usw auf unser Institut 
geändert und dann konnt ich den in der CyConsole anschauen.
Wie´s ausschaut, hat die "Firmware" auf dem 8051 dann irgendwelche 
Standard-Werte, denn der meldete sich schon mit 4 AltInterfaces am PC 
an, die eigentlich alles abdecken, was man benötigen würde.

Geh ich recht in der Annahme, dass ich jetzt über die cyAPI direkt drauf 
zu greifen könnte, und im BULK-Transfer Daten per Slave-FIFO hin- und 
her übertragen kann? Arbeitet das GPIF am 68013 ohne sonstige 
Konfiguration im Slave-FIFO-Modus, oder muss ich dazu mit dem 
GPIF-Designer eine Konfiguration erstellen, welche ich dann in die 9051 
Firmware einbauen muss?

Gibts die Möglichkeit, mit einem Programm o.ä. gleich ein IIC-File zu 
erstellen, in das ich dann eigene VID/PID eintragen kann?

Gibts von Cypress auch einen Block freie VID/PIDs, die man nutzen kann, 
ähnlich wie bei FTDI?

Die Seriennummer müsste man ja auch in das EEPROM schreiben, damit man 
bei mehreren gleichen Chips auseinander halten kann, welcher jetzt 
welcher ist, oder?

Dazu hab ich noch nix gefunden.

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sebastian

Mit allem was du sagst bzgl. Performance hast Du recht !! :-))

Der obige Entwurf soll doch nur zu TESTZWECKEN implementiert werden, 
damit man eine Daten-Schleife über den Cypress und FPGA schieben kann.

Thema: Minimalsystem !!!

Damit wird dann
- das Reset Verhalten,
- das Timing
- die fehlerlose Übertragung
- Windows USB Antwortzeitverhalten

und vieles mehr studiert und hoffentlich zum laufen gebracht.

Wenn man die Datenschleife mit einfachster FSM am Laufen hat, dann kommt 
die anwendungsspezifische  Ausgestaltung die bei jedem anders aussieht.

... erstmal kleine Brötchen backen ..


Nochmal zu den FIFOs:

Bei z.B. Quad Buffering kann gleichzeitig der FPGA einen Buffer füllen 
und der PC 3 Buffer leeren. Und so weiter. Der PC bzw. der FPGA wartet 
immer nur darauf bis ein freier Buffer zur Verfügung steht.

Folgende Aussage mal nachvollziehen:

Flag Full => ALLE buffer sind komplett gefüllt.

FLAG Empty => ALLE buffer sind vollständig leer.

Flag not Empty => es ist ein Buffer zum auslesen durch den FPGA 
vorhanden !

Gruß vom FPGA-Fragenden

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian R.

zum ausprobieren kannst Du

- den 8051 mir Code betanken, damit sich an der parallel Schnittstelle 
was tut ( langsamster Datenflow )
- eine quasi Timing Sequenz für das GPIF entwerfen ( schneller datenflow 
)

- slave FIFO Betrieb

Das GPIF wird ohne die spezielle programmierung nichts machen. Würde mir 
die Zeit für das Teil nicht nehmen, wenn Du's ja eh nicht brauchst.

Versuch doch mal über die CyUSB.dll über den Endpoint 0 die aktuelle 
Konfiguration des Chip auszulesen.

Eigenes C# Programm schreiben. Register einlesen. Mit den WErten über 
die Konsole vergleichen.

Wenn Du soweit bist, dann stehst Du genau vor dem gleichen Problem an 
dem wir schon eine weile rummachen, eine FSM zu schreiben und einen CPLD 
oder FPGA ranzuhängen und zu checken ob ein Datenaustausch zustande 
kommmt.

Freie VID/PID ???, wüßte ich auch gern.

Würd mich freuen, wenn Du's als erster hinbekommst, dann lernen wir von 
Dir.

Gruß vom FPGA-Fragenden

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  FPGA-Fragender

Falls Du Probleme mit dem VHDL-Code bekommst kannste ja den Codeteil 
posten und ich kann dann helfen. Die Statemachine sollte eigentlich 
recht gut zu programmieren sein.

Grüsse

Sebastian

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich hab nochmal weiter im Reference Guide gewühlt. Ohne 
Programmierung kann man den Slave FIFO Modus nicht benutzen.

Seite 114: "The EZ-USB comes out of reset with its I/O pins configured 
in ‘Ports’ mode, not ‘Slave FIFO’ mode. To configure the pins for
Slave FIFO mode, the IFCFG[1:0] bits in the IFCONFIG register must be 
set to ‘11’"

Also MUSS man eine Art Firmware auf den 8051 Core spielen. Die Frage 
ist, ob es für den Slave-FIFO eine Art Standard-Firmware von Cypress 
gibt. Bisher hab ich zwei asynchrone Slave-FIFO Sachen da gefunden, 
allerdings bloß 8 Bit Interface. Ist ja Unsinn.

Wenn man die Firmware selbst ändern muss, braucht man ja einen 
Compiler...welchen eigentlich? Müsste das nicht mit dem freien SDCC auch 
gehn? Oder nur mit Keil?

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

Aus meiner Sicht folgt aus der Notwendigkeit das IFCONFIG Register zu 
beschreiben nicht unbedingt die Notwendigkeit einer individuellen 
firmware.

Die Preisfrage lautet: kann das Register IFCONFIG ( und andere ) auch 
direkt durch einen control Transfer über den EP0 vom PC geschrieben 
werden und dadurch der SLAVE in den FIFO Mode versetzt werden ?

Genau das müssen wir jetzt untersuchen.

Ich denke schwer dass das geht, denn die normale Reihenfolge lautet ja:

1. CYConsole nutzen und Status vom Controller einlesen

2. controll Befehle absetzen

3. wieder Status einlesen und prüfen ob der Controller macht was man 
will

4. weitere Befehle absetzen usw.

Dabei hängt sich der Controller 10 mal auf und man versetzt ihn jeweils 
über einen Reset bzw. Reconnect wieder in den Ursrpungszustand.

Bis das Script genau das macht was man will.

Erst dann wird das ganze z.b. in C code z.B. per KEIL programmiert und 
ins RAM downgeloade.

Wenn der Chip das gewünschte tut wird der code ins EPROM übertragen.

Natürlich kann man auch gleich die ganze Zeit in C arbeiten.
Also immer compilieren, ein HEX File erzeugen downloaden ins RAM ohne 
EPROM und testen. usw.

Hoffe aber schwer, dass sich die Conf Register auch über die C#, API 
direkt schreiben lassen.

Gruß vom FPGA-Fragenden

P.S. Hast Du mal in C# oder C++ versucht die Demos nachzuvollziehen ?

Hab ich gestern gemacht. War gar nicht mal so schwer.

Insbesondere CyConsole liegt im Quelltext komplett in C# vor und bietet 
einen guten Einstieg.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FPGA-Fragender wrote:

> Die Preisfrage lautet: kann das Register IFCONFIG ( und andere ) auch
> direkt durch einen control Transfer über den EP0 vom PC geschrieben
> werden und dadurch der SLAVE in den FIFO Mode versetzt werden ?

Genau das wäre schön, steht aber nirgends beschrieben. Die Register 
zählen nicht zum RAM des 8051 Core, sondern werden per EXTERN ... im 
Compiler angesprochen. Mittlerweile hab ich mal paar Firmware Fetzen 
angeschaut, scheint nicht viel dazu zu sein, das meiste macht ein 
Assembler-File von Cypress, man muss im C-File "nur" die Einstellerei 
machen. Eventuell kommt man mit der 2k-beschränkten Keil-Version hin, 
ansonsten mit SDCC, den hab ich zumindest schon mal installiert und in 
Eclipse integriert. Allerdings mag der einige keil-spezifische 
Anweisungen (noch) nicht.

Vielleicht lässt sich ja mit den Samples schon was sinnvolles machen, 
BulkLoop scheint erst mal grundsätzlich geeignet zu sein.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte schon mal das SX2 Board von Cypress. Dort gab es eine Programm 
mit dem man den Registern Werte Zuweisen konnte, somit kannst Du den 
Cypress Chip in den Slave-Modus umschalten. Angeschlossen wurde das 
ganze über USB. Die Einstellungen die vorgenommen werden, werden im 
internen EEPROM gespeichert. Der Programmcode, der das USB-Protokoll 
enthält steht im FLASH-Speicher des Cypress Chips. Dies ist demnach 
recht einfach zu realisieren, jedoch muss man genau wissen welche Werte 
die Register haben sollen.

Grüsse

Sebastian

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian R

Gestern hab ich mal mein erstes eigenes c# Programm zur Kommunikation 
mit dem Cypress Chip geschrieben und getestet ( per CYUSB.DLL ). Nix 
großes nur ein paar Spielereien, die Demos abgeändert usw. Daten über SW 
Schleife gelesen usw.

Dazu muss man vorher das entsprechende HEX File von den Demos auf den 
USB Chip downloaden, was mit der CyConsole schon aufs erste Mal prima 
ging.

Es gibt z.B. eine Demo Firmware, welche das endlose lesen von einem 
Endpoint unterstützt ( quasi so als ob ständig neue Daten vorhanden 
wären )

Eine andere Demo ( HEX File ) schreibt alle Daten aus dem Schreib-fifo 
in den Lese-FIFO. (Software Datenschleife )

Nach viemal EP-Buffer vollschreiben muss dann spätestens wieder der 
entsprechende EP-Buffer gelesen werden usw.

Hat alles problemlos funktioniert.


Allerdings hat die Configuration der spezieller Register für SLAVE FIFO 
Konfiguratione nicht funktioniert.

Der Chip sollte sich zwar per SW im Reset Modus halten. ( das klappt 
auch )

Dann sollte eigentlich das schreiben einer beliebigen Adresse über den 
EP0 gehen. ( hier kommen nur Fehlermeldungen zurück )

Danach den Reset wegnehmen ( klappt auch ) und der Chip ist neu 
Enumerated und läuft mit neuer Config.

Geht aber in Tat und Warheit einfach nicht, weil sich die Register nicht 
schreien lassen. Grrrrrr  :-((

Ich gehe zwischenzeitlich auch davon aus, dass sich spezielle Register 
einfach nur über die Firmware schreiben lassen !!!

SDCC Compiler für die Firmware
===============================

Als nächstes hab ich mir den SDCC Compiler (Open Source) installiert.

Allerdings komme ich mit dem Teil unter Windows nicht richtig klar.

Das Teil läuft als Commandozeilen Version. Soweit kein Problem. Wie man 
sich unter DOS bewegt ist mir aus alten Zeiten auch noch klar.

Aber ich habs nicht fertig gebracht, dem Teil zu sagen hier ist ein 
MAKEFILE nimm dieses und Compile das Projekt durch.

Es kam immer nur die Mitteilung, dass er mit dem Makefile nichts 
anfangen kann.

Könnte mir bitte jemand erklären, wie ich unter Windows in der 
commandozeile ein Projekt mit SDCC durchkompiliere.
Das Projekt besteht aus ein paar C Quellfiles und Headerdateien und 
MAKEFIle, die ich aus dem Netz runtergeladen hab.

Keil Compiler für die Firmware
===============================

Nächster Versuch. Keil-Compiler, kostenlose Version runtergeladen und 
installiert.

Ein Demo Projekt vom Cypress Developer Kit einzukeseb klappt wunderbar, 
weil die Demos ja unter KEIL gemacht wurden.

Allerdings hab ich mit der Interpretation des QuellCodes noch meine 
Schwierigkeiten.

Was von dem Code ist unabdinglich und sollte immer unverändert bleiben 
usw.

Soweit mit Stand

Gruß vom FPGA-Fragenden

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da bei uns Zeit = Geld ist, werden wir wohl erst mal das Design von 
QuickUSB kaufen, ist ja spottbillig. Aber nebenbei schauen wir trotzdem 
nach der Firmware. Von einer Partnerfirma hab ich schon paar Tipps 
bekommen, die Register sind über USB nicht setzbar, aber 
Firmware-Entwicklung ist mit dem 4k beschränktem Keil gut machbar. 
Anhand der Beispiele lässt sich wohl recht schnell eine eigen Firmware 
schreiben, sind im Prinzip ja nur Register-Definitionen zu machen.
Allerdings gibts von Cypress keine PIDs und die Standard VID/PID in den 
Chips sind nur für die Entwicklungsphase bzw. zum Programmieren der 
eigenen da. Fertige Geräte dürfen nur mit eigener VID/PID verkauft 
werden.

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

Was kostet denn bei QuickUSB wieviel ? Was meinst Du mit Design. ? Die 
benutzen doch den gleichen Chip.

Ich hab deren Seite auch schon durchgelesen aber hatte den Eindruck dass 
die nur die übliche Verkaufsstrategie fahren.

Also: Eval Board anbieten. Eigene Firmware mitliefern. Zugriff über eine 
eigene xyz.dll usw.

Kann die VID von QuickUSB für commerzielle Produkte verwendet werden.

Also ich kenne das nur so, dass man immer beim "USB Konsortium" eine 
eigene VID kaufen muss.

Gruß FPGA-Fragender

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die verkaufen auch die Firmware extra, ohne Board, die in den externen 
EEPROM kommt, und da die das so anbieten, müssen sie eine eigene VID 
haben. Die Firmware kostet 29$ bei 10Stück und wird mit zunehmender 
Anzahl Lizenzen billiger.

Es ist ein ausgereiftes API dabei, wie es scheint, man kann allerhand 
machen. FPGA-Kofiguration, SPI, IIC, usw....

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss die Firmware unbedingt in ein externes EEPROM? Ich hatte gedacht 
man ersetzt einfach die Cypress Firmware im IC und fertig.

Ein großer Vorteil bei Quickusb ist die Ansteuerung per Software, die 
Dokumentation ist eigentlich sehr gut. Jedoch ist auch Braintechnology 
sehr gut. Braintechnology ist eine deutsche Firma und somit sollte der 
Suport noch einfacher sein. Einfach anrufen und nachfragen.

http://www.braintechnology.de/braintechnology/usb2dll.html

Grüsse

Sebastian

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der 68013 hat intern nur RAM-Speicher, entweder man lädt die Firmware 
jedes mal aus dem Treiber oder der DLL(wie bei Braintech.) oder man 
speichert die Firmware in einem EEPROM, und der 68013 saugt die sich 
beim Einschalten da heraus in seinen RAM. Der FX2 hat keinerlei internen 
nicht-flüchtigen Speicher.

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Braintechnology ist mir sehr gut bekannt. ( usb2.dll und die neue 
Streaming dll )

Ich besitzt selbst das Board von Braintechnologie zum testen.

Kann euch aber gleich sagen, dass ich nach Durchsicht der SW von BT 
gleich wieder davon abgekommen bin und lieber mit der Cypress SW / API 
arbeite.

Achtung: Gilt nur für Slave FIFO Betrieb, für die anderen Port Modes mag 
die usb2.dll natürlich nützlich sein.

Selbst meine beschränkten, kleinen C++, C# kenntnisse reichen aus um ein 
Anwenderprogramm von Cypress nachzuvollziehen und zu ändern, das Daten 
mit ca. 36 Mbyte/sec Durchsatz vom USB liest und in mehreren Threads 
läuft.

Die Prozessor-Auslastung ist dabei nur ca. 15 %, das ist schon suuuper.
( Prozessor = Athlon 64 / 3000 )  :-))

Das Hochladen einer eigenen Firmware xy.hex File beim Start der 
PC-Front-end SW konnte ich auch realisieren.
( SW code Teil einfach aus der Demo übernommen fertig )

Man braucht also nicht unbedingt ein EPROM.

Mit Keil hab ich nun die Standard Firmware so abgeändert, dass der CHIP 
in den SLAVE-FIFO Mode versetzt wird.
Die Firmware für Bulk-Demo übernehmen und einige Regiser beschreiben, 
fertig !

Ob das Teil natürlich das macht was ich will, sehe ich erst, wenn ich 
eine Verbindung zum FPGA herstelle und die FSM per VHDL geschrieben hab.

Wobei sich der Kreis schließt und wir wieder bei der 
Ausgangs-Problemstellung des Threads angelangt sind.

Sobald mein Spartan Board gekommen ist wird die Sache spannend !!!

Gruß vom FPGA-Fragenden

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man die Beispiele, die Du so gut findest auch bei Cypress 
runterladen, oder sind diese nur auf einer CD erhältlich?

Grüsse

Sebastian

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sebastian,

die Beispiele sind bei der SW dabei, die zum Cypress Eval Kit gehört.

Die SW für das Eval Kit kannst du direkt bei Cypress runterladen.

Es sind dabei

1. SW Demo Prog für die API auf der PC Seite C# z.T. auch in C++
2. Firmware für den Chip als SourceCode (bearbeitbar mit Keil 
Demoversion)

Gruß vom FPGA-Fragenden

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich hab jetzt eine lauffähige Firmware für den FX2 geschrieben, d.h. 
eine von einer Partnerfirma verwendete angepasst. 2 Endpoints, einer für 
IN einer für OUT. Der Control ist ja obligatorisch. Desweiteren ein GPIO 
für Bus-powered Strom einschalten. Ging alles ziemlich einfach, wenn man 
sich bissl in das technical reference manual einliest. Die Firmware 
macht nix weiter als alle Register einstellen, Slave FIFO Modus und 
AUTO-IN und AUTO-OUT. Die Fifo-Flags sind fest an die FIFOs gebunden, 
also kein indexed-Mode. Datenübertragung klappt, auf FPGA-Seite eine 
ziemlich einfache Schaltung, die mit dem IFCLK läuft, der aus dem 68013 
kommt. Die Daten werden korrekt übernommen und versendet. Im FPGA ist eh 
nochmal ein FIFO drin.

Firmware hat 2900Bytes etwa, passt also in die kostenlose Version. Dank 
der vielen Demos von Cypress bzw. Anchor, die gut dokumentiert sind, war 
das recht einfach.

Schade nur, dass es keine DLL für unmanaged Code gibt, sondern bloß eine 
statische Lib, aber das ist nicht so wild.

Quellen darf ich natürlich keine hier posten, ist alles auf Arbeit 
gemacht....

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ein toller Beitrag der hilft und Mut macht! Bin seit 3 Tagen dabei mich 
durch all die .pdf's zu wühlen und stimme mit fast all euren Aussagen 
überein. Doch alle Theorie ist grau, daher habe ich noch ein paar 
Fragen:

1. Ich habe mich entschieden den Keil zu nutzen (scheint mir die 
reibungsloseste Variante zu sein). Wenn ich mein .hex file in den RAM 
bekommen will ist es dann nötig den EEPROM zu flashen oder kann ich es 
wirklich per CyConsole über USB zu schicken? (Wie ich es verstanden habe 
geht es über USB.)

2. Mein erster Schritt wird die Ansteuerung eines am 8051 hängenden 
LCD's und das Auslesen von ein paar Tastern am 8051 sein. Gestaltet sich 
der Zugriff auf die endpoints vom 8051 aus problemlos?

3. Zur Sciherheit: Es sollte möglich sein die endpoints mit 
verschiedenen Konfigurationen zu betreiben, nicht wahr? (Beispiel: EP2 
low-speed für den 8051, EPxyz high-speed mit slave FIFO zum DSP.)

Würde mich über einen Austausch freuen.

Grüße
pumpkin

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Ja, das sollte problemlos klappen. Aus dem externen EEPROM wirds auch 
nur in den RAM geladen und dann ausgeführt.

2. Ja, auf die Bulk-Endpoints kann man ganz leicht zugreifen, ist für 
den Programmierer dann einfach ein Array in der im Descriptor 
angegebenen EP-Größe.

3. Nein! Anders herum wird ein Schuh draus: Man kann für Low- und für 
High-Speed verschiedene Endpoints deklarieren, die ans OS reported 
werden. Bei Low-Speed sind max. 64Byte Buffer Größe möglich, bei 
Hi-Speed 512 Byte.
Je nachdem, wo man das USB Device ansteckt, sind die EPs dann nutzbar. 
Man kann sie aber auch für Low- und High-Speed gleich groß machen (max. 
64) und gleiche Adressen vergeben, dann muss man das auf der 
PC-Gegenseite nicht explizit prüfen...

Slave FIFO: Aufpassen. Das Timing ist abartig und sehr intolerant 
gegenüber Fehlern oder knappen Zeiten. Außerdem muss die Reihenfolge des 
zugriffs genau eingehalten werden, das steht so nicht im Datenblatt und 
User Guide. Beispielsweise darf man nicht gleichzeitig die FIFO-Adresse 
und die Steuersignale anlegen. Immer eins nach dem anderen. Sonst 
krachts und Bytes gehn verloren oder kommen zuviel an. Alles sehr 
komisch.

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Christian,

das ging schnell!

Ok, zu 3.: Versteh ich dich falsch oder du mich oder doch ganz anders? 
Ich skizzier nochmal wie ich das sehe: Man konfiguriert mit der firmware 
des 8051 die EP's. In meinem Beispiel halt EP2 low speed und EPxyz mit 
high speed. An den PC angestöpselt sieht man nun ein low speed und ein 
high speed device!?

Das mit dem slave FIFO ist natürlich ärgerlich, aber das tangiert mich 
z.Zt. eher nicht, das ist Schritt 2 oder 3. Bezieht sich deine Aussage 
auf beide (synchron und asynchron) Modi? Kann mir nicht vorstellen dass 
es beim asynchronen auch so kritisch ist, hab mir die timings jedoch 
noch nicht näher angeschaut.

Grüße
pumpkin

Autor: Martin Kohler (mkohler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pumpkin wrote:
> Ok, zu 3.: Versteh ich dich falsch oder du mich oder doch ganz anders?
> Ich skizzier nochmal wie ich das sehe: Man konfiguriert mit der firmware
> des 8051 die EP's. In meinem Beispiel halt EP2 low speed und EPxyz mit
> high speed. An den PC angestöpselt sieht man nun ein low speed und ein
> high speed device!?

Dann klinke ich mich auch mal ein...
Nein! Ein USB Device kann mehrere Endpoints haben (beim 68013A insgesamt 
max. 6), das Device selbst kann aber nicht in unterschiedlichen 
Konfigurationen gleichzeitig kommunizieren. Entweder läuft das Interface 
in Highspeed (480Mbps) oder aber in Fullspeed (12Mbps). Lowspeed wird 
vom 68013er nicht unterstützt.
Es ist genau so, wie schon Christian beschrieben hat.

Die Endpoints selbst können dann wieder unterschielich "schnell" sein, 
der Interrupted Mode z.B. kann sehr schnell laufen (alle 125us, nur bei 
HS) oder aber auch sehr langsam. Die effektive Datenübertragung über den 
Bus läuft aber immer mit der übergeordneten Geschwindigkeit des Device.

Alle unklarheiten beseitigt?

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Groschen ist gefallen, danke schön!

Grüße
pumpkin

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich bin auf der Suche nach dem "Conexant USB Bus Powered Reference 
Design" von Cypress. Der link auf der Seite spuckt mir nur ein popeliges 
Bild als download aus. Hat jemand eine brauchbare Quelle?

Grüße
pumpkin

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

schade keine Anwort. Aber erstmal egal. Was mich zur Zeit wurmt ist die 
Ezusb.lib die man ja für die Beispiele benötigt. Das Evalkit habe ich 
nicht hier (wo die Software wohl mit bei ist wenn ich das recht 
verstanden habe) und im Netz habe ich nur eine Ezusb.lib gefunden die 
aber scheinbar für den FX Chip (nicht für meinen FX2LP) ist - kann ich 
die verwenden (auf den ersten Blick unterscheiden sich u.a. die header, 
aber von Bibliotheken hab' ich ehrlich gesagt wenig Ahnung)? Kann mir da 
jemand helfen?

verwirrte Grüße
pumpkin

Autor: Martin Kohler (mkohler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Email erwünscht?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das komplette Entwicklungspaket für den FX2 gibts hier: 
http://download.cypress.com.edgesuite.net/design_r...

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mmmmmh, nicht schlagen  ;^)  ! Die Geschichte hatte ich schon, aber die 
Installation schlug fehl, daher hatte ich dieses Paket aus den Augen 
verloren  :^/   Aber nun läuft es, abgesehen von 189 Warnungen beim 
kompilieren. Ist das normal?

Grüße und Dank!
pumpkin

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
189 Warnungen? Das ist nicht normal. Mein Programm erzeugt 0 Warnungen, 
0 Fehler.

Sicher, dass du das richtige Header-File drin hast?

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, es sind keine Beispiele die in dieser .exe dabei sind sondern 
welche von Keil bzw. Cypress (z.B. die ATA-Anwendung). Die Beipiele die 
beigelegt sind laufen ohne Beanstandungen durch, das ist ja das 
wichtigste.

pumpkin

Autor: Der_kleine_vom_See (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi an alle,
ich habe gerade fast alles hier durchgelesen. Trotzdem ist bei mir der 
Groschen leider immer noch nicht ganz gefallen. Mein Ziel ist 
digitalisierte Daten an die Ports anzuschließen, diese mit dem 8051 
einzulesen ein bissel zu bearbeiten(eigentlich nur die Datenreihenfolge 
zum senden festlegen) und dann per USB an den PC zu senden.
Nun hab ich hier mehrmals geselesen das es dafür Treiber (dll, sys) 
gibt. Benötige ich hierfür das Entwicklungsboard, was ja fast 500€ 
kostet oder brauche ich dieses garnicht?
Hätte ich sonst andere alternativen den abgeänderten Code in den 8051 zu 
laden oder bietet mir der Chip mit der Standart Firmware schon andere 
alternativen ohne das ich noch viel machen muss?
Danke schonmal für eure Hilfe

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also nochmal: Wenn du kontinuierlichen Messdaten aufnehmen willst, und 
das auch noch äquidistant, wie das ja beim Messen wichtig ist, kommst du 
mit dem FX2 alleine nicht weit. Du müsstest mindestens einen CPLD oder 
sowas extern anschließen, der zwischen ADC und FX2 sitzt, den Takt und 
die Steuersignale für den ADC generiert. Das kannst du nicht sinnvoll 
über den 8051 machen, dafür ist der nicht ausgelegt. Dann kannst du den 
Slave FIFO Modus des FX2 benutzen, um die Daten an den PC zu 
transferieren. Mit Quad-Buffer müsstest du genügend Reserve haben.
Wenn du die Daten erst in die CPU einlesen und da noch sortieren willst, 
brauchst du mindestens externen RAM, denn die Endpoint-Buffer werden 
dafür nicht funktionieren.

Um die Firmware in den FX2 zu bekommen, brauchst du kein extra 
Eval-Board, die wird direkt per USB hochgeladen. Entweder in den RAM 
oder ins externe EEPROM.

In dem von mir geposteten Link gibts die komplette Entwicklungsumgebung 
mit Kompiler, Beispielen, Manuals usw.
Allerdings ist der Kompiler auf 4k beschränkt, für viel mehr als Slave 
FIFO, oder einfache Sachen, die per BULK-Transfer laufen, reicht das 
nicht.

Der Chip hat keine Standard Firmware, lediglich rudimentäre Funktionen, 
um das EEPROM oder den internen RAM zu beschreiben, und sich überhaupt 
als USB Device enumerieren zu lassen.

Autor: Der_kleine_vom_See (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, das mit der Takterzeugung sehe ich ein. Aber warum schlägst du einen 
CPLD vor, wenn dieser nur zur erzeugung des Taktes verwendet werden 
soll? Da gibt es bestimmt noch andere Varianten...muss ich mal 
nachschauen.
Ok das mit den sotieren der Daten kann sein das das nicht klappen wird. 
Aber irgendwie muss ich doch die digitaliserten Daten erstmal in den FX2 
bekommen. Reicht es die Signale an die Ports zu hängen? Muss doch 
abfragen wann die Daten zur verfügung stehen damit ich sie abholen kann 
und dafür brauche ich doch dann den 8051. Und dann hätte ich mir gedacht 
das ich die daten gleich weiter an das "USB Interface" geben kann und er 
sendet das dann einfach mal.
Es wäre mir im Notfall sogar egal wenn die digitalisierten Daten (von 
mehreren ADC`s) nicht in der selben reihenfolge am pc ankommen würden.
4KB ist nicht gerade viel was zur verfügung steht. kann dann nicht z.b. 
im externen ram der code für den 8051 gespeichert werden und dann 
hineingeladen werden oder so?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Takt ist ja nicht alles. Du musst ja auch die Flags der Slave-FIFOs 
des Cypress auswerten, die Steuersignale für den ADC bereitstellen usw. 
Klar, kann man auch diskret machen, aber das wird ja ein Haufen 
Gatter-Logik dann.
Die Daten in den FX2 bekommst du, indem du die Steursignale und Daten an 
die Ports anlegst, vielleicht solltest du mal das Manual lesen.
Und "einfach mal so senden" ist sowieso nicht bei USB, du kannst die 
Daten lediglich bereitstellen, abholen muss es dann der PC. Dazu muss 
der PC allerdings auch wissen, wieviele Daten zur Abholung bereit 
stehen. Sonst bekommt er nix.

Und wieso musst du abfragen, wann die ADC-Daten zur Verfügung stehen? 
Das legst du doch selber mit dem Timing des ADC-Taktes und der 
Steuersignale fest. Auch hier solltest du ins Datenblatt des ADC 
schauen. Der ADC alleine macht ja nix, dem musst du ja auch ein 
Wandlungssignal geben und dann stehen die Daten bereit. Wann genau hängt 
vom ADC ab, das steht im Datenblatt.

Autor: Der_kleine_vom_See (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Du musst ja auch die Flags der Slave-FIFOs des Cypress auswerten, die
>> Steuersignale für den ADC bereitstellen usw.

Muss ich dies wirklich so tun? Kann ich das nicht mit den integrierten 
8051 machen?...hatte ich mit zumindest so vorgestellt.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Theoretisch ja, allerdings wirds dann halt wesentlich aufwendiger. Und 
wie ich deinen Wissensstand einschätze, bekommst du das nicht ohne 
weiteres hin. Dir fehlen ja so ziemlich viele Grundlagen. Gerade bei USB 
und 8051 Programmierung.

Autor: Der_kleine_vom_See (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei USB muss ich dir leider vollkommen recht gehen. Mit 8051 hatte ich 
schon einige erfahrung, muss aber auch zugehen das das schon ein bissel 
her ist. Werd das trotzdem mal probeweise aufbauen und testen.

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

hier mal ein kurzer Beitrag einfach mit dem Ziel anderen Leuten, die 
sich mit dem Thema dieses Threads beschäftigen viel Ärger bei der 
Konfiguration des Cypress Bausteines zu ersparen.

Wenn der Cypress Baustein partout das Beschreiben der Out Endpoints 
verweigert, dann ist speziell im

- Slave Modus
+ auto_out Modus

zu beachten,

- dass die Out Endpoints buffer je nach Anzahl der Puffer tripple, quad 
usw. explizit scharf geschaltet werden müssen

- und jetzt kommt das entscheidende
====================================

das REVCTL Register muss zunächst auf

 0x01 enspricht no_Outo_Arm  und nach dem Fifo Reset wieder auf
 0x03 entspricht Auto_Arm geschaltet werden

Diese Info steht nirgends in der Doku klar beschrieben und hat mich viel 
Zeit gekostet.   :-))

Beispiel: Der Endpoint 2 soll als Out konfiguriert werden

    // Configure EP2 (Out) for bulk output, quad-buffered (4*512 bytes).
    EP2CFG = 0xa0;     SYNCDELAY;

    REVCTL = 0x01;    SYNCDELAY;  // OutPacketEnd also bit 1 auf 0

                 // Fifo Resets für alle Endpoints durchführen
    FIFORESET = 0x80;  SYNCDELAY;  // NAK all requests from host.
    FIFORESET = 0x02;  SYNCDELAY;
    FIFORESET = 0x04;  SYNCDELAY;
    FIFORESET = 0x06;  SYNCDELAY;
    FIFORESET = 0x08;  SYNCDELAY;
    FIFORESET = 0x00;  SYNCDELAY;  // Resume normal operation.

  // die 512 Byte Buffer für den Out Endpoint 2 scharf machen
    OUTPKTEND = 0x82;  SYNCDELAY;
    OUTPKTEND = 0x82;  SYNCDELAY;
    OUTPKTEND = 0x82;  SYNCDELAY;
    OUTPKTEND = 0x82;  SYNCDELAY;

    REVCTL = 0x03;    SYNCDELAY;  // Jetzt OutPKTEnd wieder auf 1 setzen

    // EP2  AUTOOut bytewise bus, 0 len Packets erlaubt
    EP2FIFOCFG = 0x14 ;  SYNCDELAY;

.. usw.

Gruß vom FPGAFragenden

Autor: harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe gespannt mich hier durchgelesen...
mein projekt ist ziemmlich ähnlich eurem, ich verwende statt einem fpga 
einen DSP. die firmware läuft nun endlich (hat zwahr noch ein paar 
maken). aber mein nächstes problem ist das GUI von cypress.
ist das richtig, dass es nur mit der CyUSB.dll komuniziert? und wo finde 
ich die doku dazu? oder hat jemand schon diese dll ins labview gezogen?

gruss
harry

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die DLL die es von Cypress gibt, geht nur mit .NET Software zu 
verwenden. Die statische Lib für C++ usw geht meines Wissens nicht mit 
LabView.
Ansonsten wäre noch LibUSB32 eine Alternative.

Autor: harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
herzlichen dank,

geht bei auch aber die .Net Sofware? bei mir kommt immer, dass 
CYUSB.CSPROJ fehlt. Oder wenn ich LV die DLL anschauen lassen heisst es, 
dass sie korrupt ist.

Kann mir jemand helfen? komme mir schon vor wie ein dummy und habe 
schnell cypress angerufen... (den support kann man ja vergessen)

Autor: huwi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo FX2-Gemeinde,
mische mich auch mal ein - nachdem ich diese ganze ellenlange Seite 
sorgfältig durchgelesen habe.

Ich benutze VB und versuchte es mit den hier erwänten CyUSB.dll, 
usb2.dll und vielen anderen.
- Nach langem suchen stiess ich auf die usbio.dll von Thesycon.de, dies 
ist eine allround-Dll, die auch von VB voll unterstützt wird und alle 
Funktionen der FX2LP unterstützt. Wir verwenden vor allem 
Vendor-Requests für diverse Steuerungen (Ram und Flash an DSP's 
beschreiben, auslesen etc.). Auch den Treiber (.sys) wird da sauber 
erstellt.

PS: hat jemand nähere Erfahrung mit SingleByteRead/Write?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, unsere Hardware ist jetzt fertig und streamt zuverlässig Daten über 
BULK-Transfer. Die maximale Datenrate liegt bei uns bei etwa 33MByte/s. 
Ext. FPGA schickt die Daten an das Slave-FIFO Interface mit 40MHz 
IF-Clock, der IN-Endpoint hat eine Paketgröße von 1024 Byte und ist 
doppelt-gepuffert.
Die hohe Geschwindigkeit erreicht man nur, wenn man die XFerSize 
hochsetzt. Diese 33MB/s sind "overall" Speed, wir schicken 2 Byte als 
Anforderung der Daten über einen OUT-Endpoint, daraufhin stellt der FPGA 
die Daten aus einem anderen FIFO in den USB-FIFO bereit.

Nur so als Info, falls jemand ähnliches vorhat.

Autor: DS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian, mit welcher XFerSize arbeitet ihr denn? Und nach 
welchen Kriterien habt ihr diesen Wert festgelegt?

Gruß
DS

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit 64kByte, durch probieren als Optimum ermittelt. Mein Software-Hiwi 
hat da einiges rumprobiert und kam dann auf die 33MByte/s. Allerdings 
verwendet er direkt die IO-Control Funktionen direkt vom Treiber. Keine 
CyUSB.dll oder sowas.

Autor: DS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen, ich hab da folgendes Problem mit meinem FX2LP:

Ich möchte 16-Bit-Daten, die mit einer Frequenz von 5 MHz an den 
FD-Eingängen anliegen, mittels BULK-Transfer an den PC übertragen. Das 
mach ich im synchronen Slave-FIFO-Modus über EP2. Dieser hat eine Größe 
von 1024 Byte und ist 4x gepuffert. Die Slave FIFOs werden von extern 
mit 10 MHz getaktet. AUTOIN ist aktiviert, mit einer Größe von 1024 
Byte. ZEROINLEN und REVCTL sind aus.

Die Daten kommen zum Testen von einem Patterngenerator und werden über 
einen Spartan-3 FPGA an den Cypress geschickt. Leider hab ich keine , 
externen RAM zum Zwischenpuffern hab ich leider keinen.

Ich mach das über LabVIEW. Die passende DLL hab ich mit der CyAPI in 
Visual C++ geschrieben.

Soweit, so gut. Ich hol die Daten nun ab. Die XFerSize hab ich auf 2MB 
gesetzt. Alle Daten, die in den ersten 2MB liegen, sind auch korrekt. 
Dann wird für die nächsten 2MB eine neue Transaktion gestartet. Während 
des Abholens laufen aber die 4096 Bytes Puffer voll. Zwischen den 
Transaktionen fehlen also immer Bytes, mal mehr mal weniger. Das kann 
doch bei diesen Datenraten und vierfacher Pufferung nicht sein, oder?

Leider kann ich auch die XFerSize nicht noch höher setzen, dann schmiert 
mir der Rechner ab.

Habt ihr ne Idee wie ich den Datenverlust verhindern kann?

Gruß
DS

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, BULK-Transfer ist nicht für Datenströme geeignet, die man nicht 
stoppen kann. Du müsstest das Full-Flag des FX2 benutzen, um den 
einzulesenden Datenstrom zu stoppen. BULK wird bedient, wenn der Bus 
frei ist, und Windows macht irgendwas zwischendurch.
benutz am besten den isochronen Transfer, da wird dir eine Datetenrate 
von 24 MByte/s als Maximum garantiert. Da gibts ein Dokument von 
Cypress, wie man Daten streamt.

Autor: DS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem bei isochron ist aber, dass es keine Fehlerkorrektur gibt. 
Das System soll später mal zum Testen von Bildsensoren verwendet werden, 
und da muss sichergestellt sein, dass  die im PC ausgewerteten Fehler 
100%ig nicht von der USB-Übertragung herrühren...

Na ja, ich werd dann mal noch ein paar andere Settings durchspielen.

Gruß
DS

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du die Sicherheit von BULK brauchst, musst du die Strecke 
anhalten können. Es gibt bei keinem Setting eine Garantie, dass du die 
Daten losbekommst. Du musst das Full-Flag verwenden und warten, bis 
wieder frei ist. Da sind mitunter riesige Lücken drin, ich hab mir das 
aufm Oszi angeschaut. Da bringt auch das beste Puffern nix. Entweder 
Streaming oder Strecke anhalten per Full-Flag.

Autor: DS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, aber bei isochron merke ich den Fehler nicht, bei bulk weiß ich 
wenigstens, wenn was nicht stimmt.

Da alle Daten innerhalb einer 2MB-Transaktion ja richtig sind, muss wohl 
der Treiber oder die CyAPI zu langsam sein, wenn eine neue Transaktion 
gestartet wird.
Werd dann mal mit der Windows-API und CyUSB testen, oder vielleicht mit 
LibUSB...

Fast 2 Monate Arbeit fürn Arsch!

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das liegt nicht am Treiber, sondern an der Betriebssystem-Architektur. 
Windows ist nun mal kein Echtzeit-Betriebssystem, deswegen kann nicht 
mal garantiert werden, dass du die Daten in 2 Stunden, 2 Wochen, 2 
Jahren bekommst. Wenn irgendwas im Kernel halt gerade geschieht, hat der 
USB Pause. Der ist so niedrig priorisiert, dass da einfach gewartet 
wird. Du musst einfach das Full-Flag auswerten, was ist denn daran so 
schwer? Unter Linux übrigens das gleiche.

Autor: DS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na das ist nicht wirklich schwer, aber was soll ich mit den einlaufenden 
Daten machen, während ich nicht in die FIFOs schreiben kann? Ich kann 
den Datenstrom nicht stoppen.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, tja, dann hast du schlicht und ergreifend ein falsches Konzept. 
Da müsste eigentlich noch ein etwas größerer FIFO dazwischen, und dann 
mit 40Mbyte/s aus dem FIFO in den FX2 pusten, wenn der Platz hat. Im 
Mittel reicht die USB Geschwindigkeit ja aus, aber eben nur im Mittel.

Autor: Ekkehard Domning (ekkehard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem beim Bulk Xfer ist, dass Du maximal 3MB xfersize geben 
kannst (ISOChron 4GB). Damit liefert jeder xfer Aufruf (wie beobachtet) 
maximal 3MB am Stück zurück.
Meine Lösung diese Problems sieht ungefähr so aus:
Es laufen zwei Threads (mit identischem Code). Im Thread gibt es einen 
Mechanismus der dafür sorgt das die Xfer funktion der API von beiden 
Thread im Abstand von einigen ms Aufgerufen werden. Damit setzt der 
jeweils zweite Aufruf die Datenabfrage des ersten (lückenlos) fort.
Damit konnte ich schon stundenlang unterbrechungsfrei Daten empfangen, 
allerdings bei ca. 5-10MB/s.
Bei 38MBs brauche ich immer nur relativ kurze Stücke, da weiß ich nicht 
ob es genauso geht.
Gruß Ekkehard

Autor: DS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen, hab bis jetzt mit einer Art Dual Channel Modus 
experimentiert, der FPGA schreibt abwechselnd 3MB in den EP2 (1024 Bytes 
doppelt gepuffert) und danach in EP6. Der PC leert diese dann 
abwechselnd in 2 Threads. So konnte ich Daten mit 20MB/s über Bulk 
streamen, ist allerdings zu wenig.
Daher bin ich auf eine Methode umgestiegen, die der von Ekkehard ganz 
ähnlich ist. Ich starte abwechselnd 2 Threads, die die Daten in 
3MB-Portionen von EP2 (1024 Byte, 4x gepuffert) abholen. So konnte ich 
schon mit 40MB/s streamen!!! Da sage nochmal einer dass der 
Cypress-Treiber langsam sei.

Gruß

Autor: DerDan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

So ähnlich hab ich das auch gemacht aber mit nur einem Thread:


Man startet zwei mal das Auslesen, aber ohne auf das Ende zu warten.

Nun wartet man auf das Ende des ersten Lesen. Sind die Daten da, so 
startete man sofort wieder mit einem Lese Befehl für den 1. Block.

Erst danach wartet man auf das Ende des zweiten Blocks. Den man dann 
auch wieder sofort startet.



und so weiter ...

Ich hab damit auch die 40MByte/s geschafft.


Mfg


DerDan

Autor: DerDan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja und logisch zusammenhängende Daten sollten immer nur über einen 
Endpoint übertragen werden sonst weis der PC unter Umständen nicht, wie 
er die Daten wieder zusammen setzen muss.

Autor: DS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind dann aber trotzdem 2 Threads, die die gleiche Funktion 
starten...

Und die Daten wieder zusammenzusetzen ist kein Problem, ich weiß ja 
welcher EP wieviel geholt hat...

Gruß

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]
  • [vhdl]VHDL-Code[/vhdl]
  • [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.