Hi!

I reported problems with the ftdi_sio driver (for the FTDI FT232BM
USB-to-serial adapter) some time ago.  Now I've finally set up a null
modem connection to a Digital VT420 terminal.  I tested the connection
both with the integrated 16550 port of my computer and with a US232B
adapter attached to usb-uhci, using ftdi_sio v1.3.5 (kernel 2.4.25).

According to my analysis, the behaviour of the ftdi_sio driver differs
from the behaviour of the built-in 16550-based ttyS0 in two fundamental
ways:

(a) XON/XOFF handshaking is completely ignored when sending data
   (the 16550 is able to pause output at every N*16 chars written)
(b) write(2) calls return immediately
   (the 16550 driver blocks until all data has been sent)

I believe that the 16550 driver implements the proper behaviour
specified by POSIX.

These two differences probably explain why the C-Kermit terminal
application, which sends output one byte at a time by invoking
write(2) for each character, fails when trying to paste anything
longer than 4 or 5 characters at 300 baud.

Here are the stty settings, both for /dev/ttyS0 (16550) and /dev/usb/tts/0
(US232B a.k.a. FTDI FT232BM):

$ stty -F /dev/usb/tts/0 sane speed 300 -brkint -imaxbel -echo ixon

More verbosely:

$ stty -F /dev/usb/tts/0 -a
speed 300 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

When the terminal (Digital VT420) is connected to /dev/ttyS0, pressing
ctrl-s will pause output at the end of the 16-byte hardware FIFO.  It
looks like if ctrl-s is pressed after K received characters of a
write(2) of N characters, the output will pause after
MAX((K/16+1)*16,N) characters.

Here is a test case:

$ echo 01234567890123456789012345678901234567890123456789 > /dev/ttyS0
The Digital VT420 terminal will display the following test pattern:
01234567890123456789012345678901234567890123456789

The test can be repeated, pressing ctrl-s and ctrl-q at different points of
output.  The screen output can halt at three positions:

ctrl-s pressed on the VT420
=> 0123456789012345 (screen output pauses after 16 characters)
ctrl-q ctrl-s
=>                 6789012345678901 (again pause after 32 characters)
ctrl-q ctrl-s
                                   2345678901234567 (pause after 48 chars)
ctrl-q
=>                                                 89\r\n (resumed until end)

If I press ctrl-s at the end of a transmission, it will be ignored by
subsequent echo commands.  Only ctrl-s during a write(2) seems to
count.  (I guess that this is because the file descriptor will be
closed between echo(1) invocations.)

The ftdi_sio (/dev/usb/tts/0) seems to completely ignore ctrl-s
characters sent with the terminal.  I remember reading that the
hardware FIFO of the FT232BM is 128 or 384 bytes, much longer than the
test string above.  What if I send a longer string?

perl -e 'for($i=0;$i<40;$i++){printf "%c123456789",$i+64}' > /dev/ttyS0

On the 16550, the write(2) call will block until all 400 characters
have been sent.  If ctrl-s is pressed on the Digital VT420 terminal
and the perl process is terminated with SIGINT (ctrl-c), no further
characters will be sent to the terminal.

On the FTDI FT232BM, the write(2) call will complete immediately, and
the characters will be sent after the termination of the perl process.
Pressing ctrl-s on the VT420 has no effect on the output.  I tested
this with output strings of up to 800 bytes, pressing ctrl-s within
the first few bytes received.  All 800 bytes were always delivered.