PPBUS(4) | Device Drivers Manual | PPBUS(4) |
ppbus
— Parallel
Port Bus system with GPIO
ppbus* at atppc?
options PPBUS_VERBOSE
options PPBUS_DEBUG
options DEBUG_1284
gpio* at ppbus?
lpt* at ppbus?
plip* at ppbus?
pps* at ppbus?
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.
In order to write new drivers or port existing drivers, the
ppbus
system provides the following facilities:
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 |
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 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.
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.
The parallel port may operate in the following 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. 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.
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.
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:
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.
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.
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.
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.
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:
ppbus
Finally, the device layer represents the traditional device drivers such as lpt(4) which now use an abstraction instead of real hardware.
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
.
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.
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 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.
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.
The ppbus
system first appeared in
FreeBSD 3.0.
This manual page is based on the FreeBSD
ppbus
manual page. The information has been updated
for the NetBSD port by Gary Thorpe.
The ppbus
framework is still experimental
and not enabled by default yet.
August 19, 2009 | NetBSD 10.99 |