> 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 [email protected]
