Description

Currently, all examples use generic prototype VID/PID pairs that should really not make it into widespread use; building with them shows a big red warning to please get own IDs before handing out anything.

With USB support becoming more usable, boards like the nrf52840-dongle (#12189) whose default console is a USB serial device become available to RIOT. Those flashing USB warnings to developers who didn't even touch a line of USB code or intentionally use USB (other than for make term) is confusing, and those situations may qualify for some of the ID pair pools for Free Software.

The hard parts here are to

• define when such IDs could be used, and to
• make the build system detect whether the IDs are usable.

Applicability

The IMO clear-cut corner cases for applicability are "user is building a demo like gcoap on a board that happens to have default USB UART and networking" (that should get a VID/PID that says 'RIOT built-in serial adapter'), and "user is building an application with own USB peripherals" (clearly, the prototype pair should be used here and flash the red). Examples should probably show the latter behavior as well as to indicate what a developer should do in own code.

It would be easiest to have one code that just says "RIOT built-in peripherals", and has serial and/or Ethernet configured as applicable or configured. There may be room for a third endpoint that allows for reset into the bootloader by whichever means. If that flexibility within an ID pair is asking too much, there'd be 3 (or 7, with bootloader) IDs for whichever combination of features is active.

Detection

Detection of whether a build is eligible for the "RIOT built-in foo" IDs is another open point; relying on users to do the right thing might not cut it here.

One suggestion for detection would be to create a usbus_user (pseudo?)module(?). The core USB module headers would check for whether either that is active or a USBUS_INTERNAL define is present (outside of their include guards), and otherwise #error out with a message asking to activate usbus_user. The internal users of USB that are sanctioned to use the VID/PID pair set that define for while they're including the USB headers. All this is easy to circumvent intentionally (and there's no ambition to avoid that), but both accidental use of the RIOT IDs and "I'm lazy and will do the quickest thing that'll make things work" cases should be curbed by that.

(The build system would then set the default VID/PIDs to the current prototype ones if usbus_user is active, and to the internal ones otherwise. Either could be overridden. The red warning would show iff the prototype ones are in use, independent of the modules).

Useful links

• https://github.com/openmoko/openmoko-usb-oui is one registry that could provide ID pairs
• http://pid.codes/ the registry from which the current prototype codes are taken

Context

This was brought up by @bergzand in an IRC discussion of VID/PID pairs.

(edit: added pid.codes link)