Only one VID/PID for all Apollo platforms

[mossmann]

Currently we have only one VID/PID for all Apollo platforms. We use bcdDevice to indicate Cynthion hardware revision, but we also overload bcdDevice with board identification. There are some problems with this:

• non-Cynthion Apollo devices can’t use bcdDevice for hardware revision, so the scheme doesn’t really support more than one shipping Apollo product.
• Saturn-V does not use bcdDevice in the same way, so a flashing utility can’t tell what board a Saturn-V device is. There is little room to do anything different in Saturn-V, and any change would not be pushed to Cynthions that have already been flashed at the factory.

Proposal:

• Reserve the existing VID/PID 1d50:615c for Cynthion only.
• Start using 1209:0010 (one of the pid.codes test PIDs) for non-Cynthion Apollo devices. Continue to use the other pid.codes test PIDs for LUNA but add a note to the LUNA documentation saying that 1209:0010 is recommended to be used only for Apollo.
• Other Apollo platforms may optionally use their own VID/PID. This would be recommended for any shipping product.
• Create a new vendor request for board identification in Apollo. Make this consistent for all Apollo devices, even those that have their own VID/PID. This allows, for example, an experimental Cynthion using 1209:0010.
• Deprecate the use of bcdDevice for board identification. Host code will look for this type of board identification only if the USB API is older. We may remove that feature from host code in the future.

The use of 1209:0010 requires that we additionally qualify Apollo devices, for example by checking for the word "Apollo" in the product string or a vendor request, but we already want to do that anyway. See #61 and #47.

[mossmann]

@cyber-murmel I'm interested in your thoughts on this proposal.

[cyber-murmel]

I think this proposal is sound!
Saturn-V shouldn't be as big of an issue, since the RP2040 (and QtPy iirc) for example use UF2 anyway.

Create a new vendor request for board identification in Apollo.

Would this also bump the USB API number?

Checking the product string might cause outdated software in the future to fail detect the debugger, if the name changes, but that's a very fringe case.

Seems all fine by me!

[mossmann]

Yes, the new vendor request would bump the USB API version.