With the whole USB peripheral PR set slowly starting to take it's final
shape, I'd like to get a RIOT-os specific vendor/product code. As Dylan
suggested[1] we can try to get a free vid/pid combination at the
pid.codes[2]. This with the assumption that a full vendor space for
$5.000 is both too much and too expensive for RIOT-os. I'm strongly
against making up/stealing a combination, even if it is for a short
while as this not how USB VID/PID's should work(tm).
My question is if anydbody has a better solution for the vid/pid
problem? If not wether anybody minds if I go ahead and fill out the
necessary info to request a PID from the pid.codes collection.
Cheers,
Koen
P.S. For those interested, the progress so far:
PR'd:
- Generic USB peripheral interface (#9830)
- USB peripheral driver for the atsamr devices (#10915)
- Preliminary USB peripheral stack (#10916)
First of all, great work. Now to the VID, PID matter: I don't think we should get any VID. A single PID may be ok.
Product numbers are for products. RIOT is not a product. Rather, it is used to build product (or at least that's wath we hope for). Even if we obtained an ID it would be irrelevant for everyone except developers: if you develop a device, you should get your OWN ids, you cannot reuse your OS vendor's.
For example, I remember using TI's USB library for the MSP430 some years ago (horribly ugly, btw) and it does NOT come with any ID.
>
> My question is if anydbody has a better solution for the vid/pid
> problem? If not wether anybody minds if I go ahead and fill out the
> necessary info to request a PID from the pid.codes collection.
>
Quoting from PID.CODES:
"If your project involves both hardware and software, both need to be licensed under recognised OSS and OSHW licenses. If your project involves only one or the other, we may ask for further justification as to why you need a PID associated with your software project / development board instead of allowing end-users to request their own."
I think that having a single PID for "Generic RIOT-powered device" (or something of the sort) is valuable, especially for development, and for the CI, and we only really need one, not a whole block. That, and the fact that we have a more or less large project should be enough justification to get a PID from pid.codes. Of course, the docs should clearly state that the PID is for use in RIOT development and should be changed for actual devices.
A whole VID would not be useful: what would you do with so many PIDs?
Looking forward to the first riot-powered USB peripherals.
I don’t think that RIOT-OS needs a USB VID/PID code. It should be left the Board developers to decide if they get one from pid.codes.
In our case we developed a board almost a year ago for Contiki (And ended up running RIOT-OS on it), we decided to reserve a VID/PID from pid.codes to identify our product.
On Contiki we started to implement the support for USB but didn’t finished it. Later when we migrated to RIOT-OS we used our VID/PID to identify the Arduino-based USB bootloader.
First of all, great work. Now to the VID, PID matter: I don't think we
should get any VID. A single PID may be ok.
Product numbers are for products. RIOT is not a product. Rather, it is
used to build product (or at least that's wath we hope for). Even if
we obtained an ID it would be irrelevant for everyone except
developers: if you develop a device, you should get your OWN ids, you
cannot reuse your OS vendor's.
</snip>
I think that having a single PID for "Generic RIOT-powered device" (or
something of the sort) is valuable, especially for development, and
for the CI, and we only really need one, not a whole block. That, and
the fact that we have a more or less large project should be enough
justification to get a PID from pid.codes. Of course, the docs should
clearly state that the PID is for use in RIOT development and should
be changed for actual devices.
A whole VID would not be useful: what would you do with so many PIDs?
I agree with you here. First of all, I also don't see any use for a VID
for RIOT-os, but hey maybe somebody else has a use case for a full VID.
For me, a hypothetical RIOT-os PID would be used only for development
and testing. CI jobs, people wanting to test USB or develop USB devices.
As soon as the USB device leaves the building it must have a different
VID/PID owned by the developer/company. Having a PID for this is mostly
for ease of development, so we don't have to use a random VID/PID with
all the consequences. A lot of USB functionality doesn't require a
specific VID/PID, but is purely recognized based on the descriptor
information.
A second PID could be required if we have our own DFU enabled RIOT
bootloader. For this I wouldn't mind if it was used for actual products
as long as the RIOT bootloader is unmodified. This as in if it claims to
be the RIOT-os DFU bootloader, it should behave like the RIOT-os
bootloader and be able to flash RIOT-os on the mcu with the RIOT-os DFU
tooling.
First of all, great work. Now to the VID, PID matter: I don’t think we
should get any VID. A single PID may be ok.
Product numbers are for products. RIOT is not a product. Rather, it is
used to build product (or at least that’s wath we hope for). Even if
we obtained an ID it would be irrelevant for everyone except
developers: if you develop a device, you should get your OWN ids, you
cannot reuse your OS vendor’s.
I think that having a single PID for “Generic RIOT-powered device” (or
something of the sort) is valuable, especially for development, and
for the CI, and we only really need one, not a whole block. That, and
the fact that we have a more or less large project should be enough
justification to get a PID from pid.codes. Of course, the docs should
clearly state that the PID is for use in RIOT development and should
be changed for actual devices.
A whole VID would not be useful: what would you do with so many PIDs?
I agree with you here. First of all, I also don’t see any use for a VID
for RIOT-os, but hey maybe somebody else has a use case for a full VID.
For me, a hypothetical RIOT-os PID would be used only for development
and testing. CI jobs, people wanting to test USB or develop USB devices.
As soon as the USB device leaves the building it must have a different
VID/PID owned by the developer/company. Having a PID for this is mostly
for ease of development, so we don’t have to use a random VID/PID with
all the consequences. A lot of USB functionality doesn’t require a
specific VID/PID, but is purely recognized based on the descriptor
information.
A second PID could be required if we have our own DFU enabled RIOT
bootloader. For this I wouldn’t mind if it was used for actual products
as long as the RIOT bootloader is unmodified. This as in if it claims to
be the RIOT-os DFU bootloader, it should behave like the RIOT-os
bootloader and be able to flash RIOT-os on the mcu with the RIOT-os DFU
tooling.
I think Koen perfectly sums up the situation and I agree with him.
VID is pointless for RIOT, but having two PIDs (one for development, one for DFU) would be great. Of course, it should be clearly state that the devel PID must not be used outside of its original scope.
BTW, If people want to be involve. We must port the lowlevel driver and test the stack against several MCUs (EFM32, STM32, Kinetis,etc…). Any help is welcome !