Uwe Bonnes wrote: >> >>>>> "Thomas" == Thomas Jarosch <[email protected]> writes: >> >> >> Thomas> One thing comes to my mind: What happens to applications >> Thomas> expecting the current behavior? I'm currently trying to figure >> Thomas> out if this would break something. Hmm. >> >> At present, mosten no Byte is returen, but also sometimes some bytes of the >> request, depending on rate and scheduling. So the application must cope with >> the data even in the old behaviour.
Sorry, this one slipped by me. I haven't had a chance to test with the new version. But say that usb_read_timeout is 5000 (5 seconds), the default. Does the use case of 1) passing a large buffer 2) reading as much as is available 3) returning immediately no longer work? The benefit of that use case is that the microcontroller can decide exactly how much data needs to be returned, rather than expecting the host to need to know, and without waiting for the timeout to expire. If it no longer works, that reduces me to either A) having to read one byte at a time with ftdi_read_data, which is of course a pain (sure I can read one byte at a time and check how much libftdi read, but that's still extra overhead) B) seeing if libftdi-1.0 can satisfy my needs C) staying with an older release of libftdi I figured that, given such a LONG timeout, timeouts were supposed to be considered a last resort. If *you* want slower timeouts, shouldn't you just set the latency timer on the ftdi chip higher? Regards, Michael -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
