On 24/9/22 02:39, John R. Hogerhuis wrote:
On Fri, Sep 23, 2022 at 2:59 AM Brian White <[email protected]
<mailto:[email protected]>> wrote:
I believe all the right chip does is help, and make more code more likely to
make it through
Chip/driver wise the two things I've observed:
Here's some extra Linux/FTDI related stuff. Abort now if you're driving and
prone to sleepiness.
Someone (B 9?) mentioned that the FTDI had on chip soft flow control, and I
hadn't heard of such a
thing either, so I went spelunking through the source code and datasheets.
Sure enough, the FT2232R
and variants (which is something I use for JTAG/SPI work, as well as serial)
datasheets mention
"Fully assisted hardware or X-On/X-Off software handshaking", and that's *all*
they mention of it.
The FT232R datasheet however doesn't mention it, so I wonder if it was
introduced with their MPSSE
tech (Multi Purpose Synchronous Serial Engine), but I believe that's only used
for the non-UART
transfers (and couldn't find any mention of it here [1]). However [2] mentions
that the FT232R
*is* capable of soft flow control on the chip side, so ¯\_(ツ)_/¯. Damn sparse
datasheets.
The Linux FTDI driver (ftdi_sio) does have support for this on-chip software
handshaking if available
though[3], and is enabled by default if using software flow control. I've got
a todo item to see how
to enable the dev_dbg() messages to ensure that it's being enabled, or at least
poke the chip to read
its current settings via USB.
Without the hardware assist, software flow control will be subject to USB poll
latency, as the USB
host controller has to poll the serial chip for waiting characters (which is
then processed by the
appropriate serial driver). The poll latency is requested by the chip:
$ lsusb | grep Future
Bus 003 Device 044: ID 0403:6010 Future Technology Devices International, Ltd
FT2232C/D/H Dual UART/FIFO IC
$ lsusb -vd 0403:6010 | egrep 'id[VP]|bInterval'
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6010 FT2232C/D/H Dual UART/FIFO IC
bInterval 0
bInterval 0
bInterval 0
bInterval 0
And as bInterval is zero, the driver uses its default:
$ cat
/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/ttyUSB0/latency_timer
16
which I believe is in mS, so this is the potential maximum (not including
processing overhead)
that the X-OFF character will take to traverse just the USB subsystem. This is
adjustable to
the end user, and might be something to try if you, or anyone you love, is
afflicted by any of
these issues that we've discussed in this email. Apparently, this matters to
gamers - there's
a lot of chat around USB gaming mice and USB latency on the interwebz, but it's
applicable to
a broader range of devices than just mice. Given an extremely loose
back-of-envelope figure
of 1mS per character at 9600 bps, that's roughly up to 16 characters (worst
case) before the
OS knows it has to stop sending, without hardware assist.
That's not taking into account the on chip Rx and Tx buffer sizes that vary
between chips; the
older FT232R has an Rx (to serial device) of 128 bytes, the newer MPSSE capable
ones are up
around 4K.
I've also on my todo list to testbench this setup (prior to knowing about the
software flow
control shenanigans), as I'm interested in other USB serial chips as well, but
that particular
item is well down on priority.
WAKE UP!
Footnotes:
1.
<https://www.ftdichip.com/Documents/AppNotes/AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf>
2.
<https://www.ftdichip.com/Support/Knowledgebase/index.html?an232b_04flowctl.htm>
3.
<https://github.com/torvalds/linux/blob/master/drivers/usb/serial/ftdi_sio.c#L2789>
Cheers,
--dt
