Hi Jan,

> 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 see.  On Windows, my program that does bit-banging with CTS, RTS and TxD
(serial programming of Atmel AVR microcontrollers) did not work with the
FTDI driver.  The culprit appears to be that the Windows driver caches the
last read status of the modem lines.  On Linux, this form of bit-banging
works, but it is about 10 times slower than over the 16550.

> 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?

If I interpreted Documentation/usb/URB.txt and ftdi_sio.c correctly, the
data is sent in chunks of 64 bytes, and there are 32 write URBs, suggesting
a write buffer size of 32 * 64 = 2048 bytes.  Is this correct?

I'm testing this on 2.4.26 right now.  After the normal
output of "stty -F /dev/usb/tts/0", I get a kernel message
"ftdi_sio.c: Error unlinking urb".  I don't remember getting that
message on kernel 2.4.25.  I also get this message after any
command that outputs to /dev/usb/tts/0.

At 38400 bps, the VT420 terminal seems to have a fatal input buffer overrun
after receiving about 280 bytes consisting of 8 characters and CR+LF.
It also loses a few lines every now and then.  The kernel reports
"ftdi_sio.c: write request of 0 bytes" several times, followed by
"ftdi_sio.c: Error unlinking urb".  According to strace, the perl
command I wrote writes the data in chunks of 9 bytes.  If I output
the test string to a file and cat it to /dev/usb/tts/0, strace will
show a single write(2) of 2565 bytes.  The outcome isn't any different:
I get multiple "write request of 0 bytes" messages.

If I stty -onlcr 2400, the "write request of 0 bytes" messages go away, and
the terminal won't receive any garbage.  There is probably a bug in the
onlcr handling of usb-serial or ftdi_sio.

The cat command writing to the terminal exits after sending at least 500
characters, with about 2000 remaining to be sent.  It appears that the
ftdi_sio driver allows write(2) to return with up to 32*64=2048 unsent
bytes in the write URBs.

Even if I press ctrl-s within the 50 first sent characters (while the
cat process is still running), the output won't stop until all 2850 bytes
(285 lines of 8 chars+CR+LF) have been transmitted.  The XON/XOFF handshaking
is enabled (stty ixon).

Please let me know if you would like to have further tests.  I'm glad to test
any patches on the 2.4.x kernel series.

        Marko Mäkelä


-------------------------------------------------------
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

Reply via email to