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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
