libftdi Archives

Subject: RE: libftdi: Make ftdi_read_data() honor usb_read_timeout

From: Uwe Bonnes <bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Tue, 29 Mar 2011 12:09:39 +0200
>>>>> "Michael" == Michael Plante <michael.plante@xxxxxxxxx> writes:

    Michael> Uwe Bonnes wrote:
    >>> 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.

    Michael> I expect what's available to be returned if the FTDI chip
    Michael> indicates that it should be.  But my read call always blocked
    Michael> for a small amount of time, depending on how much data the FTDI
    Michael> chip was ready to push out.  That was desirable.  Blocking for
    Michael> the full timeout value is not desirable, and setting it
    Michael> extremely small just hogs the CPU.

But again, the behaviour is unexpected compared to all other read() calls I know
of. How would you implement your requirement of reading variable length
response with low latency with a uc connected to a real serial port. 
char buf[BIG];
int fd = open ("/dev/tty");
read (fd, buf, BIG);
wouldn't give you the result you expect libftdi() to work.

You would probably read single bytes until you have a sensible
response. Working that way for your use case in libftdi already works, and with
the libftdi internal buffer getting filled with the first sucessfull
libusb_bulk_transfer() wouldn't produce system call overhead. So the same
argument
    Michael> Ok, but that's not additional CPU overhead, it's additional code 
complexity.
holds also for your use case...

That doesn't mean I understand your requirements, and libftdi should work in a
sensible and _well documented_ way and in consense with as many users as 
possible...

...
    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.

What about 
- returning when at least some data has been read
- or ftdi->usb_read_timeout has expired?

At present we always return when the latency timer expires.
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   

Current Thread