[riot-notifications] [RIOT-OS/RIOT] Have usable VID/PIDs for standard situations and prototype ones for examples (#12273)
notifications at github.com
Mon Sep 30 16:55:12 CEST 2019
> This is also how I've always understood VID/PID pairs, as one product with a specific and fixed feature set.
How set-in-stone do they need to be? Can the USB stack give long-term guarantees that applications that pull in ECM and ACM will always have the ACM at If=0 and the ECM at If=2? Are we sufficiently far along that we feel comfortable picking a virtual reset-pin feature that'd go into that feature set?
(If those are difficult questions to answer, I suggest we keep using the Test PIDs for some more time, let nothing block on this issue, and maybe start experimenting with internal conventions on the use of the Test PIDs before we apply for real ones; a la "Test1 is for bootloader, Test2 is for what we'd later call Generic Application with ACM+ECM+Reset etc").
> the bootloader really requires a separate PID as it makes DFU flashing a lot more convenient
Yes, sketched as such.
> prefer to also have a VID/PID for examples
The examples have a tendency of getting copy-pasted around as skeletons, so if they use a non-screaming-red pair, that'd easily get out of hand -- and the build system couldn't really know when the example is pristine, when someone's just tweaking it a little, and when it's a separate application. That's what I'm suggesting the RIOT test PID for, it'd scream less loudly (yellow?) and say that this is for RIOT examples and you should pick a real one at some point in time.
(Examples that are not USB examples would use the "Only using RIOT system USB-emulated peripherals" anyway, which never scream but conflict with the `usbus_user` pseudomodule, or some mechanism to that effect).
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications