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 <chasake@xxxxxxxxx> 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 bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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 libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
