I have bought a USB Vendor ID, and for some time I sold product ID ranges. The USB org contacted me that they did not like that. I decided it was not worth the risk and stopped.
The exception that you can sub-license product ranges to customers of your hardware is well-documented and open to everyone owning a vendor ID, but it is worded in a way that makes it practical only for hardware (chip) vendors.
USB clearly has distance limitations but is the most ubiquitous interface on a PC.
You mentioned assigning COM Port numbers with FTDI. You can also use a DLL that bypasses the serial port assignments. Each device can be enumerated separately without port assignments.
This is fairly easy to implement. You can probably get some PIDs assigned and use the chip manufacturer's VID. You just need to contact FTDI. I assume some of the other players have similar solutions.
You could consider Ethernet. Each devive might need a MAC. You can get these by using a Microchip EEProm with the MAC included. Your next issue is the software management of Ethernet. Wiznet simplifies many of these issues. With Ethernet you can have long distances and even supply power (PoE).
Zigbee seems like a natural wireless solution over Bluetooth.
just ideas & comments
Al Clark
Tim Wescott wrote in news: snipped-for-privacy@giganews.com:
From what I read, it previously wasn't forbidden by the USB-IF, so people started to do this. Then the USB-IF said 'we don't like this, don't do it' and changed the agreement to forbid it. But the people who made/make a business out of it said 'that wasn't in the agreement we signed' and carried on doing it. Maybe some fun with lawyers happened, I don't know.
I would not eliminate USB because of the VID registration cost if the target is a closed system. You can use any VID you think would not collide with the use of the product in the environment and its lifetime. By closed system I mean a system that you have control or can reasonably expect that certain drivers and devices will not be used.
For example, if your deployed environment is a factory floor and you decide to "borrow" XYZ companys' VID and XYZ makes MP3 players, then using their VID would be extremely low risk. Even less risk if the port will be used just by a tech for service, debug, or something like that.
This practice is typically considered breaking the rules but there is no rule other than what your customer demands.
I'd pick USB to serial. It's easy to implement and host side support for COM ports is huge.
In this list you can see that I reserved the range 5824:1000..1009 (all numbers in decimal!!!) for exactly such use. Use them as you see fit, as long as no product that uses these numbers ever leaves your controlled environment (and thus can not meet another device that similarly uses these numbers).
There are plenty of microcontrollers with built in USB transceivers and tool chains that have sort of USB stack available. We do a LOT of virtual COM port goodies. Your device has a mini/micro USB connector on it and you provide an INF file that basically points back to Windows' provided virtual com port driver and off you go. The bytes appear in a buffer just like UART bytes would and your application would require little modifications, if at all. If you want to get slick, you have your Windoze app to some secret handshake poll and look for the response so your app can autodetect the presence of your hardware.
You can also go HID if you want to get into that. It isn't much difference from the MCU's point of view, but gets a little more difficult from the application point of view.
Yep, I forgot to mention that one. I'm not a Windoze guy, but I have had to make a lot test programs, or proof of proper operation things and I use PowerBasic, which doesn't do well with dealing with USB devices and I have been too lazy to just use the Win32 system calls.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.