Hallo Forum, ich habe riesiges Problem. Bin Besitzer eine FX2LP(CY7C68013A). Nun versuche ich mit der DeveloperKit (SuiteUSB.NET) von Cypress herumzuspielen.... Leider scheitere ich schon an den elementaren Sachen. Der Treiber fuer das CYStream Beispiel wird nicht richtig erkannt und funktioniert nicht. Die anderen Beispiele von Cypress bekomme ich zum Laufen, allerdings nur wenn ich die schon kompalierte Firmware von Cypress verwende. Falls ich versuche den mitgelieferten Sourcecode selbst zu kompalieren und anschliessend die Firmware auf das Eprom schicke erkennt XP das Deviece nicht und der richtige Treiber wird nicht geladen. Der Support von Cypress ist nicht so wirklich der Renner. Hoffe jemand hat aehnliche Probleme. Gruss Peter
Da klinke ich mich mal mit ein. Hatte heute das Vergnügen endlich das Teil in Betrieb zu nehmen. Eigene Firmware ist drauf (basierend auf dem bulksrc-Code). Im EEPROM liegen 8byte für den "C0"-Load:
1 | 0xC0 |
2 | 0xB4 | |
3 | 0x04 | Cypress ID |
4 | 0x11 | |
5 | 0x11 | Produkt ID zum testen |
6 | 0x00 | |
7 | 0x00 | Version zum Testen |
8 | 0x01 | DISCON off, I²C 400kHz |
Nun möchte ich die Firmware beim Re-Numerieren aufspielen lassen. Also habe ich meine .hex in ein .spt gewandelt (CyScript) und unter system32../ sowie im Ordner des modifizierten Treibers abgelegt (ist das richtig so?). Anschließend habe ich das Beispiel CyLoad aus dem Driver-Ordner nach der Maßgabe der Hilfe umgebaut (wobei es da zwei unterschiedlich Versionen gibt: eine in der Hilfe zum CyUSB.sys Treiber und eine in der Hilfe zum EZ-USB Kit). In das modifizierte .inf habe ich die VID/PID meines EEPROM-Inhaltes eingetragen (für die Enumeration) und eigene Instanz mit eigener VID/PID im gleichen .inf für die Re-Numeration angelegt (VID/PID aus Firmware). Schließlich wollte Windows den Treiber kredenzt bekommen. Gesagt, getan. Windows kopierte das .spt und spielte es auf den Cypress. Anschließend erkannte Windows ein neues USB-Device und zeigte mir die Devicestrings aus meiner Firmware. Also schritt ich fort und fütterte Windows nochmals mit dem modifizierten Treiber. Das klappte dann nach mehreren Anläufen, aber leider kann ich nun nicht per CyConsole das Device auslesen. CyConsole zeigt kein Device an. Wenn ich versuche per API zuzugreifen gibt er mir auch Devicecount = 0 zurück. Nach vielen Stunden des probierens habe ich alles deinstalliert und meinen mehrmals modifizierten Treiber nur zur ersten Enumeration genutzt. Beim Re-Numerieren habe ich dann den normalen CyUSB.sys Treiber gewählt (den ich vorher mit meiner VID/PID versehen hatte) - so hat es auch funktioniert, bis ich es wieder deinstalliert hatte weil nicht konsistent/unsauber. Never touch a running system :^/ . Nun habe ich soviel rumprobiert dass ich nicht mehr weiss ob mein Vorgehen überhaupt richtig ist. Ist mein Denkansatz, zweimal den selben Treiber zu nutzen (mit zwei unterschiedlichen VID/PID-Instanzen), grundsätzlich falsch oder berechtigt? Auf Wunsch poste ich gerne das letzte .inf. Ich freue mich über jeden Tipp!
Man muss schon genau aufpasen. Für die aktuellen Chips kann man meines Wissens nur die CyUSB.sys nehmen, der alte EZUSB.sys geht nicht. Ich speichere die selbst kompilierte Firmware im EEPROM, das klappt bestens, sowohl bus- als auch self-powered. Zugreifen kann ich mit der CyConsole, mit der statischen Lib sowie der DLL für .NET Sogar LibUSB Win32 hab ich getestet, klappt bestens, sogar eigentlich einfacher als die statische Lib von Cypress. Wenn man diese Neu-Enumeration benutzt muss man aufpassen, dass man für die beiden Geräte in der inf Datei jeweils eine eigene GUID benutzt (GUID-Generator ist bei Visual Studio dabei), sonst kann der Treiber die Geräte nicht auseinander halten. Ich könnte mir vorstellen, dass die Probleme daher kommen.
Guter Tipp mit der GUID! Ich habe mal das .inf angebammselt. An der Stelle ;;; ####### [???] frage ich mich, ab ich dort ein [Cypress]-Äquivalent eintragen muss? Wie gesagt, ich bin mir nicht schlüssig ob das so laufen kann wie ich es dort habe. Die GUID habe ich jetzt erstmal unten als dummy eingefügt. Hast du weitere Vorschläge?
Naja, also sicher bin ich mir da nicht. Wie geschrieben, benutze ich immer das EEPROM. Ich seh da keinen Grund, diese komische Re-Enumeration zu machen, und die Firmware nur in den RAM zu laden. Bei uns macht die FW schon vor dem USB Anstecken einige Sachen auf der Zielhardware. Bei einem FX2-basierten USB-Boundary-Scan Controller, den wir einsetzen, wird das aber so in etwa gemacht, wie du das vorhast. Allerdings gibts da 2 getrennte Inf-Files, mit unterschiedlichen GUID. Vielleicht liegt da der Hund begraben? Benutz doch mal 2 inf-Files und lass dir vom GUID-Gen zwei verchiedene GUID generieren. Achja, und bei solchen Spielchen im Gerätemanager die versteckten (nicht angeschlossenen) Geräte anzeigen lassen und immer sauber deinstallieren.
Wie gesagt, als ich zwei getrennte .inf's genommen habe hat es
funktioniert. Ich denke, dass dort auf jeden Fall der Hund begraben
liegt wie du so schön sagst. Ab morgen werde ich es erstmal mit dem
EEPROM machen, ist halt die Backuplösung um voranzukommen.
> [...] Geräte anzeigen lassen [...]
Öhm, noch ein guter Tipp! Ich denke du meinst 'Ausgeblendete Geräte
anzeigen'?
Ja, und vorher die Umgebungsvariable setzen, damit der auch wirklich alles anzeigt.
@set DEVMGR_SHOW_NONPRESENT_DEVICES=1 @set DEVMGR_SHOW_DETAILS=1 @start %WINDIR%\system32\devmgmt.msc
So ist es. Am besten bei den Umgebungsvariablen dauerhaft hinzufügen, sonst ist es nach einem Neustart wieder weg. Also ohne Set dann. Und die 3. Zeile startet den Gerätemanager einfach.
Ich hätt' auch schnell googeln können ;^) Naja, jedenfalls läuft es jetzt wie gedacht. Habe es aber in zwei unterschiedliche .inf's gemacht, ist übersichtlicher am Anfang. Fehler eine falsch eingetragende VID im letzten .inf. Vielen Dank für eure Hilfe!
Na dann. Falls dir mal was schlaues einfällt, wie man über das Slave-FIFO Interface mehr als 22MByte/s in den PC bekommt, kannst du dich ja mal melden. Das kranke Timing des ext. Interfaces nervt gewaltig.
Ich hatte das schon (von dir) gelesen, dass das Timing nicht der Renner ist. Du schreibst 'Slave', ist es denn im Mastermode anders? Meine Konfiguration ist auch auf Slave ausgerichtet... Irgendwann soll mein Baustein über ein CPLD an einen DSP. Zukunftsmusik, ich denke das ich das nicht mehr erlebe - Praktikum. Jetzt heisst es erstmal eine kleine API bauen und die Peripherie vom aus PC ansteuern. Kleine Brötchen...
Naja, es gibt noch den GPIF Master, das ist aber auch nicht so das Wahre. Naja, mal schauen, vielleicht hilft ein geschicktes Füllen mehrerer Endpoins und/oder Buffer.
Tja Chris, keine Ahnung wie man da soviele daten durchpressen soll. Die Tage habe ich mit einer Probekonfiguration 20MBit(!)/s geschafft. Externe 27MHz Clock, 16Bit und OUT FiFo -> IN FiFo schaufeln. Ich habe den begründeten verdacht, dass der Rechner erheblich zur Geschwindigkeit beiträgt. Ich finde das Timing am Port garnicht so schlecht, allerdings wird es tatsächlich kritisch wenn man mit 48MHz reitet, da muss man schonmal hier und da einen Schweigemoment einlegen... Allerdings habe ich gerade ein wahrlich banales Problem: PortC5 ist als Ausgang konfiguriert, daran hängt ein CPLD der Hi-Z macht - sonst hängt nichts anderes dran. Der Pin will einfach nicht LOW gehen, jedenfalls nicht wenn ich einen Reset durchführe. Zudem schaltet er beim hochfahren den Pin stufenweise auf HIGH (erst gute 2V dann die 3,3V). Ziehe ich die Versorgung ab und wieder an klappt es (bus powered). IFCONFIG habe ich geprüft. Hast du eine Idee?
Ja, liegt auch viel am Hostcontroller. Intel ist da sehr fix, wir haben aktuelle Core2Duo Rechner bei uns. Hab jetzt die Tage nochmal getestet, direkt aus dem Cypress kriege ich 40,85MByte/s als maximum. Aber eben nur in eine Richtung. Wenn du erst Daten sendest und die dann zurück emfpängst, hast du natürlich nur maximal die Hälfte, dazu kommt dann noch der Overhead fürs Umspeichern usw. Wir haben aus einem FPGA mit 30MHz IFCLK, 16 Bit etwa 20MByte/s Upstream zum PC geschafft, allerdings nur mit Double-Buffer. Mit Quad-Buffer haben wir immer noch nicht getestet, ist momentan nicht so hoch prior. Ja, mit 48MHz wirds bissl haarig, aber machbar. Die GnuRadio Leute schaffen immerhin auch etwa 33MByte/s
Moin Chris, war ein dummer Fehler. Jetzt läufts. Du hattest hier mal ein modifiziertes Tool reingestellt mit dem du die Geschwindigkeit gemessen hast. Ich finde es nicht mehr, würde es aber gerne mal ansetzen (nutze momentan nur die CyBulk.exe und stoppe die Pakete ;^) ). Übrigens Respekt, >40MByte sind schon sehr sehr gut!
Den Quelltext kannst du per Mail kriegen. Öffentlich nicht. 40MB/s sind aber nur aus dem Chip möglich, also der 8051 setzt den EP immer wieder scharf, sobald es möglich ist.
Ist schon ok, hab mir gerade selber schnell etwas gebastelt. Trotzdem danke für das Angebot. Ich denke nicht, dass es einen großen Geschwindigkeitsvorteil bringt mit Quad zu fahren wenn die Daten nicht sehr 'bursty' sind oder der Host mit mehreren Devices zu kämpfen hat. Wenn man hintereinander weg schaufelt reicht Double.
Kann sein, dass es nicht viel bringt. Wie gesagt, wollen wir noch ausprobieren.
Nach welcher Anleitung hast du die .inf Datei angepasst? Ich habe soweit ich weis keine gesehen. Oder wie kann ich das ins EEPROM laden? Mit dem EZ-USB Control Panel? Wenn ja geht das bei mir nicht, weil es immer abstützt wenn ich dies versuche.
Inf-Datei Anleitung? Anschauen - Verstehen - Ändern, ist doch total billig. Und wenn das EZ-Control-Panel abschmiert.....hmm...keine Ahnung, bei mir gehts. Welches OS hast du denn?
Jetzt hab ich die Anleitung gefunden.....und ist wirklich nicht schwer. Aber mal ne andere Frage. - Was sollte man jetzt eigentlich eher nehmen....EZUSB.sys oder CYUSB.sys nutzen? - Wie genau kann ich über die CYAPI die Firmware dazu bringen was zu machen? Ist mir irgendwie noch nicht ganz klar. Endpoints und DeviceInfos kann ich auslesen.
Neuling wrote: > Jetzt hab ich die Anleitung gefunden.....und ist wirklich nicht schwer. Sag ich doch. > Aber mal ne andere Frage. > - Was sollte man jetzt eigentlich eher nehmen....EZUSB.sys oder > CYUSB.sys nutzen? Für den FX2 auf jeden Fall die CYUSB.sys sonst krachts. > - Wie genau kann ich über die CYAPI die Firmware dazu bringen was zu > machen? Ist mir irgendwie noch nicht ganz klar. Endpoints und > DeviceInfos kann ich auslesen. Was willste denn noch machen? Alle Funktionen, die der 8051 im FX machen soll, musst du in der Firmware selber schreiben. Dazu gibts die Keil Entwicklungsumgebung und die Beispiele.
OK, dann nur CYUSB.sys. Ich habe mittels eines Beispiels Waveforms mit dem GPIF Desginer erstellt und die dazu gehörigen Anpassungen in der Firmware gemacht. Jetzt muss ich doch irgendwie von Windows aus mit der CyAPI die Firmware zum laufen bringen und korrekt meine Daten abholen. Und da fehlt mit gerade der Ansatz wie das gehen soll. Achso....Firmware ist schon im internen RAM.
Leider zu früh gefreut. Irgendwie will das mit dem Treiber nicht klappen. Beschreibe mal kurz mein vorgehen und hoffe ihr erkennt den Fehler. 1. Firmware aus GPIF Designer\fifo genommen und minimal angepasst (nur einen Endpoint verändert, somit zwei Eingänge) 2. kompiliert und nun hab ich meine *.hex *.iic 3. Mit CySkript aus der erstellen Hex Datei eine *.spt Datei erstellt 4. Inf Datei angepasst (Device Name, Pfad zur .spf Datei) 5. USB Controller verbinden und Treiber installieren (erstellte .inf) -> klappt alles Wenn ich nun mit dem Control Center mit die Endpoints anschaue habe ich keine zwei Eingäne, sondern einen Ausgang und eine Eingang....wie in der Originaldatei die angepasst wurde. Wisst ihr wo meine Fehler ist? Wie kann ich genau feststelle das meine erstelle .spt Datei verwendet wird. bin für jeden Hinweis sehr dankbar.
Da kann ich dir nicht helfen, ich benutze das EEPROM, und da klappt alles immer. Das iic File lade ich mit der CyConsole hoch.
Hallo, ich hatte auch erhebliche Probleme mit dem Erstellen der Deskriptoren. U.A. damit, dass die Tabellen immer auf "geraden" Speicherstellen beginnen müssen. Natürlich muss auch die angegebene und tatsächlich Anzahl der EP übereinstimmen. Ich hatte mich da etliche Male in's Aus navigiert. Den Firmware upload habe ich in meine Anwendung integriert (cyAPI Beispiel), so kann ich die HEX Datei direkt verwenden. Gruß Ekkehard
Hab es jetzt hinbekommen. Ich hatte vom Quelltext der Firmware entsprechende anpassungen den Endpoints gemacht. Nun habe ich gesehen, das dies aber nicht in der Datei dscr.a51 geändert wurde. Ist das richtig das ich das immer manuell ändern muss? Eine weiter Frage habe ich aber noch: Ich verbinden den USB Controller mit dem PC und installiere ihn mit meiner erstellen INF. Sollte somit schon die Firmware theoretisch schon in den internan RAM geschrieben worden sein? Ist bei mir nicht der Fall (kann ich in der Control Center sehen). Wenn ich nun über das Control Center was in den internen RAM schreibe meldet sich Windows wieder und verlangt nach einen Treiber. Dann gebe ich ihn wieder meinen ertsellten und die Firmware ist im internen RAM. Ist dieser Weg so korrekt oder ist irgendwo noch ein Fehler in der INF Datei zu suchen?
Es ist genau so. Der Cypress schaut ins EEProm, er findet dort nichts sinnvolles, meldet sich mit der standard PID/VID Kombination. Windows lädt den Treiber für diese PID/VID. Dann lädts Du Deine Firmware und sagst "RENUM" dann meldet sich der Cypress ab und wieder an, diesmal mit der PID/VID Kombination die Du ihm gesagt hast. Windows lädt den Treiber für Deine PID/VID. Fertig. Christian sagte ja schon, dass Du die Firmware ins EEProm schreiben kannst. Alternativ kannst Dun im EEProm die PID/VID ablegen unter der der Cypress sich nach dem Reset melden soll.
Alles klar...war mir nur nich 100%ig sicher ob es so ist. Zur Zeit lade ich den Firmware entweder mit dem Control Center oder mit fxload-libusb in den controller. Welche Funktion kann das den von der CyApi? Ich habe da keine Beispiel gesehen. Kannst du mir maml bitte sagen wo das steht. Würdees mir zumindest mal anschauen wollen.
...eine sache habe ich vergessen....was bringt es mir in die INF Datei die .spt Datei einzutragen und was soll die machen? Wenn die in dem Ordner nicht ist wie angegeben geht auch alles wunderbar.
Bei dem cyAPI Zeug gibts ein Beispielprojekt "fxEEProm" da ist im MainF.cpp eine Funktion die ein HexFile in's Ram schiebt.
Ok danke. Das Projekt habe ich mir natürlich nicht angeschaut, da es ja fxEEProm heißt und ich dachte das Programm schreibt dann nur was ins EEPROM.
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.