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

[Joshua Boyd]

On Thu, Aug 21, 2008 at 03:29:17PM -0400, der Mouse wrote:

> In my particular case, no, largely because I have so few machines with
> working USB.  That aside, I don't know; it depends on what the host
> interface looks like.  If it means doing a dance with some USB
> interface, then it is substantially less convenient, because of that;
> one of the things I did was to diddle the parallel-port driver so I
> could pass in an array of bytes and have it shove each one onto the
> output lines, then replace the byte in memory with the resulting values
> of the input lines.  This was easy because the thing is, after all,
> just, well, a parallel port.  My understanding of the USB devices is
> that they aren't parallel ports, except at the device-interface end;
> they're actually printer interfaces that happen to speak parallel-port
> printer protocol out the printer-interface end.
> 
> If someone has a real USB parallel-port interface, as opposed to a USB
> printer interface that speaks parallel-port printer protocol out the
> printer end, I'd be interested.  (It would still be substantially less
> convenient than a real parallel port, but it probably would have uses
> nevertheless.)

FTDI makes such a chip, and sells modules (under $20) build on that
chip.  Drivers for linux and freebsd are included with the respective
OSs, so I would imagine that they are also in NetBSD.

If you use the driver, the overhead of setting up the USB connection
should be nonexistant from your software's perspective.  On linux, it
shows up as /dev/ttyUSBx.

Here is a ready made device based on this chip:
http://www.fivemanconspiracy.com/node/45

DJ Delorie also has a simple design based on a 232 chip and a R8C/20 uC:
http://www.delorie.com/electronics/usb-gpio/

There are other GPIO type chips as well.  Plus, you can always use a
small uC on a serial port.  I believe the ATtiny2313 might be exactly
what you'd want (hardware UART, external clock not required, DIP
package).  

> > The potential problem I see there is you can't just push a nice byte
> > stream out an I/O port and have those values appear sequentially on a
> > set of pins -- you're now stuck going through the USB driver (which
> > at least solves *that* problem)
> 
> Not really; the application-facing interface presented by a USB stack
> is substantially more complicated than that presented by a serial port.

Why wouldn't it be that the application-facing interface is only as
complicated as the driver makes it?

> I think you'd also have trouble finding a serial port that could run at
> parallel-port speeds.  My ROM reader can grab 64KB of ROM contents
> through a parallel port faster than you can send 64KB over a 115.2Kbaud
> serial line (I think - it's been a while since I tried it, but I think
> it's only something like two to three seconds).  And that's with a
> completely clockless flying-wire rat's-nest breadboard circuit.  The
> serial-line version requires substantially more complexity (at least a
> UART, implying a clock, and probably some kind of microcontroller).

There may be no simple way to go faster than 115kbps.  However a good
USB->uC should be able to go faster, and it shouldn't cost you much to
build. 

A good 232->uC that can go faster is likely to be trouble some, unless
you have one of the really high speed serial cards for a Sun (or other
machine). 

For a some amount more cash spent on the project, you could build
something network capable and a lot faster.  To me, that would be the
write way to do it.  It seems to me that ethernet isn't expensive if you
can built it yourself, but it is pretty expensive to buy premade
modules.  

PCI would be another option, but premade PCI protoboards are also a bit
expensive, and they will likely require that you run free proprietary
software on linux or windows to program them.