Hi,
I'm having problems with the ftdi_sio driver. My RS-232 software does not
work with the US232B adapter, which is based on the FTDI FT232BM chip.
To investigate the problem, I set up a 300 bps connection to a Digital
VT 420 terminal and enabled XON/XOFF handshaking.
I made three different tests:
Linux 2.4.25 with 16550 serial port driver
Linux 2.4.25 with ftdi_sio v1.3.5
Windows XP with the newest FTDI driver
When I send a block of data to the serial port and try to interrupt it by
pressing ctrl-s on the VT 420, the 16550-based interface will stop after
transmitting N*16 bytes. The Win32 FTDI driver stops after sending 2 to 4
more bytes. The ftdi_sio driver doesn't honor the ctrl-s at all!
Furthermore, the process write()ing to ftdi_sio will exit long before
all the data has been transmitted. When sending to the 16550-based
interface, the process will not exit until everything has been sent.
Could someone please have a look at this? I'd try to fix it myself,
but I'm not very familiar with the USB protocol stack.
With best regards,
Marko Mäkelä
http://www.funet.fi/~msmakela/
More detailed report follows:
I believe that the 16550 driver implements the proper behaviour
specified by POSIX.
These two differences (ftdi_sio not honoring XON/XOFF handshaking, and
allowing write() to return immediately) probably explain why C-Kermit
fails when trying to paste anything longer than 4 or 5 characters at
300 baud. (C-Kermit invokes write(2) for every character it sends.)
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 VT 420) 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 VT 420 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 VT 420
=> 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+32}' > /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 upon receiving ctrl-q.
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 VT 420 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.
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
