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.
Reply by John Temples●September 23, 20142014-09-23
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.
Reply by WangoTango●September 22, 20142014-09-22
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
Reply by Wouter van Ooijen●September 22, 20142014-09-22
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
>
Reply by John Speth●September 22, 20142014-09-22
> 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
Reply by Wouter van Ooijen●September 22, 20142014-09-22
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
Reply by Theo Markettos●September 22, 20142014-09-22
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
Reply by Al Clark●September 22, 20142014-09-22
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.
>
Reply by Ulf Samuelsson●September 21, 20142014-09-21
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
Reply by Wouter van Ooijen●September 21, 20142014-09-21
>>> "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