Hi Marko, I am currently trying to push a different patch into the ftdi driver as it doesn't handle DTR line transitions correctly when switching baudrates. I'll take a look at this too then. I think the entire datachunk, that you send to the driver actually fits into 1 single URB -> a communication quantum in the USB framwork and once the URB gets submitted to the kernel, the data gets on wire. Could you test with bigger data chunk as you proposed?
Jan Jan Capek - CCS Inc. Firmware developer On Fri, 14 May 2004, Marko [iso-8859-1] Mäkelä wrote: > 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 > > ------------------------------------------------------- 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
