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_resources/datasheets/contents/cy7c68013a_8.pdf 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
Angehängte Dateien:
-
Read_Timing.jpg
190 KB
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
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
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.
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
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...?
Darf ich mal fragen, womit du das Timingdiagramm gemacht hast? :)
@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
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...
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
@ 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).
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_resources/technical_reference_manuals/contents/ez_usb_r___technical_reference_manual__trm__14.pdf @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
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_fastinterface26.html
Angehängte Dateien:
-
FSM_V1.jpg
140 KB
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
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.
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
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.
Ich habe im Internet noch was sehr schönes gefunden http://www.quickusb.com/store/media/QuickUSB_User_Guide_v2.11.41.pdf 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
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.
@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
@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
@ 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
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?
@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.
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.
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
@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
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.
@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
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....
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
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.
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
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
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
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....
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
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.
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
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?
Der Groschen ist gefallen, danke schön! Grüße pumpkin
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
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
Das komplette Entwicklungspaket für den FX2 gibts hier: http://download.cypress.com.edgesuite.net/design_resources/developer_kits/contents/cy3681_ez_usb_fx2_development_kit_15.zip
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
189 Warnungen? Das ist nicht normal. Mein Programm erzeugt 0 Warnungen, 0 Fehler. Sicher, dass du das richtige Header-File drin hast?
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
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
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.
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?
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.
>> 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.
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.
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.
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
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
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.
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)
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?
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.
Hallo Christian, mit welcher XFerSize arbeitet ihr denn? Und nach welchen Kriterien habt ihr diesen Wert festgelegt? Gruß DS
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.
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
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.
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
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.
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!
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.
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.
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.
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
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ß
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
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.
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ß
Hallo Ekkehard, DS und DerDan, könnt Ihr mir sagen, wie genau Ihr das gemacht habt? also welche Einstellungen und welche Treiber/Software? Oder gibt es mittlerweile irgendwo eine entsprechende Lösung zum runterladen? Ich habe nämlich auch einen Datenstrom, den ich weder anhalten noch irgendwie zwischenpuffern kann. Ich habe einen CLK mit 12MHz, DATA mit 12MHz Datenrate und alle 32 Takte noch ein NewData Signal, weil jeder Datensatz 32 Byte hat. Der nächste Datensatz schließt aber lückenlos an. Wäre nett, wenn Ihr mir da mit Euren Erfahrungen helfen könntet. Viele Grüße, Sabine
Auch wenn es nicht tum Topic passt: Ich verwende einen FT232H, der ist sehr einfach zu bespaßen auf FPGA Seite wenn man nur Daten vom FPGA zum PC schicken möchte. Auf PC Seite in C ist lesen auch nicht schwierig. 12MHz 32Bytes alle 32Takte sind 12MBytes/Sekunde? Kein Zwischenpuffern bedeutet das auch, dass du keinen FIFO im FPGA verwenden kannst?
:
Bearbeitet durch User
Hallo Sabine, das ist nun schon alles länger her, aber die Lösung auf der PC-(Windows)-Seite sah so aus: - Treiber mit "libUsbK" erstellen (s.a. http://libusbk.sourceforge.net/UsbK3/index.html bzw. https://sourceforge.net/projects/libusbk/). Der erstellte Treiber kann problemlos unter allen Windowsvarianten verwendet werden, es gibt keine Probleme mit der Signatur. Die Installation erfolgt mit einem automatisch erzeugten EXE-File. - Der Treiber kann dann vom Programm wie eine DLL angesprochen werden. Interfaces gibt es für C, Delphi etc. - Man benötigt nur einen Thread, weil der Treiber im Hintergrund die bereitgestellten Puffer füllt und man kontinuerlich die jeweils befüllten Puffer abholen und weiterverarbeiten kann. Ich selber schreibe die Daten dann in ein Queue, damit es beim Auslesen nicht zu Engpässen kommt. - Die Lesemethode funktioniert sowohl im Bulk- als auch im Isochronenmodus, wobei die Ansprache des Treibers etwas unterschiedlich ist. - Es sind Beispiele im "libUsbK" Developer-Kit vorhanden. Gruß Ekkehard
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.