Zilog Z16C30 User Manual

Page 127

6-8

Z16C30 USC

SER

ANUAL

UM97USC0100

ILOG

6.3.1 Programming the DMA Request Levels

(Continued)

Code that writes or reads a DMA Request threshold must
ensure that no interrupts will occur between the time it
writes the “Select xICRHi=REQ Level” command to the
TCSR or RCSR, and when it writes or reads the value in the
TICR or RICR, if such interrupts can lead to other code
writing a different Select command (for TSA data, the FIFO

Fill Level, or interrupt threshold) to the same Command/
Status Register.

Note that a Purge Tx FIFO (or Purge Rx and Tx FIFO)
command can make a channel immediately assert /TxREQ.

6.5 SEPARATING RECEIVED FRAMES IN MEMORY

In some block-oriented communications protocols, soft-
ware needs to separate received frames or messages so
that there is one and only one in each buffer area in
memory. Since the only signals between the USC and an
external DMA controller are REQ and ACK, there’s no way
for the USC to tell the DMAC about frame/message bound-
aries. Therefore there’s no way for the DMA transfer pro-
cess to automatically separate frames/messages in memory
by hardware means, and if such separation is to be done
it must be by means of software intervention between
frames.

As described in an earlier section of this chapter, a USC
Receiver asserts the /RxREQ pin when it places a charac-
ter with end of frame/message (RxBound) status in the
RxFIFO, regardless of the FIFO fill level. This promotes
separation of received frames/ messages in memory.

The channel then keeps /RxREQ asserted at least until the
DMA channel moves the RxBound character from the
RxFIFO to memory, at which time the channel sets the

RxBound status bit (RCSR4). If the Receive Status interrupt
on RxBound is armed and enabled, software can respond
to the resultant interrupt by reprogramming the DMA
channel for the next memory buffer and restarting it to store
the next frame there.

However, this feature is not in itself a complete solution
because the USC may go on to store the first few charac-
ters of the next frame at the end of the preceding frame’s
memory buffer, before software can reprogram the DMA
controller for the next buffer.

The answer to this problem is to use the Wait4RxTrig bit
(CCR5) that’s described near the end of Chapter 5. When
this bit is set to 1, the USC channel negates /RxREQ as it
moves the RxBound character to memory or completes
storing the Receive Status Block. Software can then re-
spond to the Receive Status interrupt, reprogram the DMA
channel for the next frame, and finally write the “Trigger Rx
DMA” command to the RTCmd field (CCAR15-11) to allow
the channel to assert /RxREQ again.

6.4 DMA ACKNOWLEDGE SIGNALS

/TxACK. If the /WAIT//RDY pin is configured for the Ready
(Data Transfer Acknowledge) function as described in
Chapter 2, the USC channel drives /WAIT//RDY low after
either /TxACK or /RxACK goes low. Note that, in a system
in which the DMA controller requires a Ready or Data
Transfer Acknowledge signal, external logic will probably
want to condition and combine /WAIT//RDY from the USC
and the corresponding signal from the memory, to pro-
duce the signal for the DMA controller.

Each channel of the USC has a /TxACK and an /RxACK pin.
In modes other than flyby DMA operation, these pins can
be used as outputs or as polled inputs, as described in
Chapter 3. For flyby DMA applications, connect these pins
to the acknowledge outputs of the DMA controller, and
program the RxAMode and TxAMode fields of the Hard-
ware Configuration Register (HCR3-2 and HCR7-6) with
01. The 01 value makes the USC route the signals from
these pins to the DMA Acknowledge inputs of the Receiver
and Transmitter.

The USC channel provides data on the AD lines within a
specified time after /RxACK goes low. For Transmit DMA
cycles, data must be valid on the AD lines for specified
setup and hold times around each trailing/rising edge on

UM009402-0201