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 [email protected] http://lists.blu.org/mailman/listinfo/hardwarehacking
