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+unsubscr...@developer.intra2net.com
