Wu, Ruiyu (GE Healthcare) wrote:
>> I would expect that the ftdi_read_data() call returns when either the
>> requested number of bytes has been read or when zero of fewer then the
>> requested number of bytes has been read and the timeout happened.
I think I remember that the FTDI chip can return something that causes an
earlier return than when it times out. Indeed, that was usually my
operating assumption. Timeouts for me usually only occurred in an error
condition (by my own design choices, so you could certainly set things up
otherwise), such as if the mcu on the other side got busy and didn't get
around to replying in time. FTDI has a document somewhere that indicates
all the situations in which the read will return fewer than 62+2 bytes (for
full-speed), including things like the latency timer expiring (def 16ms),
certain status lines changing, and perhaps a few other things. This early
return often propagates through ftdi_read_data().
Now if ftdi_read_data() actually returns zero bytes total when it returns
immediately (i.e., ftdi_context::usb_read_timeout is much longer than it
took to return and it returns 0), that might be worth discussing. How long
is it currently timing out at, what is the value of usb_read_timeout, and
how many bytes are returned?
Michael
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
