Re: Persistent USB serial?

From: Ian Lepore <ian_at_freebsd.org>
Date: Fri, 08 Oct 2021 14:20:23 UTC
On Fri, 2021-10-08 at 08:00 +0200, Milan Obuch wrote:
> Hi,
> 
> I'd like to solicit opinions/hints for following scenario, which is
> quite common currently.
> 
> There are some development and evaluation boards designed with USB
> port
> as power source and serial console at the same time (sometimes even
> more ports or JTAG as well). When board has power on switch, usually
> no
> activity is present on USB wire without board being powered - there
> is
> some USB-to-UART circuitry powered from board power source. So serial
> port device /dev/cuaUn et al. get created only after power on of the
> board.
> 
> Problem: port number can be different depending on USB port
> enumeration
> or connection order. Another one: it is easy to miss first characters
> sent from the board if you are not able to write required command
> like
> 'cu -l /dev/cuaU9 -s 115200' quickly.
> 
> Maybe it is possible to write some devd config file snippet which
> ensures consistent device naming without need of maintaining correct
> (everytime the same) order of cable connecting, but even that, this
> does not solve second problem, starting up some terminal or terminal
> like program in time.
> 
> Has anybody some experience in this area who can share it? Some hints
> what to test? Do we have some pseudo serial device, which can be used
> as device argument for cu command, which can just grab the real USB
> serial when it appears on connecting the board under test?
> 
> Regards,
> Milan
> 

If the device on the other side of the usb serial adapter is already
sending data when you attach the adapter to the freebsd system, you
will lose data and/or get corrupted data.  There is nothing you can do
about it.

Opening a usb-serial device involves a 100ms sleep (in usb_serial.c). 
For every config command sent to the device (change speed, change line
parameters such as asserting DTR), there is another 100ms sleep. 
Because of the freebsd line config mechanisms (.init and .lock files)
there is a surprising amount of config traffic that happens when you
open a tty device -- it configures everything based on .init and .lock
files, then the app opening the device will reconfigure everything
again.  For usb serial you can see all that happening with usbdump(8).

A 115200 connection is roughly 11 kbytes data per second, and it takes
up to a second to open a usb-serial device.  The ftdi on-chip fifo is
only 384 bytes on the older-generation chips (the common ones), and
even on the modern H-series chips the fifo is only 2K or 4K depending
on chip model.

So the fifo can't hold enough data to capture everything arriving
during during the open-and-config sequence.  Even if it could, some of
the data would have arrived at the wrong line speed and will just be
garbage.

-- Ian