CD1284 Datasheet, PDF (36/176 Pages) Intel Corporation – IEEE 1284-Compatible Parallel Interface Controller with Two High-Speed Asynchronous Serial Ports

CD1284 — IEEE 1284-Compatible Parallel Interface Controller
5.3.1
5.3.2
At the completion of the acknowledge procedure, the CD1284 must be taken out of the
acknowledge context by informing it that the procedure is complete. This restores the original
internal state before the context change. This operation occurs after the CPU performs a ‘dummy’
write to the EOSRR.
Several registers within the serial channel portion of the CD1284 can only be accessed when the
context switch has been made. These are the Virtual registers. For example, the CPU cannot place
data directly in the serial transmit FIFO at an arbitrary time. It must wait for a transmit service
request indicating that the FIFO is empty, then acknowledge it. Once the acknowledge procedure
begins, the transmit FIFO is available for loading.
The CD1284 makes requests for service when an enabled need exists. The two basic ways that the
CPU can be made aware of these service requests is through hardware (interrupt) or software
(polling internal CD1284 registers). Which method is dependent on the hardware/software design
of the system; the CD1284 functions well in either environment. The following section discusses
the trade-offs of either basic method and how to combine the two for maximum performance.
Interrupts
The term interrupt is a generalized description of the method where the CD1284 gains the attention
of the CPU. Interrupt is used interchangeably with ‘service request’ as the two are the same
function. Interrupt often describes an unconditional response on the part of the CPU. Whether or
not this is the case, the source is still the same — a service request from the CD1284. Hardware
signals generated by the CD1284 (SVCREQR*, SVCREQT*, and SVCREQM*) can be connected
to the CPU interrupt input to start an interrupt service routine. The service routine can then begin
servicing the request from the CD1284 by starting an acknowledge sequence.
The SVCREQ* outputs can be connected to the interrupt circuitry individually using three unique
interrupt-level inputs or they can be logically OR’ed together (not wire-OR’ed) into a single
interrupt and applied to one interrupt-level input. In the latter case, the CPU can examine the
SVRR to determine which service requests are active. The method (single or multiple interrupts)
chosen by the designer is dependent on the system requirements and hardware and/or board-space
limitations. The CD1284 has no restrictions. It is likely that interrupt latency is slightly shorter with
the first method since the individual interrupt levels can cause a software vector directly to the
correct service routine without first checking for the source of the interrupt.
No matter which interrupt method is used, the end result is the same. Once the CPU has recognized
that a service request is active, a service-acknowledge routine must be executed to process the
request. There are two ways to start the acknowledge and force the context switch: by four
hardware input pins or by making specific reads/writes to internal registers.
DMAREQ* as Parallel Interrupt Source
Interrupts are not generated by FIFO threshold conditions; therefore, if the system design requires
data to move through interrupts, connect DMAREQ* directly to a CPU interrupt input or logically
OR it into the same CPU interrupt input as SVCREQP*. If DMAREQ* is used to generate
interrupts, the following are required:
• A 16-bit data interface must be implemented to support 16-bit reads of the DMABUF register.
• The DMA threshold value in the PFTR must be initialized.
• DMAREQ* remains active until the FIFO is nearly empty (Rx) or nearly full (Tx), followed
by the toggling of DMAen if data is moved to/from FIFO through PIO (refer to Section 5.2.4).
36
Datasheet