Interfacing

Parallel Port

The parallel port got its start as a straightforward mechanism that allowed the CPU to communicate with a printer. The CPU could poll a status bit to see if the printer was ready to accept a character, could write a byte to an output port that was wired to the printer, could set a bit to tell the printer the data was valid, and could poll another status bit to see if the printer had acknowledged receipt of the data byte.

Of course, things changed. Printers today have more processing power than the early PCs. CPUs went from simple, megahertz, byte-wide machines to screaming, multi-gigahertz, cached, pipelined 32~64 bit-wide machines. The parallel port was enhanced and extended. The reality, however, is that the parallel port hasn't kept up with the advances personal computers in general have enjoyed.

The parallel port is a legacy port. This is truly sad because the parallel port is quite easy to interface to, is quite fast, and up until recently it wasn't too difficult to write code for. The parallel port is still a viable I/O path, but be aware that using it may eventually leave you high and dry when some random OS update declines to support it.

Peripherals have left the parallel port behind, depending instead upon USB. Most PCs no longer have parallel ports. Those that do seem to provide only a header on the mother board. If you want to use the parallel port you have to purchase a cable/connector assembly to route the port to a port connector.

Software issues have moved the same direction. It used to be you could use INPORTB() and OUTPORTB() to read and write the port's registers directly. That doesn't quite happen with the newer versions of Windows, you actually talk to a virtual machine rather than hardware. The ability to directly touch such registers is limited to kernel mode device drivers as Microsoft attempts to build increasingly robust operating systems. When support for these ports is withdrawn totally, you quite possibly will have to write your own driver.

Nonetheless, information on the parallel port remains available, and there's even some nice third party software. And, if the parallel port IS totally diss-ed, well..., the parallel port into your simpit then becomes an easy target for a USB interface adapter. (Either buy one or build something like the project described in "USB Parallel Port" by Jan van de Kamer in the February 2003 issue of Circuit Cellar.)

If you do decide to give the parallel port a try, a good way to start is with a visit to Beyond Logic. This site has a tremendous amount of information on interfacing in general and parallel ports in particular. Craig Peacock has written a series of excellent articles detailing the standard, enhanced, and extended capabilities parallel ports. You might also take a look at the book Parallel Port Complete by Jan Axelson. If you need to get into the nitty gritty of Windows device drivers, check out Writing Windows WDM Device Drivers by Chris Cant, and The Windows 2000 Device Driver Book By Art Baker and Jerry Lozano.

Actually, Windows does apparently still provide at least some support for accessing the parallel port. In Win 32 System Services, 3rd edition, authors Marshall Brain and Ron Reeves indicate that the communications APIs support the parallel port (LPT) as well as the serial (COM) ports. Sadly, the book's numerous coding examples all focus on the serial port and there is no detail on the device control blocks or IO control for the parallel port.

There had been several untilties ("IO.DLL", PortIO", and "TVICHW32") that allowed programming access to the parallel port without the need for spsecial device driver programming. These appear to be gone.

Zeal SoftStudio apparently still offers NTPort Library that allows real time direct access to PC I/O ports, including the parallel port. It functions under Windows NT/2000/XP. NTPort appears to be receiving frequent support.

A final point; the parallel port is a byte-wide digital interface. Technically, there are a few status bits that can be pressed into general I/O duty, but the point is that you've fundamentally got an eight bit pipe. If you intend to do more than handle eight lights or switches, or if you are contemplating analog I/O, you will need to develop some additional logic.