Re: [riot-devel] USB PID number

[Hauke Petersen]

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 > 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.
>
> 
>
> 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 
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

Re: [riot-devel] USB PID number

[Dylan Laduranty]

Hi all,

Le mar. 26 févr. 2019 à 09:51, Koen Zandberg  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.
> >
> > 
> >
> > 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
> 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

Re: [riot-devel] USB PID number

[Koen Zandberg]

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.
>
> 
>
> 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.

Cheers,
Koen




signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] USB PID number

[Mario Gómez]

Hi!

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.

http://pid.codes/1209/053A/

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.

https://github.com/hackerspacesv/ArduinoCore-samd/

Our plan is to keep using those VID/PID already reserved on pid.codes when
the USB support is ready for RIOT-OS.

Regards,
Mario.


On Mon, Feb 25, 2019 at 8:17 AM 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.
>
> 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.
>
> Regards,
>
> Juan.
>
> ___
> 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

Re: [riot-devel] USB PID number

[Juan Ignacio Carrano]

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.


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.

Regards,

Juan.

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] USB PID number

[Christian Pfaab]

Moin,

On 2/25/19 2:58 PM, Koen wrote:
> 
> 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.

There is the old pool from Openmoko that gets managed by someone for
community projects (formerly Harald Welte). I do not know the current state.



http://laforge.gnumonks.org/blog/20180609-openmoko-usb_id/

Cheers,
Christian
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] USB PID number

[Koen]

Hi all,

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)

In a branch somewhere:

- Simple USB auto init code
- USB CDC ACM with STDIO support
(https://github.com/bergzand/RIOT/tree/pr/usb/cdcacm/examples/usbus_minimal)

Not yet in a branch/very WIP but somewhat functional:

- USB peripheral driver for the nrf52840
- USB CDC ECM with netdev support


[1]: https://github.com/RIOT-OS/RIOT/pull/9830#issuecomment-428096556
[2]: http://pid.codes/howto/




signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel