18 Aug
2012
18 Aug
'12
10:16 p.m.
On 08/18/2012 11:29 PM, Mouse wrote:
Well...just two comments about that: You're not a potential user of
this device (no offense intended...see below), and I consider USB to be
pretty standard.
> For what
it's worth, at work, I've taken to putting an FT232 (or
> 2232 or 4232, depending on how many ports) on new boards instead of
> real RS232 [...]
Yeah, y'know, I'm doing a bit of that
myself lately. [...]
Just how "unclean" is it to waste the
on-chip USB controller just
because of the suitly crap surrounding the Vendor IDs and stuff?
As a potential device user, I would prefer to have a serial port (on a
tiny connector if physical space is an issue - provided either you
provide a dongle to something at least pseudo-standard or I can solder
to the pads and run wires out to whatever connector I want). If you _must_ go USB,
I must. It is a requirement from the customer, and this is for my
employer. I personally prefer standard RS232 serial I/O as well, at
9600 8/N/1 like the rest of the world. The customer, however, has
several thousand field personnel whose laptops do not have RS232 ports,
and whose other field tasks involve connecting to USB-interfaced
devices. (and many of those are FTDI-based)
I would _much_ rather have a USB device that looks
like
a serial port, with known, reliable, stable software on the host, than
something which requires either running a vendor binary blob (which
usually won't run on what I want to talk to it with even if I were
willing to run it) or doing a bunch of driver hacking. "Unclean" can
go hang - especially if the alternative would mean increasing the
device cost to make up for having to buy a vendor ID.
"Unclean" will not "go hang" here. I am incredibly anal with my
designs. Period.
With that out of the way...I design industrial control and
communications systems based on requirements from the customer. They
use OS X, Linux, and occasionally even Windows laptops in the field to
access their devices. They don't mind installing the FTDI drivers on
their machines to access their devices. FWIW, FTDI-based async serial
ports work under NetBSD as well.
I *think* there is a USB async serial I/O profile, but nobody (that I
know of) has implemented it, and there has to be a reason for that.
I've designed several USB peripherals and I am only peripherally (ahem)
aware of the possible existence of the USB async serial I/O
profile...that tells you how much traffic THAT gets.
If you really want your device to be useful to users
(as opposed to
being useful to software license-to-use sales or some such), the only
excuse I can see for not looking like a stock serial port is if your
device wants to do something that is difficult or impossible within the
serial-port abstraction - or if there's already a standard abstraction
available for your device. (A video camera might be an example of both
of those simultaneously.)
This is not a consumer device. I am not looking for an "excuse" to
design in USB support.
USB is not evil. In fact, for what it was designed to do, it works
amazingly well. It's not even "new" anymore, so we can't use that
excuse. In this case, though, this is what the (highly technical and
just as anal as I am) customer has requested, and that's what they're
getting. My question was an attempt to get a fellow designer's opinion
of the level of design ugliness brought forth by implementing it with a
separate chip, a widely used industry-standard controller (FTDI), while
my microcontroller already has USB support (multiple in fact) on-chip.
Fortunately said microcontroller has the ability to actually power
down any peripheral controllers that are not in use. I like that a lot.
One other important point here...there is insufficient space available
for a DB25 or DE9 connector on the last two boards I designed. In most
cases these control systems must mount inside existing systems' chassis,
so physical form factor (as well as power, etc) are dictated for me.
(as annoying as that is!)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA