PPBUS(4) | Device Drivers Manual | PPBUS(4) |
ppbus
—
ppbus* at atppc?
options PPBUS_VERBOSE
options PPBUS_DEBUG
options DEBUG_1284
gpio* at ppbus?
lpt* at ppbus?
plip* at ppbus?
pps* at ppbus?
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.
ppbus
system provides the following facilities:
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 |
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.
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.
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.
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”.
ECP protocol features include:
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.
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.
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.
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.
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.
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.
ppbus
system first appeared in
FreeBSD 3.0.
ppbus
manual page. The information has been updated
for the NetBSD port by Gary Thorpe.
ppbus
framework is still experimental and not
enabled by default yet.
August 19, 2009 | NetBSD 9.4 |