Re: Persistent USB serial?

From: Milan Obuch <freebsd-hackers_at_dino.sk>
Date: Fri, 08 Oct 2021 07:40:58 UTC
On Fri, 8 Oct 2021 18:26:32 +1100
Chris Johns <chrisj@rtems.org> wrote:

> On 8/10/21 5:00 pm, Milan Obuch wrote:
> > 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?
> >  
> 
> It is something I have just had to live with it and with RTEMS we
> suggest using `ser2net` [1] to handle the connection. I see
> consistent enumerations once connected if the USB ports are not
> moved. You could then wrap the telnet connection in something that
> hammers the connection as fast as you need to pick up characters. It
> is not prefect but it is ok and simple to implement.
> 
> The actual issue is usually a bug in the USB UART circuit on the
> target.
> 
> Chris
> 
> [1] I recently raised a bug against ser2net on FreeBSD ..
>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258382
> 

I have no idea what ser2net does, I'll check what it is and how I can
possibly use it. Thanks for pointer.

Regards,
Milan