[HH] cheapest/simplest way to control a relay from a PC

[Tom Metro]

Jack Coats wrote:
> Tell us what you choose, and how it works for you in your application.

I wanted to prototype this using my desktop machine, rather than the
target server, and it doesn't have a parallel port. A while ago I picked
up a cheap USB parallel port converter for possible future hardware
hacking projects, but of course I couldn't find it. I happened to be by
Micro Center today, so I picked up another one. They're only $9.

First thing I noticed is that these adapters use a centronics connector
instead of a DB25, like you'd find on the back of a PC. I guess this
makes sense, as the adapter takes the place of your printer cable. They
did have a model at Micro Center with a DB25 connector (and oddly it
seemed like an even longer cable), but they wanted a ridiculous $40 for
it. I went with the cheap one and figured I could dig a mating
centronics connector out of my junk cable collection.

I plugged in the adapter, saw it was recognized by the kernel, and now I
had a /dev/usb/lp0 device.

I went back to:
http://www.epanorama.net/circuits/parallel_output.html#linuxprogramming

to take a closer look at how they were doing I/O with the parallel port.
The method of directly poking data at addresses didn't seem like it
would fly with the USB emulated port. I followed a link they had for the
Parapin library:
http://parapin.sourceforge.net/

and found no mention of USB in their documentation, so I searched their
list archives, and came up with some discussion. Some of it was from
developers doing experiments, and other threads were people answering
that the Parapin library was incompatible, yet other than implying it
was just an API mismatch, they didn't shed much light on why.

The page for ppdev, a parallel port driver for Linux, starts to provide
some clues:
http://people.redhat.com/twaugh/parport/html/ppdev.html

It explains that the usual printer device, /dev/lp0, provides a
high-level interface, where "a user-space program (such as the printer
spooler) can send bytes in 'printer protocol'. Briefly, this means that
for each byte, the eight data lines are set up, then a 'strobe' line
tells the printer to look at the data lines, and the printer sets an
'acknowledgment' line to say that it got the byte."

In contrast, their driver creates a /dev/parport0, and lets you twiddle
with all the various output and input lines.

While it is theoretically possible to create a ppdev version that
presents the same API while talking to USB hardware, there is no
evidence that such a thing exists. The documentation seems to be from a
pre-USB era. And then there's the question of whether the USB hardware
could even support it...

Thats when I ran across discussions like:
http://libusb.6.n5.nabble.com/libusb-1-0-Error-writing-to-device-td320939.html

which point out that cheap USB adapters require a latching register, as
depicted in this schematic:
http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/hs_freeware/DLO_UsbPrn.zip/DLO_UsbPrnCen.png?bin=PNG

so when you fire data at the adapter, and it cycles the strobe pin, the
register can capture the word and latch it in until the next time you
send data to the port. Without the latch, the data lines will only
output the desired bit pattern momentarily.

At this point I ran lsusb to see what converter chip I had:

Bus 005 Device 004: ID 067b:2305 Prolific Technology, Inc. PL2305
Parallel Port

and did some additional Googling, which showed that this is a very
common chip. The data sheet is easy to find.

I also turned up what appears to be a vendor/hacker that makes an
alternative USB adapter:
http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund%20um%20den%20PC/USB2LPT/index.html.en

which fully emulates a classic parallel port, but in this FAQ asking
whether this makes a good general I/O device:
http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund%20um%20den%20PC/USB2LPT/faq#DIY

the vendor admits the driver is not very stable, and only works with
Windows.

He actually recommends the serial port ("USB->Serial adapters work
seamlessly") if you only need 3 output lines. I assume that means you
can latch states onto those lines, even when using a USB adapter.

(The USB parallel port adapter problems wasn't a big surprise to me, as
I'd read countless reports that USB serial adapters were incompatible
with things like device programmers, or IR transmitters. But the
explanation there seemed to be that the USB adapter made the interface
slow, or otherwise messed with the timing. I figured the problems with a
parallel port adapter would be of the same nature, and timing was far
from critical for my application.)

This FAQ also has a few entries on the PL2305 chip:
http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund%20um%20den%20PC/USB2LPT/faq#PL2305

  Those converters emulate extern USB printers according to extern USB
  device class code 7. The protocol used in printer class USB devices
  doesn't allow to set some printer port pins; that protocol doesn't
  know a parallel port at all. ... You can use such a device only if
  your external device is capable of EPP transfer, and you have to adapt
  your software. Most external devices need direct pin control.

And another question discussing whether the PL2305 chip could be
reprogrammed (no) or had some undocumented interface that allows
pin-level control (not likely).

I get why Prolific Technology provided the interface they did. It merely
does what is necessary to support the USB device class for printers. But
it seems rather short sighted on the part of both the USB standards
committee and the chip vendor not to support a more generic parallel
port interface as well. Certainly they must have been aware that the
parallel port was used for numerous other peripherals besides printers.
(You could argue that things like Zip drives, tape drives, and scanners
that use the parallel port were all but obsolete when USB rolled around,
but you could say the same for printers that still used a parallel
interface. It would have been near zero incremental cost to at least
support the functionality in the hardware (PL2305 firmware).)

According to:
http://cholla.mmto.org/computers/linux/usb/usbpar.html

The Lucent USS720 chip supported a "register mode" to emulate a classic
parallel port, but it is out of production. Pretty much everyone uses
the Prolific Technology chip in their adapters now.

So a useless detour, but now I understand why USB parallel port adapters
are really printer adapters and not parallel ports.

The additional latch circuitry is actually pretty minor, so they still
could be useful for hardware hacking, but more than I want to bother
with for my project.

Fortunately my target hardware has a real parallel port (and a
/dev/parport0), so I can avoid that complication.

Although now I'm tempted to take back my USB parallel adapter and trade
it for the similarly priced USB serial adapter.

 -Tom