Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Oct 2024 22:21:16 +0200
From:      Tomek CEDRO <tomek@cedro.info>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        hackers@freebsd.org
Subject:   Re: pyserial.tools.list_port improvement for FreeBSD
Message-ID:  <CAFYkXjmzAsxLiRZNM1=A37hXKHrDRud6u0R-odxosmCg0oPMcg@mail.gmail.com>
In-Reply-To: <203ADA8C-A4ED-4849-B89D-6D18664D67D0@webweaving.org>
References:  <202410210954.49L9s9sD076618@critter.freebsd.dk> <203ADA8C-A4ED-4849-B89D-6D18664D67D0@webweaving.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 21, 2024 at 9:04=E2=80=AFPM Dirk-Willem van Gulik
<dirkx@webweaving.org> wrote:
> On 21 Oct 2024, at 11:54, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> > I have had reason to muck about with pyserial. One result is much bette=
r pyserial.tools.list_port implementation for FreeBSD.
> > I would appreciate it, if somebody else could give it a spin, before I =
upstream:
> >       https://github.com/bsdphk/pyserial
>
> Works for me (provided /usr/sbin is in the path); and nicely picks up a u=
gen0.2 that the ESP32 tooling would always need an explicit path for prior =
despite it having a tty name.

Very cool PHK! But I have some more ideas below :-) :-P

% uname -a
FreeBSD octagon 13.3-RELEASE-p7 FreeBSD 13.3-RELEASE-p7 GENERIC amd64

On current 3.5 system py311 package:

>>> list_ports.main()
/dev/cuaU0
/dev/cuaU1
/dev/cuaU2
/dev/cuaU3
/dev/cuaU4
/dev/cuau0
6 ports found

On Your repo from 3.9 venv:

(venv3.9embedded) python3 list_ports_freebsd.py
/dev/cuaU0 - ugen0.7: usb
/dev/cuaU1 - ugen0.8: usb
/dev/cuaU2 - ugen0.9: usb
/dev/cuaU3 - ugen0.10: usb
/dev/cuaU4 - ugen0.11: usb
/dev/cuau0 - cuau0: uart

Now lets take a look at two example descriptors:

% usbconfig -d ugen0.7 dump_device_desc
ugen0.7: <Silicon Labs CP2102 USB to UART Bridge Controller> at
usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA)

  bLength =3D 0x0012
  bDescriptorType =3D 0x0001
  bcdUSB =3D 0x0110
  bDeviceClass =3D 0x0000  <Probed by interface class>
  bDeviceSubClass =3D 0x0000
  bDeviceProtocol =3D 0x0000
  bMaxPacketSize0 =3D 0x0040
  idVendor =3D 0x10c4
  idProduct =3D 0xea60
  bcdDevice =3D 0x0100
  iManufacturer =3D 0x0001  <Silicon Labs>
  iProduct =3D 0x0002  <CP2102 USB to UART Bridge Controller>
  iSerialNumber =3D 0x0003  <0001>
  bNumConfigurations =3D 0x0001

% usbconfig -d ugen0.8 dump_device_desc
ugen0.8: <Espressif USB JTAG/serial debug unit> at usbus0, cfg=3D0
md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (500mA)

  bLength =3D 0x0012
  bDescriptorType =3D 0x0001
  bcdUSB =3D 0x0200
  bDeviceClass =3D 0x00ef  <Miscellaneous device>
  bDeviceSubClass =3D 0x0002
  bDeviceProtocol =3D 0x0001
  bMaxPacketSize0 =3D 0x0040
  idVendor =3D 0x303a
  idProduct =3D 0x1001
  bcdDevice =3D 0x0101
  iManufacturer =3D 0x0001  <Espressif>
  iProduct =3D 0x0002  <USB JTAG/serial debug unit>
  iSerialNumber =3D 0x0003  <60:XX:F9:CC:XX:XX>
  bNumConfigurations =3D 0x0001

% usbconfig -d ugen0.9 dump_device_desc
ugen0.9: <STMicroelectronics STM32 STLink> at usbus0, cfg=3D0 md=3DHOST
spd=3DFULL (12Mbps) pwr=3DON (300mA)

  bLength =3D 0x0012
  bDescriptorType =3D 0x0001
  bcdUSB =3D 0x0200
  bDeviceClass =3D 0x00ef  <Miscellaneous device>
  bDeviceSubClass =3D 0x0002
  bDeviceProtocol =3D 0x0001
  bMaxPacketSize0 =3D 0x0040
  idVendor =3D 0x0483
  idProduct =3D 0x374b
  bcdDevice =3D 0x0100
  iManufacturer =3D 0x0001  <STMicroelectronics>
  iProduct =3D 0x0002  <STM32 STLink>
  iSerialNumber =3D 0x0003  <0667XXXX49558575671XXXXX>
  bNumConfigurations =3D 0x0001

It would be amazingly useful to also have SerialNumber, VID/PID,
Manufacturer + Product printed out in a single line delimeted for easy
parse (maybe a table?), something like:

/dev/cuaU0: ugen0.9, usb, tty?, 0667XXXX49558575671XXXXX, 0483:374b,
STMicroelectronics STM32 STLink.

We are building distributed build and testing farm for NuttX RTOS
where different boards are attached over multiport USB HUB(s). Build
will be repeated with different tools and commits in order to verify a
firmware image build, then firmware will be flashed to a physical
board in order to perform on-board runtime tests. Logs will be
gathered and sent back to a server for analysis (PASS / FAIL + logs).

This comes as complementary action to build only verification on
GitHub and recent cuts in CI availability (we exceed CI quota by a lot
with just standard PR verification). Plus we will have real world
hardware runtime verification :-)

Also we plan to use https://github.com/mvp/uhubctl for single USB HUB
port control. I did not play with that guy yet, is supposed to work on
FreeBSD, will have to add support for my i-Tec U3CHARGEHUB16.

ugen device is nice to know, but it will change depending on what will
be attached to what port, maybe even change in time as HUB ports are
cycled, SN is better for target board/interface identification in
scripting :-)

Thank you :-)
Tomek

--=20
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFYkXjmzAsxLiRZNM1=A37hXKHrDRud6u0R-odxosmCg0oPMcg>