--- 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.