Just a reminder that last summer I saw that the code in serial_ftdi_read() doesn't guarantee that a timeout occurs in the desired timeout period. Due to the way it is written, you can get MUCH longer delays when the bytes don't stream in right away or This was an issue I was fighting last year when I was trying to get retries to work on the Pelagic data cable with Android. It actually affects any ftdi device. This is likely an issue on Windows as well.
ftdi_read_data() took a few milliseconds of time before returning and that time is not accounted for. And on android the the LIBUSB_ERROR_INTERRUPTED was also happening. This caused the while loop to loop for several minutes before timing out. My solution (which I posted a patch for to the list back in Nov 2017) was to get rid of slept and to always sleep for 1ms. Then rather than comparing slept >= timeout - which doesn't work, was to use gettimofday() to check for the elapsed time to check for the desired timeout period. --- bill
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
