[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:

> >> Because that's output-only, not "the output one byte, input one
> >> byte, repeat" paradigm I'm actually using.
> > But you're controlling *relays*... (??)
> 
> Oh, two different projects.  The relay controller, yes, is
> open-loop.
> 
> I've done two others, each of which uses the send/read/send/read
> paradigm.  One is the ROM reader I alluded to briefly upthread; the
> other is a cable pinout sensor (plug a cable in and the host driving it
> can sense which pins are connected to which other pins).

But, neither is going to suddenly become impractical if you have
10,000 traps vs. *1* trap.  And, certainly the rest of the
system isn't going to cringe if you burn a few gazillion
CPU cycles trying to read 64Kbytes out of a PROM...

If you're trying to do something that needs its own processor,
then *give it* it's own processor!  If you're trying to do
something that's just exploits the "convenience" of having a 
processor to do the work (e.g., turn on your desk lamp each
morning based on whether or not your calendar(1) says you
have a meeting that day), then chances are it won't matter
how inefficient the code is.

I wrote a routine to crack a security device (essentially
a FSM with 8 bits of state and 8 inputs).  It just hammered
away at the device building a state transition table from
each set of (current state, inputs) data.  Each iteration
required a write to the device and a read from it.  It
ran in user-land (because the OS was "closed").  The time
it took to run was less than the time it took to write the
results file!

> >>> 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.
> 
> My misreading, then; I read "(more portable) and
> (future-safe)", rather than "more (portable and future-safe)".
> 
> > Thinking this out can be a real win.  E.g., like UN*X opting to treat
> > everything as files.
> 
> ...except things that aren't.  Network interfaces. 
> Shared memory segments.  ioctl().  sysctl().

Sure!  There are exceptions to everything.  Otherwise, there
would onoy be a need for *one* OS, one text editor, one PCB
layout tool, one geek port, etc.  You try to come up with a
solotion that gives you 80% of the solution for 20% of the
work.  The other 20% you either *ignore* or "spend disproportionately
more resources on"

> Also, a paradigm like that can be as constraining as any other.  I once
> was hired to build glue code between an experimental encrypted
> distributed storage paradigm and the Unix filesystem paradigm.
> It took me six months.