20 Jul
2010
20 Jul
'10
12:03 p.m.
On 7/20/10, Dave McGuire <mcguire at neurotica.com> wrote:
Agree 100% here. For anything non-consumery, async serial is still
the mainstay, and likely always will be.
That, I think, is key - "non-consumery". I have a lot of that lying
about. I even build stuff from scratch that's trivial to interface to
with RS-232 and wouldn't be so easy to embed USB into. As I admitted
at the start, though, I recognize I'm far from a typical consumer.
On 7/20/10 10:15 AM, Ethan Dicks wrote:
I can honestly admit that I take days off ;-) Of all the hours spent
pumping bits over serial ports over the past year, I'd have to say
that the most frequent occasions are reprogramming AVRs (via
serial-aware bootloader), monitoring debug output from said AVRs,
driving Makerbots, driving intelligent LCD displays, and interacting
with Cisco consoles. I do these things every week, but not every day
of the week.
I use serial ports every week.
Only every week? Every DAY here. ;) I really hate RS232. It is the most troublesome
interface of any kind
on any computer I've ever used....
It may be hateful 1960s nonsense, but if you know how it works...
you can still take something made in 1968 and
attach it to something made in 2008. I use serial ports all day,
every day when I wear either my embedded systems designer or network
engineer hats. The only time I generally don't use it is when I'm
wearing my programmer hat.
I still use them while wearing my programmer hat, but I write drivers
to talk to LCDs (www.lcdproc.org).
What's so hard about baud rates, stop bits,
parity bits, and flow
control?
Especially since 90% or more of what's in use today is 8N1 at some
speed, very commonly 9600, though faster speeds are not rare. Yes,
you might have to guess and test a few times (vs USB only having 3
possible speeds and the newer interfaces able to clock down to match),
so I'd say it's only "hard" if nobody tells you what the other end is
expecting and you end up trying all combinations of all parameters.
Interfacing to the Bridgeport was made easier by being able to inspect
the schematic - it uses a 6402 hardware-configured UART and the
configuration is clearly 8N2 (which is unusual, but the schematic
clearly shows it).
The only time I've used parity recently is while connecting to an
SBC6120 running OS/8. Other than that one platform (and that oddball
Bridgeport), I haven't configured anything except 8N1 in probably 20
years.
I'll take that over the USB enumeration process
any day. That
said, I am definitely a fan of USB, but when something's not working,
simpler is better, and USB is FAR from simple for anything but the most
pedestrian of consumer-level uses.
Agreed.
-ethan