Patrick Van Esch wrote:
> Hello,
>
...
> However, when I tried to do the following:
> The computer sends a small block (8 K bytes) of random bytes to the
> FTDI chip, where this is clocked in by the FPGA, and then the FPGA
> sends this BACK (using a second 2-clock fifo) to the computer, and
> the computer checks for integrity (that it are the SAME random
> numbers that were sent out), the data rate goes down to less than 4
> MB per second (4 MB reading, 4 MB writing). I checked that the
> fifos on the FPGA are NOT full. The data integrity is OK.
>
> In fact, looking with an oscilloscope to the TX# and RN# signals, I
> see that the reading and writing goes actually very fast of one
> block (8 K bytes), and then there is a PAUSE OF SEVERAL
> milliseconds, before the next salve comes, initiated by RN# signals.
> The FPGA gives priority to reading (so to RN#).
>
> So it seems that it is the COMPUTER that pauses after a cycle of
> sending 8 KB and reading it back, which gives me a lower average
> data rate.
It could be the computer, sure; typical operating systems aren't
designed for realtime, low-latency use, and a few milliseconds here
and there should be expected. You can probably get a better idea of
what's going on by using wireshark on the USB side of things, since
that's closer to the PC's actions (whether the microframes aren't
getting used, whether the read request was really delayed, or the FTDI
just didn't have data yet, etc).
You could try submitting multiple URBs, so that the host controller
has a buffer of things to do. For example, submit both write and
read, and wait for completion of both. I've done this in the past
before libftdi gained async support; these days you should be able to
use ftdi_write_data_submit, ftdi_read_data_submit, and
ftdi_transfer_data_done.
-jim
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
