Uwe Bonnes wrote:
>> >>>>> "Thomas" == Thomas Jarosch <thomas.jarosch@xxxxxxxxxxxxx> 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 libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
