>>>>> "Michael" == Michael Plante <michael.plante@xxxxxxxxx> writes:
Michael> 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
Michael> figure
Thomas> out if this would break something. Hmm.
>>> At present, mosten no Byte is returen, but also sometimes some
>>> bytes of
Michael> the
>>> request, depending on rate and scheduling. So the application must
>>> cope
Michael> with
>>> the data even in the old behaviour.
Michael> Sorry, this one slipped by me.
Michael> I haven't had a chance to test with the new version. But say
Michael> that usb_read_timeout is 5000 (5 seconds), the default. Does
Michael> the use case of
Michael> 1) passing a large buffer 2) reading as much as is available 3)
Michael> returning immediately
Michael> no longer work? The benefit of that use case is that the
Michael> microcontroller can decide exactly how much data needs to be
Michael> returned, rather than expecting the host to need to know, and
Michael> without waiting for the timeout to expire.
Michael> If it no longer works, that reduces me to either
Michael> A) having to read one byte at a time with ftdi_read_data, which
Michael> is of course a pain (sure I can read one byte at a time and
Michael> check how much libftdi read, but that's still extra overhead)
Michael> B) seeing if libftdi-1.0 can satisfy my needs C) staying with
Michael> an older release of libftdi
Is this your use case? The (microcontroller) device has already sent some
data. Now you do ftdi_read_data(struct ftdi_context *ftdi, unsigned char
*buf, big_size) and expect all data already in the FT fifo to be
returned even when the number of bytes available is smaller than the
requested number. With the change I introduced in libftdi-0, the call would
return
after usb_read_timeout with all available bytes or immediate when SIZE is
fullfilled.
So you would have to set the timeout to a sensible value before your call
and you should nearly have the old (broken) behaviour back. The behaviour to
return immeadate is however broken i.m.h.o. No other read(..., SIZE) call I
know of will return immedate when neither size nor timeout is satisfied.
Look at my use case: My devices starts to spew out data at high rate with
some command sent. To catch all data. I have to start reading before the
command is sent, otherwise I may overrun the FT internal fifo .
With ../examples/serial_read this spews out lots(!) of
"read 0 bytes" with a frequency of about 65 Hertz. So now I have the
overhead you talk about in "A" in my user application and in additional
calls to ftdi_read_data(). Is this better?
Best way would probably be to provide a way to query the devices about
available bytes in the buffer. Or perhaps provide a blocking and
non-blocking ( old behaviour) ftdi_read_data(). But the present behaviour
hurts the principle of "minimal surprise".
Michael> I figured that, given such a LONG timeout, timeouts were
Michael> supposed to be considered a last resort. If *you* want slower
Michael> timeouts, shouldn't you just set the latency timer on the ftdi
Michael> chip higher?
This has no influence on ftdi_read_data(). In ftdi_read_data()
ret = libusb_bulk_transfer (ftdi->usb_dev, ftdi->out_ep, ftdi->readbuffer, \
ftdi->readbuffer_chunksize, &actual_length, ftdi->usb_read_timeout);
will return immedate despite a higher latency time and ftdi_read_data() will
still return immediate.
What to do:
- keep the old behavout?
- Implement some ftdi_available_date() calls
- Split into a blocking and non blocking behaviour?
Bye
--
Uwe Bonnes bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
