USB VID and PID question - Page 1
Forum section: electronics / general

author: technix
author_rank: Super Contributor
timestamp: October 19, 2017, 04:40:14 pm
content: 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 calledobsolete 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...

author: ataradov
author_rank: Super Contributor
timestamp: October 19, 2017, 05:16:40 pm
content: Quote from: technix on October 19, 2017, 04:40:14 pmThere 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.

author: technix
author_rank: Super Contributor
timestamp: October 19, 2017, 05:40:03 pm
content: Quote from: ataradov on October 19, 2017, 05:16:40 pmI 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 19, 2017, 05:42:06 pm
content: 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.

author: technix
author_rank: Super Contributor
timestamp: October 19, 2017, 05:47:56 pm
content: Quote from: ataradov on October 19, 2017, 05:42:06 pmIn most cases it is enough. Now it is a light dimmer. It is two bytes every 30 minutes or so...

author: funkathustra
author_rank: Regular Contributor
timestamp: October 19, 2017, 07:00:56 pm
content: 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/

author: asmi
author_rank: Super Contributor
timestamp: October 19, 2017, 07:31:40 pm
content: Quote from: ataradov on October 19, 2017, 05:42:06 pmWhenever 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.

author: rheb1026
author_rank: Regular Contributor
timestamp: October 19, 2017, 09:28:30 pm
content: Quote from: funkathustra on October 19, 2017, 07:00:56 pmST does as well. We use them at work and their rep told us that they would sub-license us a VID/PID pair

author: technix
author_rank: Super Contributor
timestamp: October 19, 2017, 09:36:00 pm
content: Quote from: blueskull on October 19, 2017, 07:49:28 pmI 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...)

author: janoc
author_rank: Super Contributor
timestamp: October 19, 2017, 10:35:41 pm
content: 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.

author: bobaruni
author_rank: Regular Contributor
timestamp: October 20, 2017, 01:13:41 am
content: Quote from: ataradov on October 19, 2017, 05:42:06 pmYes, 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 20, 2017, 01:22:35 am
content: Quote from: bobaruni on October 20, 2017, 01:13:41 amControl 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: October 20, 2017, 01:43:02 am
content: Quote from: ataradov on October 20, 2017, 01:22:35 amFeature 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 20, 2017, 01:45:44 am
content: Quote from: NorthGuy on October 20, 2017, 01:43:02 amBut the size of control endpoint is still 64 bytes. It may take a few transfers to send the whole payload, of course.

author: KE5FX
author_rank: Super Contributor
timestamp: October 20, 2017, 02:06:40 am
content: Quote from: technix on October 19, 2017, 04:40:14 pmLOL. They mad at MCS

author: ataradov
author_rank: Super Contributor
timestamp: October 20, 2017, 02:08:18 am
content: Quote from: KE5FX on October 20, 2017, 02:06:40 amThis just means that MCS stopped paying royalties.

author: NorthGuy
author_rank: Super Contributor
timestamp: October 20, 2017, 02:24:35 am
content: Quote from: ataradov on October 20, 2017, 01:45:44 amBut there may be several (possibly many) packets per frame, not just one as with the interrupt endpoints. Of course, it depends on the host.

author: KE5FX
author_rank: Super Contributor
timestamp: October 20, 2017, 03:27:12 am
content: Quote from: ataradov on October 20, 2017, 02:08:18 amAlso, the whole "Reselling PIDs" thing.

author: ataradov
author_rank: Super Contributor
timestamp: October 20, 2017, 03:33:24 am
content: Quote from: KE5FX on October 20, 2017, 03:27:12 amWell, 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.

author: technix
author_rank: Super Contributor
timestamp: October 20, 2017, 05:13:34 am
content: Quote from: janoc on October 19, 2017, 10:35:41 pmIf I do want to certify it I would have got my own VID anyway, as a prerequisite of certification.

author: bobaruni
author_rank: Regular Contributor
timestamp: October 20, 2017, 11:40:52 am
content: Quote from: ataradov on October 20, 2017, 01:45:44 amCorrect, 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: October 20, 2017, 01:59:18 pm
content: Quote from: bobaruni on October 20, 2017, 11:40:52 amYou 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).