USB? Ethernet? Bluetooth?

Been there, done that.

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.

Wouter van Ooijen

Reply to
Wouter van Ooijen
Loading thread data ...
2014-09-19 19:43, Tim Wescott skrev:

A Beaglebone Black with an USB COTS WiFi Dongle is not that expensive. If you start with other RF, you probably need much more development.

BR Ulf Samuelsson

Reply to
Ulf Samuelsson

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:

Reply to
Al Clark

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.

Theo

Reply to
Theo Markettos

I think those people are right, but as a one-man-company I did not want to take the risk, so I just stopped.

Wouter

Reply to
Wouter van Ooijen

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.

JJS

Reply to
John Speth

John Speth schreef op 22-Sep-14 7:08 PM:

You can find the list of PID ranges I re-sold at

formatting link

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

Reply to
Wouter van Ooijen

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.

Jim

Reply to
WangoTango

Or just look for the serial port with your USB VID/PID.

Reply to
John Temples

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.

Reply to
WangoTango

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.