Serial Issues

The FTDI chips we use have on-board buffers which occasionally require flushing at high data rates. From this arduino thread:

According to an article published in Elektor (European electronics magazine):

The often considerably slower data transfer rate of a virtual
RS232 interface connected via USB compared to a
‘genuine’ RS232 interface deserves some explanation.
Since USB is considerably faster than RS232, it should
be possible to emulate an RS232 interface running at a
speed of say 115,200 bit/s without difficulty: by comparison,
even low-speed USB devices like keyboards and
mice can operate at rates of 1.5 Mbit/s. On the USB
side, the USB-to-RS232 adaptors from [manufacturer1] and
from [manufacturer2] both operate in USB version 1.1 full speed
mode, with a data transfer rate of 12 Mbit/s. One would
think that this would be more than enough to emulate the
fastest RS232 port, but unfortunately there is a snag. Serial
data is transferred over USB in data packets. The data
packets are sent out at one millisecond intervals. The
receiver must check that a complete and correct data
packet has been received and send back acknowledgement
data. The shortest possible turn-around time for
sending a single byte over USB is three milliseconds. As
long as the data packets are sufficiently long, continuous
communication at a speed of 9600 bit/s is feasible over
the virtual RS232 port. This in any case presupposes that
large amounts of data are to be transmitted, for example
for driving a printer or modem. (…) Comparing
the speeds of virtual and real RS232 ports shows that the
USB-to-RS232 adaptor can guarantee to match the speed
of the real port up to about 9600 bit/s. At higher communication
speeds it starts to fall behind, since each byte
must be sent individually on the one millisecond timebase.
The transfer in this case will thus take exactly
60 ms for the 60 bytes.
The behaviour described above was observed under
Windows XP for both the adaptors tested. In comparison,
a genuine RS232 interface running at 115200 bit/s will
transfer 60 bytes in approximately 5 ms; the USB-to-
RS232 adaptor takes twelve times as long!
Things take even longer when relatively small quantities of
data need to be transferred back and forth alternately. For
example, in a microcontroller system a series of command
bytes may need to be transmitted and the microcontroller
may need to reply to each byte received: the USB protocol
will now bring the system grinding practically to a
halt. Irrespective of the direction of transfer, each byte will
take three milliseconds to send and hence the effective
data transfer rate will be just 167 bytes per second.
This example also shows that the data transfer rate will
increase if it is not sent one byte at a time, but rather in
groups of bytes.

From: USB-to-RS232 Hurdle Race
adaptor problems and tuning tips
elektor electronics - 9/2005 - page 38

FTDI has documented their latency problems here.

Our problem is that once the send rate begins to outstrip the chip's ability to keep up by sending a packet per byte, it starts to buffer bytes. This leads to timeouts when the ends of packets get stuck in the buffer. Our simple solution is to flush the FTDI's internal buffer with a series of 32 nulls after a packet. It significantly slows communications, but it's quicker than waiting for packet roundtrips to time out.

Unless otherwise stated, the content of this page is licensed under GNU Free Documentation License.