Manual Pages  — PPBUS

ppbus – Parallel Port Bus system

SYNOPSIS DESCRIPTION DEVICE DRIVERS Developing new drivers Porting existing drivers PARALLEL PORT CHIPSETS PARALLEL PORT MODEL Description Compatible mode Bidirectional mode Byte mode Extended Capability Port mode Enhanced Parallel Port mode Mixed modes IEEE1284-1994 Standard Background Implementation ARCHITECTURE adapter, ppbus and device layers Parallel modes management FEATURES The boot process Bus allocation and interrupts Microsequences SEE ALSO HISTORY AUTHORS

device ppbus

device vpo

device lpt device plip device ppi device pps device lpbb

The ppbus system provides a uniform, modular and architecture-independent system for the implementation of drivers to control various parallel devices, and to utilize different parallel port chipsets.

The ppbus system has been designed to support the development of standard and non-standard software:

Driver	Description
vpo	VPI0 parallel to Adaptec AIC-7110 SCSI controller driver.It uses standard and non-standard parallel port accesses.
ppi	Parallel port interface for general I/O
pps	Pulse per second Timing Interface
lpbb	Philips official parallel port I2C bit-banging interface

Another approach to the ppbus system is to port existing drivers. Various drivers have already been ported:

Driver	Description
lpt	lpt printer driver
plip	lp parallel network interface driver

ppbus should let you port any other software even from other operating systems that provide similar services.

The logical parallel port model chosen for the ppbus system is the PC's parallel port model. Consequently, for the i386 implementation of ppbus, most of the services provided by ppc are macros for inb() and outb() calls. But, for an other architecture, accesses to one of our logical registers (data, status, control...) may require more than one I/O access.

The parallel port may operate in the following modes:

• compatible mode, also called Centronics mode
• bidirectional 8/4-bits mode, also called NIBBLE mode
• byte mode, also called PS/2 mode
• Extended Capability Port mode, ECP
• Enhanced Parallel Port mode, EPP
• mixed ECP+EPP or ECP+PS/2 modes

This mode defines the protocol used by most PCs to transfer data to a printer. In this mode, data is placed on the port's data lines, the printer status is checked for no errors and that it is not busy, and then a data Strobe is generated by the software to clock the data to the printer.

Many I/O controllers have implemented a mode that uses a FIFO buffer to transfer data with the Compatibility mode protocol. This mode is referred to as "Fast Centronics" or "Parallel Port FIFO mode".

The NIBBLE mode is the most common way to get reverse channel data from a printer or peripheral. Combined with the standard host to printer mode, it provides a complete bidirectional channel.

In this mode, outputs are 8-bits long. Inputs are accomplished by reading 4 of the 8 bits of the status register.

In this mode, the data register is used either for outputs and inputs. Then, any transfer is 8-bits long.

The ECP protocol was proposed as an advanced mode for communication with printer and scanner type peripherals. Like the EPP protocol, ECP mode provides for a high performance bidirectional communication path between the host adapter and the peripheral.

ECP protocol features include:

	Run_Length_Encoding (RLE) data compression for host adapters
	FIFOs for both the forward and reverse channels
	DMA as well as programmed I/O for the host register interface.

The EPP protocol was originally developed as a means to provide a high performance parallel port link that would still be compatible with the standard parallel port.

The EPP mode has two types of cycle: address and data. What makes the difference at hardware level is the strobe of the byte placed on the data lines. Data are strobed with nAutofeed, addresses are strobed with nSelectin signals.

A particularity of the ISA implementation of the EPP protocol is that an EPP cycle fits in an ISA cycle. In this fashion, parallel port peripherals can operate at close to the same performance levels as an equivalent ISA plug-in card.

At software level, you may implement the protocol you wish, using data and address cycles as you want. This is for the IEEE1284 compatible part. Then, peripheral vendors may implement protocol handshake with the following status lines: PError, nFault and Select. Try to know how these lines toggle with your peripheral, allowing the peripheral to request more data, stop the transfer and so on.

At any time, the peripheral may interrupt the host with the nAck signal without disturbing the current transfer.

Some manufacturers, like SMC, have implemented chipsets that support mixed modes. With such chipsets, mode switching is available at any time by accessing the extended control register.

This standard is also named "IEEE Standard Signaling Method for a Bidirectional Parallel Peripheral Interface for Personal Computers". It defines a signaling method for asynchronous, fully interlocked, bidirectional parallel communications between hosts and printers or other peripherals. It also specifies a format for a peripheral identification string and a method of returning this string to the host outside of the bidirectional data stream.

This standard is architecture independent and only specifies dialog handshake at signal level. One should refer to architecture specific documentation in order to manipulate machine dependent registers, mapped memory or other methods to control these signals.

The IEEE1284 protocol is fully oriented with all supported parallel port modes. The computer acts as master and the peripheral as slave.

Any transfer is defined as a finite state automaton. It allows software to properly manage the fully interlocked scheme of the signaling method. The compatible mode is supported "as is" without any negotiation because it is compatible. Any other mode must be firstly negotiated by the host to check it is supported by the peripheral, then to enter one of the forward idle states.

At any time, the slave may want to send data to the host. This is only possible from forward idle states (nibble, byte, ecp...). So, the host must have previously negotiated to permit the peripheral to request transfer. Interrupt lines may be dedicated to the requesting signals to prevent time consuming polling methods.

But peripheral requests are only a hint to the master host. If the host accepts the transfer, it must firstly negotiate the reverse mode and then starts the transfer. At any time during reverse transfer, the host may terminate the transfer or the slave may drive wires to signal that no more data is available.

IEEE1284 Standard support has been implemented at the top of the ppbus system as a set of procedures that perform high level functions like negotiation, termination, transfer in any mode without bothering you with low level characteristics of the standard.

IEEE1284 interacts with the ppbus system as little as possible. That means you still have to request the ppbus when you want to access it, the negotiate function does not do it for you. And of course, release it later.

First, there is the adapter layer, the lowest of the ppbus system. It provides chipset abstraction throw a set of low level functions that maps the logical model to the underlying hardware.

Secondly, there is the ppbus layer that provides functions to:

1. share the parallel port bus among the daisy-chain like connected devices
2. manage devices linked to ppbus
3. propose an arch-independent interface to access the hardware layer.

Finally, the device layer gathers the parallel peripheral device drivers.

We have to differentiate operating modes at various ppbus system layers. Actually, ppbus and adapter operating modes on one hands and for each one, current and available modes are separated.

With this level of abstraction a particular chipset may commute from any native mode to any other mode emulated with extended modes without disturbing upper layers. For example, most chipsets support NIBBLE mode as native and emulated with ECP and/or EPP.

This architecture should support IEEE1284-1994 modes.

ppbus allocation is mandatory not to corrupt I/O of other devices. Another usage of ppbus allocation is to reserve the port and receive incoming interrupts.

High level interrupt handlers are connected to the ppbus system thanks to the newbus BUS_SETUP_INTR() and BUS_TEARDOWN_INTR() functions. But, in order to attach a handler, drivers must own the bus. Consequently, a ppbus request is mandatory in order to call the above functions (see existing drivers for more info). Note that the interrupt handler is automatically released when the ppbus is released.

The ppbus manual page first appeared in FreeBSD 3.0 .

This manual page was written by Nicolas Souchu.