Hallo zusammen... ich habe da irgendwie ein kleines Problem: ich habe einen AD-Wandler (AD EVAL-AD7760/62EDZ) an ein Cypress FX2 Dev-Board angeschlossen. - ich benutze das GPIF-Dev-Tool um die Waveforms zu erstellen - den Takt für den FX2 hole ich mir vom AD-Board (in dem Fall 40MHz) ...soweit funktioniert eigentlich alles: ich kann den ADC programmieren und bekomme auf Anfrage auch meine 16Bit Daten-Pakete ABER: ich lasse vom FX2-GPIF immer 128 x 4 Bytes auslesen und in einen FIFO schreiben...wenn der Puffer voll ist kann ich das Paket vom host auslesen lassen: dies geht aber immer nur maximal alle 250us ?! Ich habe mir das ganze dann mal auf eine Logic-Analyzer angeschaut: die "Schleife" für die GPIF-Waveform dauert max 60us, dann lässt er eine laaange Pause und fängt erst dann wieder an...es sieht irgendwie so aus, als ob der Endpunkt nicht wieder freigegeben wird? ( http://nanos.kilu.de/FX2/logicanalyzer.JPG ) ...habe alles durchgeschaut: die Größe der Endpunkte auf 512 im Highspeed Modus; AutoIn nach 512; usw... kann mir einer weiterhelfen? danke schonmal
Wieveiel Daten holst du denn pro Transfer ab? Nur die 512 Byte? Dann wäre das klar. Ein Microframe (125µs) geht drauf um die Waveform anzustoßen, ein weiterer für den Transfer. Wenn du richtig schnell werden willst, musst du gleich vielfache von 512 Byte pro Transfer abholen, also meinetwegen gleich 10kiByte oder sowas. Dann packt der so viele Pakete in einen MicroFrame wie möglich.
Hallo Christian... ...also daß es 1 Microframe braucht um die Waveform anzustoßen, wußte ich nicht (stand auch irgendwie nirgends?!)...aber dann macht das erstmal soweit Sinn! Momentan hole ich nur 512 Byte über einen Bulk-EP. Jetzt zu dem vielfachen Senden: wo stelle ich das genau ein? Bei einem Iso-EP stellt man das ja beim Endpoint-Descriptor ein...aber beim Bulk-EP? mfg Patrick
Also ob der Frame wirklich gebraucht wird, weiß ich nicht, mit dem GPIF hab ich noch nicht viel gemacht. War nur eine Vermutung. Das stellst du nirgends ein, das macht der Treiber und der Host von alleine. Du musst einfach in deinem Programm mehrere 512 Byte Blöche mit dem Transfer anstoßen. Dann wird das richtig schnell. Ob das GPIF dann aber eventuell der blockierende Faktor bei dir ist, weiß ich nicht....das ist ja auch recht aufwendig zu konfigurieren.
...mmhh... dann wird wohl der GPIF selber der Bremsfaktor sein, da ich eben vom host ständig Anfragen sende, aber das device mir nur in diesem 250us-Rythmus die Daten zurückschickt! Und pro Anfrage darf ich ja auch nicht die eingestellte Größe meines EP überschreiten, eben die 512 Byte, sonst fliegt mir ja der Treiber raus?! ...und den GPIF brauche ich, da ich den ADC sonst nicht anders ansprechen kann! mfg
Patrick Vogel schrieb: > ...mmhh... > > dann wird wohl der GPIF selber der Bremsfaktor sein, da ich eben vom > host ständig Anfragen sende, aber das device mir nur in diesem > 250us-Rythmus die Daten zurückschickt! > Und pro Anfrage darf ich ja auch nicht die eingestellte Größe meines EP > überschreiten, eben die 512 Byte, sonst fliegt mir ja der Treiber raus?! Eben gerade nicht. Du musst mehr als die EP-Größe anfordern, wenn du schnell sein willst, und das funktioniert auch. Welchen Treiber hast du? Den aktuellen 3.4.110? Bei uns gibts da keine Probleme, wir fordern mitunter gleich mal 128kiByte an.... Wenn du ständig Anfragen über 512 Byte schickst, kommst du maximal auf 4MB/s etwa und erzeugst eine hohe Prozessorlast...
...ich benutze den ezUsb-Treiber (V1.30.00) und da ist es wie gesagt so, wenn ich versuche über:
1 | |
2 | _BULK_TRANSFER_CONTROL = record |
3 | pipeNum: Longword; |
4 | end; |
5 | BulkControl: _BULK_TRANSFER_CONTROL; |
6 | Buffer: array [ 0..1023 ] of Byte; |
7 | |
8 | IOCTL_EZUSB_BULK_READ := CTL_CODE ( FILE_DEVICE_UNKNOWN, |
9 | Ezusb_IOCTL_INDEX + 19, |
10 | METHOD_OUT_DIRECT, |
11 | FILE_ANY_ACCESS ); |
12 | ...
|
13 | bResult := DeviceIoControl ( _Handle, |
14 | IOCTL_EZUSB_BULK_READ, |
15 | @BulkControl, |
16 | SizeOf ( BulkControl ), |
17 | @Buffer, |
18 | NumberOfBytes, |
19 | nBytes, |
20 | nil ); |
mehr als 512 Bytes anzufordern, dann fliegt mir der Treiber um die Ohren!? ...ihr benutzt wohl den CyUSB oder? vielleicht sollte ich den mal probieren... mfg
Uargs....der ezUSB ist für die alten AN2131 usw. und nicht für den FX2LP gedacht. Nimm auf jeden Fall den aktuellen CyUSB Treiber (3.4.110). Gibts auf der Homepage.
...so jetzt habe ich das Ganze auf die CyUSB Treiber umgeschrieben... coole Sache...jetzt läuft das richtig flott! ABER: es gibt da immer noch ne 'Pause' zwischen 2 GPIF-WF -> ca 6 us !! ...jetzt versuche ich gerade immer mehr 'unnötige' Sachen abzuschalten, aber weiter gehts nicht runter... hat noch einer ne Idee? danke Patrick
Hallo, ich arbeite an einem aehnlichen Projekt, wo ich einen AD7760 durch die GPIF im FX2 asycron auslese. Dabei verwende ich den EP6 (HIGH-Speed, Bulk, Quad buffered) mit FIFO im AUTOIN-Mode , was mir praktisch ohne FW-Code in TD_Poll() erlaubt den FIFO des EP6 automatisch zu fuellen. Dies funktioniert soweit bis zu einer Abtastrate von 625kS/s gut, aber bei hoehere Abtastraten (1250 und 2500 kS/s) "stottert" das Spektrum. Es sieht so aus als ob irgendwo Samples verloren gehen. Zum auslesen des EP6 fordere ich mittels usb_bulk_read der LIBUSB-API Datenbloecke zu je 4096Bytes an, aber auch bei groesseren Anforderungen an Datenmengen aendert sich dabei nichts. Da wir bei ungefaeher 2,5MByte/s (625000 Samples/s * 4 byte) weit unter der Performancegrenze eines FX2 liegen, moechte ich euch fragen ob jemand bereits ein aehnliches Problem hatte bzw. Tipps fuer einen Loesungsansatz dazu hat. Vielen Dank, Martin
Bitte 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.