>>>>> "Michael" == Michael Plante <michael.plante@xxxxxxxxx> writes:
...
Michael> The FTDI device has the SI/WU pin. How do you expect that to
Michael> function if you consider the current behavior "broken"?
>>> The SI/WU pin functionality isn't impacted.
Michael> Could you elaborate? What I expect is that libusb would send a
Michael> shorter-than-expected chunk to libftdi when that pin is
Michael> strobed, and the new libftdi would say "oh, it's still not
Michael> enough. read again." So the patch kills any expectation of
Michael> immediate action by the application. Where am I
Michael> misunderstanding? (Incidentally, I am referring to the "SI"
Michael> part, not the "WU" part, of the name.)
I meant that the behaviour between the device and the PC remains the
same. The user visible behaviour changes however (when requested size is >
available size).
But thinking and discussing longer, you are right, let's keep the old
behaviour. Even the proposed behaviour of "return at least some bytes or
when usb_read_timeout is hit" has the disadvantage of not being able to
interrupt and exit the program gracefully when the device transmits no data
but ftdi_read_data() is active.
But documentation must improve!
usb_read_timeout is purely used for basic USB handling and has no influence
on (normal) ftdi_read_data() behaviour. ftdi_read_data() returns at latest
when the latency timer has elapsed.
Ruiyu Wu, did you follow the discussion? You brought up the subject again.
In libftdi-1.0, reading data of known size is best handle with
ftdi_read_data_submit(). But it has no timeout yet. But that another
subject. And there is probably no official distributed libusb-1/usb1.sys for
Win32 that is ready for the asynchronous calls...
So, how to handle 0.18? I propose to revert ftdi_read_data() to the old
behaviour ( return after latency timer elased or with some data
available). As Michael points out, behaviour is very different from 0.17
behaviour.
Is it worth introducing to 0.18 something like ftdi_read_sized_data() that
reties for some time? Timeout should not be ftdi_read_timeout, as it is used
in another context. Otherwise user function expecting a known number of
bytes must implement their own timeout handling...
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
|
