[rescue] Parallel ports [was Re: Slightly OT: ?Bad Cap Saga]

[Curious George]

--- On Fri, 8/22/08, der Mouse <mouse at Rodents-Montreal.ORG> wrote:

> >> Right.  At a severe (crippling, I suspect - hm, I should measure
> >> this) speed cost: at least two syscalls - user/kernel crossings -
> >> per byte, instead of one for the whole string.
> > Why can't you use an existing "printer interface"?  Or, open /dev/lpt
> > and write()-ing 500 bytes at a time?  One trap per call.
> 
> Because that's output-only, not "the output one byte, input one byte,
> repeat" paradigm I'm actually using.

But you're controlling *relays*... (??)

> > The challenge I am issuing is to come up with something more general
> > purpose (on the "application hardware" side) than a "parallel port"
> > and more *portable* and future-safe on the "host" (PC) side.
> 
> As for the latter, there is no such thing.

Note that I didn't use the superlative in my description.
Just MORE future-safe.  Damn near anything is more future
safe than the parallel port, nowadays (witness this discussion).

Nothing will *always* be future safe.  But, take an educated
gamble on *a* technology that *seems* like it has a good
chance of lasting "a while".  And, while you are dsigning
a protocol, keep in mind that the "platform" may end up
changing -- will your protocol port easily to a new
underlying hardware base, etc.

> Whatever hardware I pick is vulnerable to being abandoned by 
> computer makers much the way parallel ports are being.

Sure!  Welcome to my world!  Whatever *components* I use may
be obsoleted next week!  There are only certain things I can
do to protect against that:  buy a shitload and build a stockpile
for the foreseeable manufacturing life of the product *or*
design the product so that you *expect* changes and can more
readily (not necessarily *easily*!) accommodate them.

(e.g., I really go out of my way to write portable code!)

> As for the former, that's Hard; how can you get more general purpose
> than a bunch of undedicated signal wires?  A lot of applications need
> something layered atop it, but that's true of USB (which is neither
> universal nor a bus, but that's another rant), of Ethernet, of serial
> lines, of everything that's been proposed.

You can design an interface that puts those "undedicated signal
wires" someplace where you *know* you'll be able to talk to them
in the future!

E.g., imagine you had developed some protocol that allows all
"end user interface" related parameters to be transfered
in-band (i.e., signal levels, timing, etc.)  [note this is
probably not trivial nor practical but ignore for the moment]
Now, you could write applications that talk to that "end user
interface" (through a library call that you wrote and ported
to whatever OS's you were interested in) without concern over
whether it was a "parallel port" that conveyed those data to
the "target hardware", a serial port, a USB port, an ethernet
connection, etc.

So, *when* your interface of choice get obsoleted, you piss and
moan... and then move on to designing a *new* interface using
all the same design decisions you made previously.

Or, maybe you create N different interfaces at once -- each
serving different needs (e.g., a serial port based interface
could easily be reimplemented to use EIA485 for party-line
deployments, etc.)

[unfortunatly, I have been sloppy with my use of "interface"
etc. -- there are way too many places thta term could apply.
But, hopefully context sheds some light on it]

Thinking this out can be a real win.  E.g., like UN*X opting to
treat everything as files.  Or, Inferno's (9P?) file system
implementation.  Simple, elegant ideas.