USB? Ethernet? Bluetooth?

>>> "They may not be sold, transferred, or used by others, directly or
>>> indirectly, except in special circumstances, and then only upon prior
>>> written approval by USB-IF." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Which you can probably get if you're ginormous.
>
> Yeah, that's my point.  Microchip, NXP, etc have likely paid some fee
> and are on the panel so they get what they want and share it with us.

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

2014-09-19 19:43, Tim Wescott skrev:
> To date, most of my headless embedded development has been either entirely
> stand-alone, or has communicated with the outside world via serial.
>
> Serial is kinda old, and getting clunky.  Yes, you can use a USB to serial
> converter from FTDI or whoever, but then you have a USB connection that
> needs to have a baud rate specified, which is just strange.
>
> On the other hand, USB and Bluetooth both seem to have development models
> that demand that if you're going to do something new and unique that you
> spend $$$$$$ to create some new class of device, with vendor ID and all
> that associated folderol.  It's nice if you're building 100,000 a year or
> more, but not so nice if you're building a few hundred per year.
>
> I'm working on a device that has a need for robust and graceful
> communication with PCs.  On the one hand, data rates are not at all high
> -- once or twice a second the thing needs to report that some action has
> happened, and possibly cough up a measurement at the same time.  On the
> other hand, they need to work in harsh environments that make wired
> connections expensive, so having them communicate wirelessly is a good
> thing.
>
> It can't be assumed that these things will have a 1:1 connection with
> PC's, either -- it should be assumed that up to a dozen could all be at
> work, funneling data to one PC.
>
> So, if YOU were going to build a device than needed to communicate with a
> PC in a reasonably robust and seamless fashion, and it was going to be
> fairly low production volume, and if wireless were desirable but not
> necessary, how would YOU do it?
>
> If I were to ignore the desired "wireless" part, I think I'd be looking at
> how the PLC manufacturers network their boxen on Ethernet.
>

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

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 <seemywebsite@myfooter.really> wrote in
news:tb2dnfel0b3V9oHJnZ2dnUU7-cmdnZ2d@giganews.com: 

> To date, most of my headless embedded development has been
> either entirely stand-alone, or has communicated with the
> outside world via serial. 
> 
> Serial is kinda old, and getting clunky.  Yes, you can use
> a USB to serial converter from FTDI or whoever, but then
> you have a USB connection that needs to have a baud rate
> specified, which is just strange. 
> 
> On the other hand, USB and Bluetooth both seem to have
> development models that demand that if you're going to do
> something new and unique that you spend $$$$$$ to create
> some new class of device, with vendor ID and all that
> associated folderol.  It's nice if you're building 100,000
> a year or more, but not so nice if you're building a few
> hundred per year. 
> 
> I'm working on a device that has a need for robust and
> graceful communication with PCs.  On the one hand, data
> rates are not at all high -- once or twice a second the
> thing needs to report that some action has happened, and
> possibly cough up a measurement at the same time.  On the 
> other hand, they need to work in harsh environments that
> make wired connections expensive, so having them
> communicate wirelessly is a good thing.
> 
> It can't be assumed that these things will have a 1:1
> connection with PC's, either -- it should be assumed that
> up to a dozen could all be at work, funneling data to one
> PC. 
> 
> So, if YOU were going to build a device than needed to
> communicate with a PC in a reasonably robust and seamless
> fashion, and it was going to be fairly low production
> volume, and if wireless were desirable but not necessary,
> how would YOU do it? 
> 
> If I were to ignore the desired "wireless" part, I think
> I'd be looking at how the PLC manufacturers network their
> boxen on Ethernet. 
> 

Wouter van Ooijen <wouter@voti.nl> wrote:
> 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.

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

Theo Markettos schreef op 22-Sep-14 6:02 PM:
> Wouter van Ooijen <wouter@voti.nl> wrote:
>> 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.
>
>  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 think those people are right, but as a one-man-company I did not want 
to take the risk, so I just stopped.

Wouter

> On the other hand, USB and Bluetooth both seem to have development models
> that demand that if you're going to do something new and unique that you
> spend $$$$$$ to create some new class of device, with vendor ID and all
> that associated folderol.  It's nice if you're building 100,000 a year or
> more, but not so nice if you're building a few hundred per year.

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

John Speth schreef op 22-Sep-14 7:08 PM:
>> On the other hand, USB and Bluetooth both seem to have development models
>> that demand that if you're going to do something new and unique that you
>> spend $$$$$$ to create some new class of device, with vendor ID and all
>> that associated folderol.  It's nice if you're building 100,000 a year or
>> more, but not so nice if you're building a few hundred per year.
>
> 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.

You can find the list of PID ranges I re-sold at http://www.voti.nl/pids/

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


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

In article <tb2dnfel0b3V9oHJnZ2dnUU7-cmdnZ2d@giganews.com>, 
seemywebsite@myfooter.really says...
> To date, most of my headless embedded development has been either entirely 
> stand-alone, or has communicated with the outside world via serial.
> 
> Serial is kinda old, and getting clunky.  Yes, you can use a USB to serial 
> converter from FTDI or whoever, but then you have a USB connection that 
> needs to have a baud rate specified, which is just strange.
> 
> On the other hand, USB and Bluetooth both seem to have development models 
> that demand that if you're going to do something new and unique that you 
> spend $$$$$$ to create some new class of device, with vendor ID and all 
> that associated folderol.  It's nice if you're building 100,000 a year or 
> more, but not so nice if you're building a few hundred per year.
> 
> I'm working on a device that has a need for robust and graceful 
> communication with PCs.  On the one hand, data rates are not at all high 
> -- once or twice a second the thing needs to report that some action has 
> happened, and possibly cough up a measurement at the same time.  On the 
> other hand, they need to work in harsh environments that make wired 
> connections expensive, so having them communicate wirelessly is a good 
> thing.
> 
> It can't be assumed that these things will have a 1:1 connection with 
> PC's, either -- it should be assumed that up to a dozen could all be at 
> work, funneling data to one PC.
> 
> So, if YOU were going to build a device than needed to communicate with a 
> PC in a reasonably robust and seamless fashion, and it was going to be 
> fairly low production volume, and if wireless were desirable but not 
> necessary, how would YOU do it?
> 
> If I were to ignore the desired "wireless" part, I think I'd be looking at 
> how the PLC manufacturers network their boxen on Ethernet.

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

On 2014-09-22, WangoTango <Asgard24@mindspring.com> wrote:
> 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.

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

In article <slrnm21uaa.oh8.usenet@xargs-spam.com>, usenet@xargs-spam.com 
says...
> On 2014-09-22, WangoTango <Asgard24@mindspring.com> wrote:
> > 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.
> 
> Or just look for the serial port with your USB VID/PID.
> 
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.