beautypg.com

Zilog Z16C30 User Manual

Page 87

background image

5-20

Z16C30 USC

®

U

SER

'

S

M

ANUAL

UM97USC0100

Z

ILOG

5.14.2 Frame Length Residuals

The Receiver detects and strips inserted zeroes, Flags,
and Aborts before any other processing, and doesn’t
include these bits/sequences in the RxFIFO nor in CRC
calculations. If the Receiver has assembled a partial
character when it detects a Flag or Abort, it stores the
partial character left-justified in an RxFIFO entry. (That is,
in the MSBits of the byte regardless of RxLength.) The
Receiver saves the number of bits received in this last byte
in the

RxResidue

field of the Receive Command/Status

Register (RCSR11-9). RxResidue remains available until
the end of the next received frame. Software can use the
Receive Status Block feature as described in a later
section, to store the RCSR in memory after the frame. This
reduces processing requirements still further.

Conversely, to send a frame that doesn’t contain an inte-
gral number of characters, software must ensure that the
number of bits in the last character of the frame is written
into the

TxResidue

field of the Channel Command/Status

Register (CCSR4-2). This must happen before the Trans-
mitter takes the last character out of the TxFIFO.

Figure 5-8 shows the CCSR. The Transmit Control Block
feature can be used to set the TxResidue value for each
block under DMA control, without the intervention of pro-
cessor software. The active bits of a partial character must
be right-justified, that is, they must be the LSBits of the last
character. If the TxParEnab bit in the Transmit Command/
Status Register (TCSR5) is 1 specifying parity generation,
for a partial character the Transmitter sends the parity bit
after the number of bits specified by TxResidue, while in
other characters the parity bit is the last one of the charac-
ter length specified by TxLength (TMR4-2).

The encoding of RxResidue and TxResidue is as for
RxLength and TxLength: 000 specifies that the last char-
acter contains eight bits, while 001-111 specify 1 to 7 bits
respectively.

5.14.3 Handling a Received Abort

A USC manufactured after June 1993 reports a received
Abort sequence in two different ways. The later section
'Status Handling' will note that a channel sets the Break/
Abort bit in the Receive Command/Status Register (RCSR5)
when it recognizes an Abort sequence. This notification is
not tied to a specific point in the received data stream.

The same section will also note that, if the QAbort bit in the
Receive Mode Register (RMR8) is 1, USCs manufactured
after June 1993 queue Abort conditions through the RxFIFO.
From there, they eventually appear as the Abort/PE bit
(RCSR2) of the last character of the frame — the one that
has RxBound (RCSR4) set to 1. (If QAbort is 0 and parity
checking is enabled, the channel uses this bit in the
RxFIFO and RCSR to indicate Parity Errors.)

With a USC manufactured before June 1993, software can
handle an Abort condition by enabling an interrupt when
one is detected, and at that point forcing the receiver into
Hunt mode for the next frame and ignoring/purging all
received data. Or it can try examining received data (in
memory for a DMA application or in the RxFIFO otherwise).
Both an Abort and a closing Flag will terminate a frame with
“RxBound” status; software can use the CRC error indica-
tion to differentiate Aborts from closing Flags.

With USCs manufactured after June 1993, software can
handle Aborts more efficiently/elegantly by setting QAbort
to 1 and using the Receive Status Block feature to store the
RCSR status in memory for each frame, as described in the
later section ‘Receive Status Blocks.’ Software can then
examine this status word for each “frame”; any one that has
Abort/PE set isn’t a proper frame in that it ended with an
Abort sequence rather than a Flag.

UM009402-0201