Serial interfaces (was Re: Any former Psion 5 owners out there?)
ethan.dicks at gmail.com
Tue Jul 20 09:15:46 CDT 2010
On 7/19/10, Liam Proven <lproven at gmail.com> wrote:
> I am very happy to say that I have not used a serial port for anything
> in a good 2-3y now, and not for anything more than a very occasional
> sync of my Psion 7book...
I use serial ports every week.
> I really hate RS232. It is the most troublesome interface of any kind
> on any computer I've ever used. I celebrate its disappearance with joy
> and I hope never to have to use such a port again. All the crap with
> baud rates, stop bits, parity bits, flow control and all that hateful
> 1960s-ish nonsense is just a fading memory now and I hope I never have
> to refresh it.
It may be hateful 1960s nonsense, but if you know how it works,
presuming you have the ability to control all the parameters of one
end of a connection (software-controlled params, jumpers, straps,
solder bumps, etc), you can still take something made in 1968 and
attach it to something made in 2008.
One recent case in point - After a couple of nights studying the
schematics and the present state of the wiring (they mostly matched,
after a fashion) of a 1970s Bridgeport Series II CNC mill (that has an
embedded LSI-11 CPU!), I was able to build a round-8-pin-connector to
DE-9 serial cable and interface the Bridgeport to a modern Dell that
was also being used to drive a Shopbot. One thing relevant to this
discussion about it was that we struggled with verifying that it
worked when we tried to talk to it via a handy Thinkpad with a USB
serial adapter (communication worked from the Bridgeport, but not to
it). On a hunch, once we located a 6' extender cable, it worked on
the Dell the first try. I'm reasonably certain the voltages on the
USB serial adapter were out of spec for "true" RS-232 - the Bridgeport
uses 1488s and 1489s, not modernish MAX232 drivers or other
wiildly-forgiving line drivers/recievers.
So for wiring up a passive cable, I was able to breathe life into a
30+ year old three ton machine. I was possible because I had a
machine with a proper RS-232 port that stepped in where a machine that
only had USB failed.
> Apple did serial ports right on the Mac. You plugged things in, they
> worked, thankyou and goodnight.
Mac-designed things, sure, but Apple didn't make it easy to talk to
the world full of "standard" serial devices (of which there were
*lots* in the 1980s).
> But try interfacing non-Apple kit to
> Macs, or to anything else, and the horror-story of RS232 dropped you
> into the nightmare of RS423 and so on. I shudder to recall.
Exactly. Around the time the Mac switched from DE-9s to DIN8s, I was
in the business of manufacturing serial interfaces for DEC hosts. I
worked with sync and async RS-232 cables and ports and drivers and
application code every day. I still found it to be a pain to get the
right arrangement to hook a Mac up to some foreign device. It got
easier later when you could just buy a suitable cable off the shelf,
but for a time, it was difficult.
> I really like USB.
I really do not like USB. It takes hundreds of cycles and more to
move a simple message, it's a host-based, not bi-directional design,
and it's only available on somewhat newish kit.
The host-based aspect of it is probably my biggest peeve - with a
serial port, it's just TxD, RxD and perhaps some handshaking lines
(more likely in the past, but sometimes supported in recent products).
What that means to me is that I can buy a device that might be
intended as a client (a Palm Pilot, to give a specific and handy
example) and by dropping an app on it, turn what was manufactured to
be a "receptive" device into an "active" device - such as use it as a
VT100 replacement for configuring Cisco routers (boy my boss's eyes
bugged out when I pulled a Palm out of my pocket, clicked in a serial
cable and fixed something in seconds instead of leaving the room,
retrieving a laptop, setting it up, etc., etc.)
A USB-equipped Palm is meant to be addressed as a 'peripheral' and
cannot be a 'host' - that limits its usefulness to me.
> For storage, I preferred Firewire, but that's going away now, sadly.
I will agree with you there. Just last night, I was helping a friend
with a dying LaCie drive on a Macbook and I was happy we had a
Firewire 800 cable that walked into the door at the right moment - it
turned a 55 hour copy job via USB into a 31 hour copy job (dd to a
container file - hopefully there's enough left of the old drive to
extract enough files from to make the exercise worthwhile).
> But USB works, is wonderfully versatile, fairly
> idiot-proof and does everything I want or need: keyboard, mice,
> scanners, printers, storage, modems and networking once in a blue
> moon... It's terrific.
It has some advantages - power for light-duty peripherals is great,
simple connectors is great, not having to worry about DCE and DTE
orientation is handy. It's great for mice and keyboards, sure, but
I'm less convinced about higher-bandwidth uses.
And lest you think this is all some sort of neo-luddite rant, I've
built and programmed USB-based peripherals like the USB4LCD. I
participate (occasionally in recent years) on the libusb developers'
mailing list. I've written user-mode USB drivers with libusb. I've
debugged USB command packets and initialization code. I'm using a USB
mouse right now. USB still drives me nuts.
I'm hardly advocating the death of USB (though I don't think I'd shed
a lone tear over it). What disappoints me is the loss of a "real"
serial port on portable hardware (starting with old Macbooks, but now
across the Intel world as well) and the massive overhead that comes
with using a "USB serial port" (like the well-documented problems that
Makerbot folks have with FTDI driver issues - things work better when
you don't have a USB physical layer between your application code and
your Makerbot, but few people run that way, in part because for many
bot owners, their Netbooks or Macbooks or whatever have any sort of
way to talk to the outside world except WiFi, Ethernet or USB).
I also do a lot with microcontrollers, MCS51-family and Atmel AVR,
mostly. You _can_ make an 8MHz Atmel do USB in software (cf USB4LCD),
but it's a whole lot easier to tell that same chip that there's
someone connected on its UART and speaking async at 9600 8N1 - you get
lots more of your ROM available for application code, and you can
attach that MCU to a much larger field of devices with a simple serial
P.S. - I know USB is "consumer-friendly" and I know I fall far, far
outside the definition of a "consumer", but that doesn't change the
fact that ubiquitous RS-232 ports make my life easier and USB comes
with a bag of hassles.
More information about the cctech