Zilog Z16C30 - Manual (Page 79)

5-12
Z16C30 USC ®
U SER ' S M ANUAL
UM97USC0100
Z ILOG
5.9 EXTERNAL SYNC MODE
Software can select this mode only for the Receiver, by
programming the RxMode field of the Channel Mode
Register (CMR3-0) as 0001. This value is not defined for
the TxMode field (CMR11-8).
This is the most primitive synchronous mode. To use it,
software must program the DCDMode field of the Input/
Output Control Register (IOCR13-12) to 01, to specify that
the /DCD pin carries a Sync input. External hardware must
provide a low-active signal on this pin, that controls when
the Receiver should capture data. When the external
hardware establishes synchronization and/or data valid-
ity, it should drive /DCD low. The timing should be such that
the IUSC first samples /DCD low at the rising edge of
RxCLK before the one at which it should capture the first
data bit from RxD. (Typically, RxCLK comes directly from
the /RxC pin in this mode.)
While /DCD stays low the Receiver samples RxD on each
rising edge of RxCLK. Ideally, the external hardware
should negate /DCD such that the channel samples it high
on the rising RxCLK edge after the one on which it samples
the last bit of the last character. But if /DCD goes high while
the Receiver is in the midst of assembling a received
character, it continues on to sample the remaining bits of
the character and place the character in the RxFIFO.
Because of this, it’s OK for /DCD to go high during the last
character, at any time after a hold time after the RxCLK
edge at which the Receiver samples the first bit of the
character.
Software can make the Receiver check a parity bit in each
character as described in the following section 'Parity
Checking'. Besides or instead of character parity, software
can make the Receiver check a CRC code as described in
the 'Cyclic Redundancy Checking' section.
The USC doesn’t use the RxSubMode field (CMR7-4) in
External Sync mode, but Zilog reserves this field for future
enhancements and software should program it as 0000 in
this mode.
5.10 MONOSYNC AND BISYNC MODES
The Binary Synchronous Communications protocol put
forth by the IBM Corporation in the 1960’s is often abbre-
viated as “Bisync”. But we will use the latter term more
generally, to mean a mode of a USC channel in which the
Transmitter sends, and the Receiver searches or “hunts”
for, a Sync pattern composed of two characters totalling 16
bits or less. By contrast, we’ll use the term “Monosync” to
mean a mode in which the Transmitter sends, and the
Receiver matches, a sync pattern of eight bits or less. Use
of Bisync mode with the two sync characters equal repre-
sents a middle ground, having the advantage that the two-
character pattern match by the Receiver is more reliable
and secure than the sync match in Monosync mode.
Software can select these modes for the Transmitter and/
or the Receiver, by programming the value 0100 (for
Monosync) or 0101 (for Bisync) into the TxMode and/or
RxMode fields of the Channel Mode Register (CMR11-8
and CMR3-0).
Software can make the Transmitter calculate and send a
parity bit with each character and can make the Receiver
check such parity bits, as described in the 'Parity Check-
ing' section.
In such character-oriented synchronous modes, blocks of
consecutive characters are called 'messages'. Besides or
instead of character parity, software can make the Trans-
mitter calculate and send a Cyclic Redundancy Check
(CRC) code for each message and can make the Receiver
check a CRC in each message, as described later in
'Cyclic Redundancy Checking'.
On the transmit side , the Transmitter “concludes a mes-
sage” in either of two situations: when it underruns or after
it sends a character marked with “EOF/EOM” status. The
Transmitter underruns when the TxFIFO is empty and the
transmit shift register needs a new character. Software can
mark a character as the last one of a message directly,
using a command in the Transmit Command/Status Reg-
ister (TCSR), or more automatically by using the Transmit
Character Counter as described in a later section.
The MSBit of the TxSubMode field (CMR15) determines
whether the Transmitter sends a CRC when it concludes a
message because of an Underrun condition. The
TxCRCatEnd bit in the Transmit Mode Register (TMR8)
determines whether it does so when it concludes a mes-
sage because of a character marked as End Of Message.
If CMR15 or TMR8 (as applicable) is 1, the Transmitter
sends the CRC code that it has accumulated while send-
ing the message. If CMR15 or TMR8 is 0, it doesn’t send a
CRC code; if there’s any message-level checking, it must
be sent like normal data.
UM009402-0201