USB Device VID and PID best approach.

[Twistx77]

Hi,

I'm developing a project where USB connection is needed the problem is with the VID and PID since I don't have one I'm trying to go around it somehow at least for now.

I want to know which would be the best way to avoid having to get a VID. I've googled a lot but I haven't found a good solution yet.

I would like my device to have a USB bootloader and at least 4500 Bytes/s of real bandwidth. I could use CDC but not as a Virtual COM Port. I want to be able to detect it without the users intervention.

I thought of using something like FTDI's Chips using the D2XX drivers but in that case I would need to write my own bootloader and loader software if I want to use it to load a new firmware to my MCU. I couldn't use an already existing VCP loader application. I also thought of using a new FTDI's chip which is HID to UART which means I would no need drivers but yet again I would have problems with the bootloader.

So in case I went that road, could I use FTDI's VID and PIDs? If so, what limitations would I have? Could I at least change my devices Description Name?

I could use a STM32, Microchip, NXP or any other MCU that could have a USB HID Bootloader and also a CDC communication for normal transfer. The problem with this is I don't have a VID. In this case, is there any company that could provide me with a driver to communicate to the MCU without emulating a COM port? Could I use their VID for my product? If so, could I just change the Description Name?

Any suggestion? I'm sure this have already happen to someone else before.

Thanks in advance!

[elecman14]

If you are just testing and not selling a product you should be fine picking one that will not conflict with devices on your computer. If your project is OSS and OSHW you should check out http://pid.codes/howto/ for a free vid/pid. If not one can be bought rather cheaply from sites like http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&category_id=20&option=com_phpshop&Itemid=1

[Deni]

VID & PID have nothing to do with the way PC communicates with your device. If you need standard protocol, that requires no special drivers, you might take a look here:

http://www.usb.org/developers/docs/devclass_docs/DFU_1.1.pdf or use HID profile with your custom commands.

And regarding VID - the only (legal) way is to register your company with USB.org. On the other hand, some chip vendors allow you to use their VID but your own PID as
long as you use their chips in the product.

[pix3l]

The FTDI way works great, you can program the EEPROM of your FTDI chip to let your device be enumerated in device manager with a certain name. Can be used with for example the jd2xx library for PC side.

[Twistx77]

If you are just testing and not selling a product you should be fine picking one that will not conflict with devices on your computer. If your project is OSS and OSHW you should check out http://pid.codes/howto/ for a free vid/pid. If not one can be bought rather cheaply from sites like http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&category_id=20&option=com_phpshop&Itemid=1

Thanks, I already know about the OSHW ones but I didn't know they sold the PID by itself. Is it legal? I thought it wasn't. What limitations does it have to use one of those bought PID? 15€ is great!

[Twistx77]

VID & PID have nothing to do with the way PC communicates with your device. If you need standard protocol, that requires no special drivers, you might take a look here:

http://www.usb.org/developers/docs/devclass_docs/DFU_1.1.pdf or use HID profile with your custom commands.

And regarding VID - the only (legal) way is to register your company with USB.org. On the other hand, some chip vendors allow you to use their VID but your own PID as
long as you use their chips in the product.

I know they don't have anything to do with protocol. I just one a legal way to comunicate to my device without having to pay +2k $.

What about this: http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&category_id=20&option=com_phpshop&Itemid=1 ?

[Twistx77]

The FTDI way works great, you can program the EEPROM of your FTDI chip to let your device be enumerated in device manager with a certain name. Can be used with for example the jd2xx library for PC side.

Thanks! Do you know if it is possible to make the FTDI chip enumerate as a VCP when a pin is high and to use D2XX drivers when the pin is low or something like that?

I need that because I would like to enumerate as VCP when I want to load the bootloader but as D2XX when is running normally.

[Twistx77]

Also, could I just use HID with the VID and PID provided by Microchip, ST, or any other manufacturer? I would only like to change the device name.

[janoc]

What about this: http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&category_id=20&option=com_phpshop&Itemid=1 ?

That VID is revoked. You can probably pick one of the other revoked VIDs without paying anyone and will get the same result. USB IF can't safely re-assign revoked VIDs because it would break existing hw. Paying that company will only get you some sort of guarantee that you PID won't conflict with someone else's using the same VID. Chances of that are fairly low if you pick an obscure VID.

I remember seeing the list of revoked VIDs somewhere, probably a bit of googling would find it.

It is sad that they still didn't fix (and have no interest in fixing) this retarded issue with 16bit only (and thus artificially scarce) vendor IDs and instead rack $5k/year fees over them.

[Twistx77]

That VID is revoked. You can probably pick one of the other revoked VIDs without paying anyone and will get the same result. USB IF can't safely re-assign revoked VIDs because it would break existing hw. Paying that company will only get you some sort of guarantee that you PID won't conflict with someone else's using the same VID. Chances of that are fairly low if you pick an obscure VID.

I remember seeing the list of revoked VIDs somewhere, probably a bit of googling would find it.

It is sad that they still didn't fix (and have no interest in fixing) this retarded issue with 16bit only (and thus artificially scarce) vendor IDs and instead rack $5k/year fees over them.

Sure this is just really stupid just another way to make someone rich by doing nothing at all.

Anyway, how about using a HID class to comunicate? Do I need a VID? I mean The whole idea of HID is to be standard so no driver is needed and therefor you shouldn't need a custom VID right?

[mikeselectricstuff]

The FTDI way works great, you can program the EEPROM of your FTDI chip to let your device be enumerated in device manager with a certain name. Can be used with for example the jd2xx library for PC side.

Thanks! Do you know if it is possible to make the FTDI chip enumerate as a VCP when a pin is high and to use D2XX drivers when the pin is low or something like that?

I need that because I would like to enumerate as VCP when I want to load the bootloader but as D2XX when is running normally.

Why ?
By default the device can be accessed via either VCP or D2XX. I think you can set EEPROM bits to disable VCP, but I'm fairly sure D2xx is always available.
There was a time in the past where VCP and D2XX were separate drivers but these got unified into one several  years ago.

[janoc]

Anyway, how about using a HID class to comunicate? Do I need a VID? I mean The whole idea of HID is to be standard so no driver is needed and therefor you shouldn't need a custom VID right?

All USB devices need a VID:PID pair, even if you use one of the standard classes (like HID). That only lets you avoid having to implement a custom driver.

[Twistx77]

The FTDI way works great, you can program the EEPROM of your FTDI chip to let your device be enumerated in device manager with a certain name. Can be used with for example the jd2xx library for PC side.

Thanks! Do you know if it is possible to make the FTDI chip enumerate as a VCP when a pin is high and to use D2XX drivers when the pin is low or something like that?

I need that because I would like to enumerate as VCP when I want to load the bootloader but as D2XX when is running normally.

Why ?
By default the device can be accessed via either VCP or D2XX. I think you can set EEPROM bits to disable VCP, but I'm fairly sure D2xx is always available.
There was a time in the past where VCP and D2XX were separate drivers but these got unified into one several  years ago.

Thanks I will keep that in mind if I choose to go down that path for now I will see if I can implement my own.

Anyway, how about using a HID class to comunicate? Do I need a VID? I mean The whole idea of HID is to be standard so no driver is needed and therefor you shouldn't need a custom VID right?

All USB devices need a VID:PID pair, even if you use one of the standard classes (like HID). That only lets you avoid having to implement a custom driver.

I know that, I think I didn't explain myself. I want to know if there is a VID and PID for a "standard" HID device. Since the "standard" devices always use the same driver, shouldn't they have a standard VID/PID? In that case I would just use those and implement HID class.

[Twistx77]

You can pick a random pair as long as you are confident that it won't collide with anything.
Or, you can buy a license of VUSB, just a $10 hobbyist license is enough, and you will be issued a VID/PID pair.

Thanks. But that is riskier. I would like to know how risky it is.

[janoc]

I know that, I think I didn't explain myself. I want to know if there is a VID and PID for a "standard" HID device. Since the "standard" devices always use the same driver, shouldn't they have a standard VID/PID? In that case I would just use those and implement HID class.

No, the class of the device is determined from the device descriptors, not some pre-defined VID:PID combination. If you want to use one of the standard classes, you simply declare it as such (along with potential additional descriptors like for HID).

The VID:PID serves to distinguish different devices from different manufacturers. You may still want to be able to distinguish different serial ports or printers or what have you even if they use the same driver, because e.g. some may offer some extra functionality accessible to the user that is not part of the standard class spec - such as ink level monitoring for a printer or force feedback on a joystick.

In fact, at least in Windows, even if the device is of standard class (e.g. virtual serial port), you often need to provide at least the .inf file which says that the device with the given VID:PID should be using a standard class driver (and which one). Linux doesn't need this.

See here:
http://www.beyondlogic.org/usbnutshell/usb5.shtml#DeviceDescriptors (the bDeviceClass field)

Defined class codes:
http://www.usb.org/developers/defined_class

[Twistx77]

I know that, I think I didn't explain myself. I want to know if there is a VID and PID for a "standard" HID device. Since the "standard" devices always use the same driver, shouldn't they have a standard VID/PID? In that case I would just use those and implement HID class.

No, the class of the device is determined from the device descriptors, not some pre-defined VID:PID combination. If you want to use one of the standard classes, you simply declare it as such (along with potential additional descriptors like for HID).

The VID:PID serves to distinguish different devices from different manufacturers. You may still want to be able to distinguish different serial ports or printers or what have you even if they use the same driver, because e.g. some may offer some extra functionality accessible to the user that is not part of the standard class spec - such as ink level monitoring for a printer or force feedback on a joystick.

In fact, at least in Windows, even if the device is of standard class (e.g. virtual serial port), you often need to provide at least the .inf file which says that the device with the given VID:PID should be using a standard class driver (and which one). Linux doesn't need this.

See here:
http://www.beyondlogic.org/usbnutshell/usb5.shtml#DeviceDescriptors (the bDeviceClass field)

Defined class codes:
http://www.usb.org/developers/defined_class

Merci beacoup!

I understand but that is just ridiculous that it doesn't exist a "Generic" VID and PID for standard classes and you would need to waste a PID to repit in many cases the same exact functionality...

So in conclusion, for anyone that could find this post.

There is three ways to make a USB product:

 1) Use a chip dedicated to do so like FTDI's.
 2) Pay to get a VID.
 3) Use a VID that you think it might not be used and risk to get sued or whatever.

I guess I will go for the third one for now and if my prodcut has success I will get one. But I mean, there only 16 bits of addresses...  What will happen after that? just add another 16? They could've just add 128bit and let everyone have their own but no, they had to make money,

[KE5FX]

mcselec.com is the way to go for a commercial product.  If it makes a billion dollars and you catch grief for it, you'll be able to afford to buy a 'real' VID.  If it doesn't make a billion dollars, no one will ever say anything at all.

[Twistx77]

mcselec.com is the way to go for a commercial product.  If it makes a billion dollars and you catch grief for it, you'll be able to afford to buy a 'real' VID.  If it doesn't make a billion dollars, no one will ever say anything at all.

Yes, I think you are right better that than nothing, 15€ is worth giving a try , at least I know no one will use the same one. At least is the most probable.

[mikeselectricstuff]

 3) Use a VID that you think it might not be used and risk to get sued or whatever.

You will never get sued as long as you don't use the USB logo. It's just a number, nobody owns numbers. The USB cartel just allocates you a number in exchange for allowing you to use their logo.
The worst that can happen is  your device may clash with another installed in the machine ( or maybe if that device gets its driver included in Windows)

[Twistx77]

 3) Use a VID that you think it might not be used and risk to get sued or whatever.

You will never get sued as long as you don't use the USB logo. It's just a number, nobody owns numbers. The USB cartel just allocates you a number in exchange for allowing you to use their logo.
The worst that can happen is  your device may clash with another installed in the machine ( or maybe if that device gets its driver included in Windows)

Thanks mate!

If that is true, I will just get the MCS one, at least is less probable to conflict with another device!

[janoc]

Merci beacoup!

I understand but that is just ridiculous that it doesn't exist a "Generic" VID and PID for standard classes and you would need to waste a PID to repit in many cases the same exact functionality...

Well, because VID:PID is meant to identify a device, NOT its functionality. The functionality of the hw is described by a class.

You can have devices with different VID:PID combos having the same class (e.g. HID) but also devices with the same VID:PID using different classes (e.g. depending on a button pressed the device could boot a serial bootloader for fw update). Also while the VID:PID is unique for the device, each device could be exposing multiple interfaces (e.g. HID + mass storage) and the class can be different per interface.

None of the above would be possible if there were some hardwired VID:PID combos for certain function classes. USB-IF has done all sorts of silly design decisions but this isn't one of them. Not overloading identifiers for unrelated functions is a good engineering practice.

[tatus1969]

I did a FTDI customization quite a few years ago. I remember that FTDI was helping with custom PID. As long as you keep the original FTDI VID (you can still give a custom name, but you cannot entirely hide that information), they generate a custom PID for you and also do the registering /WHQL / updating stuff with MS for you. I don't know if they took a fee for that, or how high that was. I recommend that you get into contact with FTDI staff, they were very kind and friendly (maybe 6 years ago).

[firewalker]

Some years ago USB.org was selling the VID part. This meant you could utilize 0xFFFF number of PIDs.

There are companies reselling (legally) the PIDs owned by them.

Alexander.

[janoc]

Some years ago USB.org was selling the VID part. This meant you could utilize 0xFFFF number of PIDs.

They still do. Or rather they "sell" the USB-IF membership that you need to get the VID - it costs measly $5k annually (used to be $2k).

There are companies reselling (legally) the PIDs owned by them.

Alexander.

Yes, they do. The problem is that all those ranges were revoked unless those companies agreed to "new terms of use" that explicitly prohibit them to resell the IDs.

If you are a product manufacturer that's likely a no-go. For a small scale hobbyist/kit vendor you likely don't need to care much.

[mikeselectricstuff]

Some years ago USB.org was selling the VID part. This meant you could utilize 0xFFFF number of PIDs.

They still do. Or rather they "sell" the USB-IF membership that you need to get the VID - it costs measly $5k annually (used to be $2k).

There are companies reselling (legally) the PIDs owned by them.

Alexander.

Yes, they do. The problem is that all those ranges were revoked unless those companies agreed to "new terms of use" that explicitly prohibit them to resell the IDs.

If you are a product manufacturer that's likely a no-go. For a small scale hobbyist/kit vendor you likely don't need to care much.

They can never re-issue a revoked VID as so that's academic. As long as you don't use their logo there's nothing they can do.