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