Hello Hendrik, more reasoning: - What exact device are you using? How large is the receive buffer? - Do you use any signalling between the FTDI and your serial device?
With 500 kBaud you receive about 50 bytes per ms. With a small receive buffer and no RTS/CTS signalling on the FT232R with its 128 byte buffer, overrun will happen in 3 ms. Your programm will wait forever for the lost bytes. The libftdi programm runs as a user program and other programms may keep your from the CPU quite for some time. Realtime kernels, as I understand it, only guarantee latency for kernel drivers, but not for a user program. So again, using the kernel driver may help. And if things go wrong with the kernel driver, it's a POOP (problem of other people) :-) - Is the Device directly plugged to the PC or via a hub. At least some time ago, a USB 2 full speed (vs USB2 high speed) device directly connected to the PC was only seviced from the linux PC in 1 ms steps. With an hub in between, USB micro frames were used and things happened in 125 us steps. This could also save you from overruns. - Is it a real FTDI device or some fake rebuild? In the latter case, you may hunt some FTDI-unrelated issues. >>>>> "Hendrik" == Hendrik <[email protected]> writes: ... Hendrik> [edit 2] I now see that as soon as the transfer goes wrong, the Hendrik> 2 status bytes that are transferred over USB (and don't show up Hendrik> in the packet data) start with 0162 instead of 0160 in the Hendrik> cases it goes OK. It remains 0160 until the next data packet is Hendrik> coming in... I don't see this behaviour in th pastbin logs... Bye -- Uwe Bonnes [email protected] 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 [email protected]
