Hi,
On 4/14/07, Antonino Ingargiola <[email protected]> wrote:
Hi to the list,
I report a problem found with a device that use the FTDI chip to
communicate data to pc.
<summary of snipped problem description>
The scenario is: a serial device streams data continuously toward the
pc. The application requires the data be read once in a while (so not
all data is read). There is a corruption reading the data (old data
mixed with the new one).
The problem is absent in windows (using the same HW device and python code).
<end summary>
I report for reference how I solved the problem.
The problem arises because (while not reading) the input stream fills
the input buffer. Once filled, the buffer does not accept new data, so
the lost data is the new one not the old.
When one need to read the data he flushes the input buffer, but this
is not sufficient. In fact there is a second (hardware?) buffer in the
chain that, suddenly after the flush, pushes a chunk of old data in to
the input buffer. After this the new data is queued. This result in
data corruption at the edge between the new and the old data in the
buffer.
The problem has been reproduced also with an usb-serial device using
the cdc-acm driver and with two serial port linked by a null-modem
cable (so its not FTDI specific).
To solve the problem we must do a complete flush of all the buffer
chain. I do this flushing the input multiple times with a small pause
between them. In my case 10 flushes separated by a 10ms pause always
empties the whole buffer chain, so I get no corruption anymore. I'ts
not an elegant solution but it works (10 flushes are an overkill but I
want to be _really_ sure to read the correct data).
If someone know a better way to solve the problem is more than welcome
to suggest. Furthermore just a confirmation of my analysis of the
serial buffer behavior would be appreciated.
What puzzled me at first was that on windows the "flush" flushes all
the buffers, so the problem does not arises. Maybe Linux serial stack
works this way because is dictated by the POSIX standard ... I don't
know, just guessing.
Thanks,
~ Antonio
PS: For reference, the original report was:
http://marc.info/?l=linux-kernel&m=117683012421931&w=2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
