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'?
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.
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.
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.
