[rescue] Parallel ports [was Re: Slightly OT: ?Bad Cap Saga]
jorge234q at yahoo.com
Fri Aug 22 13:01:45 CDT 2008
--- 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
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
[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.
More information about the rescue