Hi,
fully agree. +1 to go with the two PID solution.
And I'd say we can always revisit the VID situation if someone comes up
with a good justification why we would need one...
Cheers,
Hauk
On 2/26/19 10:21 AM, Dylan Laduranty wrote:
Hi all,
Le mar. 26 févr. 2019 à 09:51, Koen Zandberg <k...@bergzand.net
<mailto:k...@bergzand.net>> a écrit :
Hi Juan,
On 2/25/19 3:19 PM, Juan Ignacio Carrano wrote:
> Hi all,
>
> 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.
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 !
Cheers,
Cheers,
Koen
_______________________________________________
devel mailing list
devel@riot-os.org <mailto:devel@riot-os.org>
https://lists.riot-os.org/mailman/listinfo/devel
--
Dylan Laduranty
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
