Date: Fri, 8 Oct 2021 09:40:58 +0200 From: Milan Obuch <freebsd-hackers@dino.sk> To: freebsd-hackers@freebsd.org Subject: Re: Persistent USB serial? Message-ID: <20211008094058.0c0bd17f@zeta.dino.sk> In-Reply-To: <6510e27f-29f0-37a8-37b5-3b5b4e297b65@rtems.org> References: <20211008080016.7830e3d5@zeta.dino.sk> <6510e27f-29f0-37a8-37b5-3b5b4e297b65@rtems.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20211008094058.0c0bd17f>