NAME
ppbus —
Parallel Port Bus system with
GPIO
SYNOPSIS
ppbus* at atppc?
options PPBUS_VERBOSE
options PPBUS_DEBUG
options DEBUG_1284
gpio* at ppbus?
lpt* at ppbus?
plip* at ppbus?
pps* at ppbus?
DESCRIPTION
The
ppbus system provides a uniform, modular, and
architecture-independent system for the implementation of drivers to control
various parallel devices, and to use different parallel port chip sets.
DEVICE DRIVERS
In order to write new drivers or port existing drivers, the
ppbus system provides the following facilities:
- architecture-independent macros or functions to access
parallel ports
- mechanism to allow various devices to share the same
parallel port
- a gpio(4)
interface to access the individual pins
- a user interface named
ppi(4) that allows parallel
port access from outside the kernel without conflicting with kernel-in
drivers.
Developing new drivers
The
ppbus system has been designed to support the development
of standard and non-standard software:
Driver |
Description
It uses standard and non-standard parallel port accesses. |
ppi |
Parallel port interface
for general I/O |
pps |
Pulse per second Timing
Interface |
Porting existing drivers
Another approach to the
ppbus system is to port existing
drivers. Various drivers have already been ported:
Driver |
Description |
lpt |
lpt printer driver |
lp |
plip network interface
driver |
ppbus should let you port any other software even from other
operating systems that provide similar services.
PARALLEL PORT CHIP SETS
Parallel port chip set support is provided by
atppc(4).
The
ppbus system provides functions and macros to request
service from the
ppbus including reads, writes, setting of
parameters, and bus requests/releases.
atppc(4) detects chip set and
capabilities and sets up interrupt handling. It makes methods available for
use to the
ppbus system.
PARALLEL PORT MODEL
The logical parallel port model chosen for the
ppbus system is
the AT parallel port model. Consequently, for the
atppc
implementation of
ppbus, most of the services provided by
ppbus will translate into I/O instructions on actual
registers. However, other parallel port implementations may require more than
one I/O instruction to do a single logical register operation on data, status
and control virtual registers.
Description
The parallel port may operate in the following modes:
- Compatible (Centronics -- the standard parallel port
mode) mode, output byte
- Nibble mode, input 4-bits
- Byte (PS/2) mode, input byte
- Extended Capability Port (ECP) mode, bidirectional
byte
- Enhanced Parallel Port (EPP) mode, bidirectional
byte
Compatible mode
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”.
Nibble mode
The Nibble mode is the most common way to get reverse channel data from a
printer or peripheral. When combined with the standard host to printer mode, a
bidirectional data channel is created. Inputs are accomplished by reading 4 of
the 8 bits of the status register.
Byte mode
In this mode, the data register is used either for outputs and inputs. All
transfers are 8-bits long. Channel direction must be negotiated when doing
IEEE 1248 compliant operations.
Extended Capability Port
mode
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 (not supported in these drivers)
- FIFO's for both the forward and reverse channels
- DMA or programmed I/O for the host register
interface.
Enhanced Parallel Port mode
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 IEEE 1284 compatible part.
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.
Mixed modes
Some manufacturers, like SMC, have implemented chip sets that support mixed
modes. With such chip sets, mode switching is available at any time by
accessing the extended control register. All ECP-capable chip sets can switch
between standard, byte, fast centronics, and ECP modes. Some ECP chip sets
also support switching to EPP mode.
IEEE 1284 1994 Standard
Background
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.
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 IEEE 1284 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 automate. 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 the default, backward-compatible transfer mode. 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. The host must
negotiate to permit the peripheral to complete the transfer. Interrupt lines
may be dedicated to the requesting signals to prevent time consuming polling
methods.
If the host accepts the transfer, it must firstly negotiate the reverse mode and
then start 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.
Implementation
IEEE 1284 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.
IEEE 1284 interacts with the
ppbus system as little as
possible. That means you still have to request the
ppbus
when you want to access it, and of course, release it when finished.
ARCHITECTURE
Chip set, ppbus and device
layers
First, there is the
chip set layer, the lowest of the
ppbus system. It provides chip set abstraction through 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:
- share the parallel port bus among the daisy-chain like
connected devices
- manage devices linked to ppbus
- propose an arch-independent interface to access the
hardware layer.
Finally, the
device layer represents the traditional device
drivers such as
lpt(4) which now
use an abstraction instead of real hardware.
Parallel port mode
management
Operating modes are differentiated at various
ppbus system
layers. There is a difference between a
capability and a
mode. A chip set may have a combination of capabilities, but
at any one time the
ppbus system operates in a single mode.
Nibble mode is a
virtual mode: the actual chip set would be in
standard mode and the driver would change its behavior to drive the right
lines on the parallel port.
Each child device of
ppbus must set its operating mode and
other parameters whenever it requests and gets access to its parent
ppbus.
FEATURES
The boot process
ppbus attachment tries to detect any PnP parallel peripheral
(according to
Plug and Play Parallel Port Devices draft from
(c)1993-4 Microsoft Corporation) then probes and attaches known device
drivers.
During probe, device drivers should request the
ppbus and try
to determine if the right capabilities are present in the system.
Bus request and interrupts
ppbus reservation via a bus request is mandatory not to
corrupt I/O of other devices. For example, when the
lpt(4) device is opened, the bus
will be “allocated” to the device driver and attempts to reserve
the bus for another device will fail until the
lpt(4) driver releases the bus.
Child devices can also register interrupt handlers to be called when a hardware
interrupt occurs. In order to attach a handler, drivers must own the bus.
Drivers should have interrupt handlers that check to see if the device still
owns the bus when they are called and/or ensure that these handlers are
removed whenever the device does not own the bus.
Micro-sequences
Micro-sequences are a general purpose mechanism to allow fast
low-level manipulation of the parallel port. Micro-sequences may be used to do
either standard (in IEEE 1284 modes) or non-standard transfers. The philosophy
of micro-sequences is to avoid the overhead of the
ppbus
layer for a sequence of operations and do most of the job at the chip set
level.
A micro-sequence is an array of opcodes and parameters. Each opcode codes an
operation (opcodes are described in
microseq(9)). Standard I/O
operations are implemented at ppbus level whereas basic I/O operations and
microseq language are coded at adapter level for efficiency.
GPIO interface
Pins 1 through 17 of the parallel port can be controlled through the
gpio(4) interface, pins 18 through
25 are hardwired to ground. Pins 10 through 13 and pin 15 are input pins, the
others are output pins. Some of the pins are inverted by the hardware, the
values read or written are adjusted accordingly. Note that the
gpio(4) interface starts at 0 when
numbering pins.
SEE ALSO
atppc(4),
gpio(4),
lpt(4),
plip(4),
ppi(4),
microseq(9)
HISTORY
The
ppbus system first appeared in
FreeBSD
3.0.
AUTHORS
This manual page is based on the
FreeBSD
ppbus manual page. The information has been updated for the
NetBSD port by Gary Thorpe.
BUGS
The
ppbus framework is still experimental and not enabled by
default yet.