Re: Persistent USB serial?
- Reply: Milan Obuch : "Re: Persistent USB serial?"
- In reply to: Milan Obuch : "Persistent USB serial?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 08 Oct 2021 07:26:32 UTC
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