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

[Mark Woodward]

I've been following this thread for a while and I'm confused.....

I originally thought you wanted to drive a relay from a parallel port 
and I'm reading that you have a USB parallel printer interface, which 
you have seen is not the same thing. Let's put the engineering caps on!

Well, first, do you still need/want to do this?
What I/O ports do you have on your system?
(Did you look inside the box at the motherboard for a DIP header for a 
parallel port? Some have it but don't bring it out on the case. Ho about 
COM1 or COM2 port?)


ll you need is one TTL or digital signal you can control. Hell, you 
could probably even use the PC speaker output, that's all handled by 
sound cards these days.

Short of that, I wouldn't mess with anything USB unless you go Arduino. 
It costs about as much or less than all the other things you'd try, and 
it is far more flexible.


On 11/17/2012 10:56 PM, Tom Metro wrote:
> 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
> _______________________________________________
> Hardwarehacking mailing list
> Hardwarehacking at blu.org
> http://lists.blu.org/mailman/listinfo/hardwarehacking