I'm getting much closer. I figured out how to make the strings, but updating the USB descriptor (as opposed to creating a whole new one) is eluding me so far. But I only want to update strings for the default CDC descriptor. There doesn't seem to be a method to only update the string dictionary (nor even examine the current dictionary). But it's after midnight and maybe things will be clearer in the morning.

Here's my start so far:

import machine
import sys
sys.path.extend(['/lib'])

# from shared/tinyusb/tusb_config.h
#    USBD_STR_MANUF (0x01)
#    USBD_STR_PRODUCT (0x02)
#    USBD_STR_SERIAL (0x03)
# from shared/tinyusb/mp_usbd_descriptor.c
#   .iManufacturer = USBD_STR_MANUF,
#   .iProduct = USBD_STR_PRODUCT,
#   .iSerialNumber = USBD_STR_SERIAL,

# string indices in the default descriptor
i_str_manuf = 0x01
i_str_product = 0x02
i_str_serial = 0x03

# module ID (will be read from DIP switches)
module_id = 0x03

# build some strings
str_module_id = f'{module_id:02x}'
str_unique_id = f'{int.from_bytes(machine.unique_id()):x}'
str_serial = f'{str_unique_id}_{str_module_id}'
str_product = f'proto_meter_{module_id:02x}'
str_manuf = 'TheStumbler'

# make the strings dictionary
mystrings = {}
mystrings[0] = None # need this for language
mystrings[i_str_manuf] = str_manuf
mystrings[i_str_product] = str_product
mystrings[i_str_serial] = str_serial

# for s in mystrings.items(): print(s)

desc_dev = machine.USBDevice.BUILTIN_CDC.desc_dev
desc_cfg = machine.USBDevice.BUILTIN_CDC.desc_cfg

# this isn't working, manually or in boot.py
# machine.USBDevice.active(False)
# machine.USBDevice.config(
#  desc_dev, desc_cfg, \
#  desc_strs=mystrings \
# )
# machine.USBDevice.active(True)

When it fails, I get this message:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument has wrong type

BTW, even though I h ent succeeded yet, I completely prefer this new dynamic method over rebuilding the firmware for each different module ID in my system. I did that last night for just four meters, so I could have some working firmware to begin integration testing. That was a pain in the neck!

I also need to finish watching the presentation you linked. I got about 15 minutes in and said to myself, "Ah ha. I got this" and started trying to implement it. Maybe I missed some key points later on in the video.

@mattytrentini so, I stumbled around over the weekend and arriving at a workable but not quite correct solution. The presentation you linked above was indeed helpful. But last night, I finally realized you were pointing me in the direction of the higher-level usb drivers solution found in the micropython-lib, so I had a look and tried that approach.

I can appreciate how this driver makes the task of creating a new USB device much easier. But in the case of just changing the descriptors of the main CDC serial port REPL, I'm not sure it has any advantages.

The CDC example works as promised in the notes. I even found the arguments one passes for customizing the strings. When you run this example, you end up with two identical CDC serial ports connected to the REPL. Good.

Now let's say I want the UART REPL for testing, as advised. I could not figure out how to have three REPLs running. No matter what I tried, there seemed to be a hard-baked limit of two REPLs. The index parameter to os.dupterm() would only accept 0, weird since if there are two REPL "slots", I'd think the index could be 0 and 1.

But on the USB front, I don't want two CDC serial ports. My goal is simply to change the descriptor strings. I could not figure out how to disable the builtin CDC driver once I created the second one. If I set machine.USBDevice.active(False), that killed both CDC ports. Creating the new CDC with builtin_driver = False didn't do what I expected, there were still two CDC ports.

Strangely, the two ports have identical descriptor strings. I would expect the original port to remain as "Board in FS mode", and the new port to have the custom strings. Note -- the two serial port name on my PC are distinguishable because underscores are appended, like _1 and _3.

So, I could create custom descriptor strings using this method. But no matter what I did, it always resulted in two ports with identical descriptor strings. Furthermore, using the usb drivers did not solve the mpremote or rshell soft reset problem. In other words, I still had to include the resume option in all my mpremote commands.

So while this library makes usb device drivers easier, in the very simple case of just changing basic CDC device descriptors, I think it causes more confusion than the direct USBDevice() approach, because it creates two ports instead of one, and no way to also have a UART REPL for debugging.

Yeah, for some reason their BSD style doesn't implement that technique. But even if it did, I'd still have to manually sort out the unique ID for each of 20-some modules and map them in an initialization script. I already do this, because even without that /dev folder, I can see the serial number using various utilities like lsusb.

By making my own custom string descriptors, I can completely automate the init script that scans the usb serial ports and initializes some variables for ease of use.

This init script assigns a shell variable to all 20-some modules in an assembly, and then I have a bunch of aliases to the mpremote and rshell tools. End result, I can simply type mpr0 reset or rs18, etc., to work with any desired meter.

Thanks for taking the time to look at my problem @projectgus For the moment it's comforting to know that I've stumbled on the most correct solution.

I would like to suggest that consideration be given to the use case of custom descriptor strings only. It seems that this is something lots of people struggle with when connecting to USB serial ports of all sorts of embedded devices, not just MicroPython. My case with a system of 20-some modules is an extreme example, but being able to clearly identify one's project by customizing USB descriptors is a common enough request from what I've seen, and provides real benefits to the users.

I am not well versed in the bowels of the USB specification and its implementation here, but based on my limited experimentation the last few days, it sure feels like implementing this feature wouldn't be a difficult thing.

Whether or not dynamic descriptor strings can be implemented in an easier way, I think there is also some benefit to making it easier to change the default strings upon building the firmware, just by adding entries to the mpconfigboard file. Currently it's a dance (though well explained by user Hippy mentioned way at the top of this discussion) requiring tweaking the main CMake file and copy / editing a couple of tinyusb modules.

Oh -- one more observation. When I used the direct USBDevice() dynamic method, or "old style" building custom MicroPython firmware per module serial number, the resulting serial ports on my system were,let's say, "normal".

/dev/cu.usbmodem1101

If I make the port, well, pair of ports, using the mip-installed usb library, the usb serial port shows up as

/dev/cu.usbmodemmodule_141
/dev/cu.usbmodemmodule_143

I note that the text "module_14" is a place holder I put in the descriptor string for serial number. But on the other custom ports above, the serial number, custom or not, doesn't get appended to the PC name for the /dev serial port. I don't really care one way or another, I just thought it was interesting that they behaved differently

Looks like USBDevice has been removed from MicroPython. That's sad.

I had a brain fart. I had two board definition directories, WAVESHARE_..... and WAAVESHARE_....._CUSTOM_USB

Not having rebuilt it for several months, I just assumed the CUSTOM_USB was the one that dealt with my custom usb descriptors. Wrong. That build was one where I had been testing hard-coding the descriptors in the tusb* files, not dynamically.

Once I got that sorted, it all works again at 1.26. That's the problem with working on code at 1 AM 8-)