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

der Mouse mouse at Rodents-Montreal.ORG
Thu Aug 21 14:29:17 CDT 2008

>> Give me a nice simple breadboard full of TTL.  No clocks, no CPUs,
>> no tri-state buses, no RAM or ROM.  I've got one such circuit in
>> production use right now, controlling the relays I installed into a
>> 12-outlet power bar.
> But, can't you get a "USB printer cable" (USB connector on one end
> and centronics connector on the other) and treat *that* as if it were
> your printer port?

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

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

> and whatever limitations it places on the sequencing of control pins
> (i.e., you can't toggle any pin at any time, arbitrarily).

This goes back to my remark about the difference between a parallel
port and a printer interface that happens to speak parallel-port
printer protocol.

> Note that you can also easily fabricate a serial-parallel converter

I can?  How?  I'll need _at least_ a clock, and quite probably at least
two or three other chips I don't have and don't have documentation on,
whereas a real parallel port I can talk to even with discrete
transistors if I want to.

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

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

More information about the rescue mailing list