Hello Uwe,
I made a USB dump of the situation. My device is instructed to report
back the 522 bytes packet that contains a 512 byte payload with the
pattern 00 01 02 ... fd fe fe 00 01 ... fd fe ff. You can see that at
the start of the dump it works fine, but then after a while an
incomplete packet is received which is missing data in the middle. These
kind of patterns (some ok packets, then an incomplete packet) repeat
over and over.
The pastebin of this you can find here:
http://pastebin.com/raw.php?i=KqvwqGGf and you can also find the problem
part in a separate pastebin at http://pastebin.com/raw.php?i=3Vwk2NAs
which is cleaned up a bit to show that there is indeed data missing.
When the latency timer is set to 16ms it looks like this
http://pastebin.com/raw.php?i=1aSYzbXu and there are no lost bytes
anymore so it seems like there is some interference of the latency
timer expiring and the data being received by USB.
Or that somehow the timer expires twice while a data transfer is already
in progress.
The
http://www.ftdichip.com/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf
speaks about these corner cases and there are also some more reports on
this mailing list about lost data but those cases are very specific in
the way that there is either 'unlimited' data coming in (not bounded to
a certain size but an ongoing stream of data) or the fact that there is
full duplex communication going on (so USB writes interfere with the USB
reads). In my case I am only waiting on a packet (even waiting on USB
traffic at all) to arrive which in turn does arrive but is broken
somehow..?!
[edit, another post from Uwe came in]
> This doesn't tell _why_ you don't use the kernel driver...
Well, I don't really know either ;). I have been using the Windows FTDI
driver with their lower level API because Windows serial ports suck. The
API allows me to do some calls that buffer the data the way I want and
we can also address the port by their USB specific information (e.g. the
serial number of the device instead of just 'COM<something>' (which is
cumbersome especially if there are many devices connected). Also the API
allows me to do a 'read' with a 'number of bytes' parameter that ONLY
returns if either that number of bytes are present OR the given timeout
expires. The standard serial port implementations, given a number of
bytes and a timeout ALSO return when less that the number of requested
bytes are present (as long as it is not 0 bytes or the timeout expired),
so I had to do the 'reassembly' of packets myself (using C# this was not
nearly as efficient as the FTDI driver just giving me what I wanted OR a
timeout).
So, thus far I haven't really looked at FTDI-SIO as I expected it to be
a 'serial port driver' instead of being a lower level API to get what I
want. I might give it a try now though :). I also haven't tried the
closed source driver from FTDI themselves, but mostly because it is,
well, closed source. I have experienced a lot of 'weirdness' (but never
lost bytes :)) using their Windows counterpart.
I will also implement the async version and see what it does and let you
know.
[edit 2]
I now see that as soon as the transfer goes wrong, the 2 status bytes
that are transferred over USB (and don't show up in the packet data)
start with 0162 instead of 0160 in the cases it goes OK. It remains 0160
until the next data packet is coming in...
Thanks so far and regards,
Hendrik
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
