> The way the libftdi and usb scheduler work is as below:
> If you requested data size is less than the read chunk size, then the
> FTDI chip latency timer (default timeout is 16ms) kicks in and keeps
> the data in the FTDI chip buffer for that long before it flushes out.
> To change the default latency timer, use ftdi_set_latency_timer() to a
> minimum value. As you are reading only one byte at a time, you always
> have got the 16ms delay. Refer to AN232B-04 "Data Throughput, Latency
> & Handshaking" document at
> http://www.ftdichip.com/Support/Documents/AppNotes.htm for further
> details.
> My understanding is FTDI is not the right device if you are targeting
> ultra low latencies, but it is good for achieving high throughput.
Thanks for the info. I've got various i2c peripheral devices hanging off
the i2c bus and I just bit-bash registers on most of them as byte accesses
(excluding an eeprom which is read & written with variable length data -
writes are page written for efficiency). It would appear that a register
read on one of the peripheral devices doesn't work because of the 16ms
extra time waiting. The device appears to give up and only every second
access works. If I drop the latency to 6ms access is fine. If
ftdi_read_data() returned after having read the byte I asked it to it
would be even better :-)
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
