Bit Banging Through A USB Parallel Port Adapter

If you’ve ever looked into low-level parallel port access you may have learned that it only works with actual parallel port hardware, and not with USB parallel port adapters. But here’s a solution that will change your thinking. It borrows from the way printers communicate to allow USB to parallel port bit banging without a microcontroller (dead link, try Internet Archive).

Sure, adding a microcontroller would make this dead simple. All you need to do is program the chip to emulate the printer’s end of the communications scheme. But that’s not the approach taken here. Instead the USB to RS232 (serial) converter also pictured above is used as a reset signal. The strobe pin on the parallel port drives an inverter which triggers a thyristor connected to the busy pin. Thyristors are bistable switches so this solution alone will never clear the busy pin. That’s where the serial connection comes into play. By alternating the data transmitted from the computer between the bit-bang values sent to LP0 and 0xF0 sent to the serial connector the eight parallel data bits become fully addressable. See the project in action in the clip after the break.

25 thoughts on “Bit Banging Through A USB Parallel Port Adapter

  1. No need for the use of serial adapter, a 555 configured as a single shot would do the job. The 555 beeing trigged by the strobe pulse would generate the busy signal of any disired length.

      1. +1
        It would be cool if commercial adapters could be used this way. Not sure if i/o pins are tied directly to the FTDI, should look at the datasheet, but it’s probably like that.

    1. I am not entirely sure what the issue is, but some people have claimed that the FTDI bit bang mode is broken in the 232R series parts. Apparently the issue is fixed in their new X series parts, which IMO are better all around, not to mention half the price.

  2. If you use an MCU, you can emulate the whole parallel port if you like, but you must develop the hardware and firmware for it (and drivers on top of it). If you have to do that, you might as well go with the FTDI chip or the like.

    If you elect to just emulate a printer with an MCU, you still must develop the hardware and firmware for it.
    There’s also the little issue of “how now to tell the MCU to hold the current byte and/or get the next byte in a user-programmable way from the host?”. There still needs to be “something” to govern the flow of data.
    Now, if you want to strobe the data by some mechanical means, a physical button works. Or, if you want to read out the data at a fixed rate, the 555 works as well. But to have the host do the flow control, you need something that can generate a pulse at a user-specified time. RS232 ports aren’t the only thing, but they do the job.

    And finally, USB serial/parallel ports need no programming at all. They can be controlled by shell scripts. And they’re really cheap. :-)

    1. USB parallel ports work differently than the parallel port on your motherboard. On a traditional parallel port you just open port 0x378, outb a byte, and it shows up on the lines until you outb another byte. It’s so simple you’d never think they could get the implementation wrong for USB parallel ports, but they did. USB parallel ports cannot be accessed this way at all. There’s no API for it, only printer spooling. My understanding is it had to do with the poorly written Windows Printer API which (purposely?) left out all low-level access capabilities. The hardware was designed around that spec and anyone who used their usb-parallel port for anything other than printing was left out in the cold. Your parallel zip drive, parallel scanner, parallel avr programmer, laplink cable, and so on became worthless. I suspect it was done to encourage the sales of usb-based scanners, drives, transfer cables, and other devices and less for any technical reason.

  3. I’ve got an old parallel port jtag adapter…

    I assume to run applications designed to work with hardware connected on the parallel port, you’d also have to have some kind of low level driver to intercept those legacy calls to read/write 0x378 (aka _inp/_outp) and route them out to an i/o expander (db25 emulator).

    There was a nice article by Dr. Dobbs a while back on this..
    http://www.drdobbs.com/184409876;jsessionid=PANHIXEVBZNJPQE1GHOSKH4ATMY32JVN?pgno=3 ,
    http://www.armory.com/~rstevew/Public/LPT/
    http://hem.passagen.se/tomasf/UserPort/

    1. USB LPT (at least) adapters do not emulate the port. Usually the package states, loud an clear, “No IRQ, no other resources required”. This actually is the only indication because a true LPT *must* allocate a single resource under IRQs, and a few resources under Ports. If I insert my CardExpress LPT adapter, only “USB Printing Support” appears in Device Manager and nothing more.

  4. Finally there is hope that I’ll be able to use that goddamned CardExpress LPT adapter. Unfortunately, this newer interface, unlike PCMCIA, contains USB 2.0 and so manufacturers can profit by that hugely. (Back in times of PCMCIA vs. USB serial adapters, only the former were true COM ports, providing fast polling etc.)

    But, what equivalent device name is used under Windows? No /dev/usb/lp0 out there :(

  5. Excellent solution pcf11, now can you tell him where to get a phone with a PCI slot? ;-)

    Took me a while to figure out what the heck he was doing, not real clear from the HAD blurb. Need to absorb some of this, might help me out in a week or two, I’ve got a nasty idea that I’m going to have to bit bang a USBRS232 adapter to make something work.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.