USB VID and PID question

[technix]

For the STM32F042 project I found a third party USB library that does not depend on Cube. It is a bit sad that it supports only CDC and HID classes. Well I hope either libusb or libhidapi can access them properly under Linux, but so far I am working only under macOS.

Now I need a USB VID/PID pair. There is an interesting list on USB-IF website called obsolete USB VID's. I wonder if you would consider it safe for tinkers to just grab a VID from the list, pick the preferred PID, check on an some databases to see if the VID/PID pair is used anywhere, and if not used, go ahead and bake it into the prototype?

Speaking of, it seem to me that the VID 0x0002 from Ingram was never used for some reason...

[ataradov]

I wonder if you would consider it safe for tinkers to just grab a VID from the list, pick the preferred PID, check on an some databases to see if the VID/PID pair is used anywhere, and if not used, go ahead and bake it into the prototype?

There is a special combination 0x6666:0x6666 that is reserved for development and prototypes.

But if you are looking at a small hobby project, I'd say it safe enough to use whatever VID/PID you like. If USB IF did not want conflicts, they would make VID/PID to be 32-bit and give them to anyone who wants.

It is pretty easy to work with HID devices on Linux and Windows. CDC is even easier, it just appears as a COM-port.

[technix]

I wonder if you would consider it safe for tinkers to just grab a VID from the list, pick the preferred PID, check on an some databases to see if the VID/PID pair is used anywhere, and if not used, go ahead and bake it into the prototype?

There is a special combination 0x6666:0x6666 that is reserved for development and prototypes.

But if you are looking at a small hobby project, I'd say it safe enough to use whatever VID/PID you like. If USB IF did not want conflicts, they would make VID/PID to be 32-bit and give them to anyone who wants.

It is pretty easy to work with HID devices on Linux and Windows. CDC is even easier, it just appears as a COM-port.

I do need a way for the host side software to accurately tell if the exact device is plugged in or not. This is where CDC is a bit less convenient as the host side software can get confused. I am thinking about using HID on the device end and libhidapi on the host end. HID is universally driver free, and libhidapi can work even if the Linux kernel grabbed the device.

[ataradov]

I do like HID for that exact reason. The only bad thing about HID on USB FS devices is speed. You will get 64 KByte/s maximum transfer rate. Good enough for basic control, but not nearly enough to transfer big amounts of data.

[technix]

I do like HID for that exact reason. The only bad thing about HID on USB FS devices is speed. You will get 64 KByte/s maximum transfer rate. Good enough for basic control, but not nearly enough to transfer big amounts of data.

In most cases it is enough. Now it is a light dimmer. It is two bytes every 30 minutes or so...

[funkathustra]

Almost all MCU vendors I've worked with will sublicense one of their PIDs for use with their VID... but I don't think ST is one of them. You may be able to open a support ticket with them and ask, though.

If your project is open-source, you could go this route: http://pid.codes/howto/

[asmi]

I do like HID for that exact reason. The only bad thing about HID on USB FS devices is speed. You will get 64 KByte/s maximum transfer rate. Good enough for basic control, but not nearly enough to transfer big amounts of data.

Whenever I need high speed connection, I use one of FTDI bridge ICs - they offer great range of bandwidth and protocols from basic UART speeds all the way to 3.2 GBit/s (via USB 3.0). They also provide royalty-free drivers, API libraries to make developing host side of things a breeze, and they even offer free USB PIDs if you need them. Their MCU/FPGA-side interface is quite simple and pretty well documented, so integrating them into the project is quite easy. And the biggest advantage - you don't need to know ANYTHING about USB as those ICs handle everything USB-related!! The only real drawback is that the cost of these ICs can be a problem for some projects - it can be anywhere from $1.4 for the simplest FT220X (USB 2.0 FS<-> UART bridge) all the way to $9.7 for highest-performance FT601 (USB 3.0 <-> 3.2 GBit/s 32bit FIFO bridge). These prices are for a singular quantities.

[rheb1026]

Almost all MCU vendors I've worked with will sublicense one of their PIDs for use with their VID... but I don't think ST is one of them. You may be able to open a support ticket with them and ask, though.

If your project is open-source, you could go this route: http://pid.codes/howto/

ST does as well. We use them at work and their rep told us that they would sub-license us a VID/PID pair

[technix]

Remember there's the VUSB for AVR? They offer a $9.9 hobbyist license with a free PID/VID pair that you can use on other projects.
Also, when you assign a PID, keep in mind that Windows will cache it and during the next enumeration, Windows will skip some descriptors, so assign one PID only to one product.

I am currently making use of the unused and reported obsoleted Ingram VID 0x0002 and the PID in range 0xc000-0xffff for my prototypes. (I doubt whether Ingram the company, or its hardware division, still exists or not...)

[janoc]

There is also a list of revoked VIDs published. If you use one of those, you will be pretty much safe because USB IF can't really re-assign them. The OS doesn't really check whether the VID is revoked (what if you actually had an old HW using it?), so it will work just fine.

Just don't try to have your device certified by USB IF as compliant or put the USB logos on it.

[bobaruni]

I do like HID for that exact reason. The only bad thing about HID on USB FS devices is speed. You will get 64 KByte/s maximum transfer rate. Good enough for basic control, but not nearly enough to transfer big amounts of data.

Yes, this speed limit exists but only for interrupt transfers on HID (64 bytes every 1mS).
Control transfers on HID have no such speed limitation and act like a bulk transfer on end point 0.
Using large report size > 1024, I have seen more than 500 KByte/s transfers but could probably do more with some optimization.
I like this approach because no driver is needed for the host using HID.

[ataradov]

Using large report size > 1024,

Control endpoints are 64 bytes, how did you get 1024 bytes?

And you can't do transfers on control endpoints with standard system APIs, so you do need drivers for that.

[NorthGuy]

And you can't do transfers on control endpoints with standard system APIs, so you do need drivers for that.

Feature reports work on all OSes (Win, Linux, Mac) through control transfer on endpoint 0 very nicely. I haven't tried large sizes, but I don't see any reason why you cannot make Feature reports much large than 64 bytes.

However, with control transfers you may not get the nice full duplex which you get with Input/output reports.

[ataradov]

Feature reports much large than 64 bytes.

But the size of control endpoint is still 64 bytes. It may take a few transfers to send the whole payload, of course.

[KE5FX]

There is an interesting list on USB-IF website called obsolete USB VID's.

LOL. They mad at MCS

[ataradov]

LOL. They mad at MCS

This just means that MCS stopped paying royalties.

[NorthGuy]

But the size of control endpoint is still 64 bytes. It may take a few transfers to send the whole payload, of course.

But there may be several (possibly many) packets per frame, not just one as with the interrupt endpoints. Of course, it depends on the host.

[KE5FX]

LOL. They mad at MCS

This just means that MCS stopped paying royalties.

Also, the whole "Reselling PIDs" thing. 

[ataradov]

Also, the whole "Reselling PIDs" thing. 

Well, yes. But they still sell them, even after revocation. And USB IF can't do much about it. In fact, it is better to not enter into a contract with USB IF, if you want to use random VIDs/PIDs.

If I remember correctly, USB IF actually had some program to clean up the list, but it was not clear what it will entail. They will probably never re-use PIDs assigned to rouge companies like that, but reusing identifiers from companies that went out of business > 10 years ago is probably safe, especially after a quick market analysis.

[technix]

There is also a list of revoked VIDs published. If you use one of those, you will be pretty much safe because USB IF can't really re-assign them. The OS doesn't really check whether the VID is revoked (what if you actually had an old HW using it?), so it will work just fine.

Just don't try to have your device certified by USB IF as compliant or put the USB logos on it.

If I do want to certify it I would have got my own VID anyway, as a prerequisite of certification.

[bobaruni]

Feature reports much large than 64 bytes.

But the size of control endpoint is still 64 bytes. It may take a few transfers to send the whole payload, of course.

Correct, still only 64 bytes per transfer but instead of stalling and waiting for the the next interrupt, the next 64 bytes are sent much much sooner.
No special drivers required, conforms to HID, works with native file open read write method in Win and also works using LIBUSB.
Just to clarify, it's a control transfer on endpoint 0 so maybe not technically a feature report.

[NorthGuy]

Just to clarify, it's a control transfer on endpoint 0 so maybe not technically a feature report.

You can do feature reports as well. Unlike output reports sent through control transfers, feature reports can go in both directions (not at the same time though).