On 12/02/2014 04:29 PM, Anders Larsen wrote:
Yes it is but it happens very frequently with a low latency and
almost never (I have now ran into the problem a couple of times with
the latency set to a high value too, but it is very infrequent) happens.
is latency an issue for you (could you live with 16ms, where your
problem seems not to manifest itself)?
Yes it is. Because the protocol is 'request -> reply' it is better to
have a faster turn-around time so we can handle (a lot) more data per
second.
Bear in mind that a low latency value will consume more CPU power on
Linux, too!
I have seen that but the overhead seems to be far lower than on Windows.
I found out that the FTDI_SIO driver has some entries in /sys in which
you can set the latency as well so we might still go that way if this
doesn't work out. But I liked the feeling of having a more direct
connection to the FTDI like I used to on Windows. It's also quite
straight-forward what happens in case USB errors occur (ESD spikes, USB
problems, disconnections) as these are handled in the LIBUSB return
codes that are passed through by libftdi. I don't know what FTDI_SIO
does with these things as being a kernel serial port, these errors
should not even be possible (you usually have no USB problems with a
real serial port :)).
A large portion of the Windows code was about cleaning up and restarting
USB devices in case the FTDI device hung so the low-levelness was
another reason for immediately going for libftdi when switching to Linux.
Regards,
Hendrik
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|