XR88C681
80
Rev. 2.11
Figure 42 shows two DUART devices, a “Receiving
Device” and a “Transmitting Device”. These devices are
labeled such because of their role in this example transfer
of data between them. This example is going to ignore, for
the time being, the fact that the “Receiving Device” has a
transmitter and that the “Transmitting Device” has a
receiver. Further, this example, is using Channel A of the
“Receiving Device” and Channel B of the “Transmitting
Device”.
The example starts with the assumption that the
“Receiving Device” has been programmed such that
MR1A[7] = 1. According to
Section G.3, this results in
programming the “Receiving Device” for Receiver RTS
Control. Additionally, the “Transmitting Device” has been
programmed such that MR2B[4] = 1. According to
Section G.3, the Transmitter of Channel B of the
“Transmitting Device” has now been programmed to be
under -CTSB input control.
In this example, the
“Receiving Device” controls the -RTSA output signal.
This output signal is fed directly into the -CTSB input of the
Transmitting Device.
If RHRA of the “Receiving Device” is full (as depicted by
the FFULLA output being at a logic “high”), -RTSA will
automatically be negated by virtue of the Receiver
Controlled RTS features. Consequently, the Channel B
Transmitter of the “Transmitting Device” will have its
-CTSB input negated and will not be permitted to transmit
any data to RXDA of the “Receiving Device”.
If the CPU reads (or “pops”) the RHRA of the Receiving
Device, RHRA will no longer be full, and the FFULLA
indicator will toggle false. In this case, the FFULLA
indicator is connected to some input port of the CPU. In
response to the FFULLA toggling false, the CPU would
interpret this “negative-edge” of FFULLA as an Interrupt
Request. The CPU would service this “Interrupt” by
“writing” [D7,...,D0] = [0, 0, 0, 0, 0, 0, 0, 1] to DUART
address 0E16. This action executes the “SET OUTPUT
PORT COMMAND” and causes OPR[0] to toggle “high”
and Output Port pin OP0 (or -RTSA) to toggle “l(fā)ow”.
Consequently, -RTSA is now asserted.
With the -RTSA output of the “Receiving Device” being
asserted the -CTSA input of the “Transmitting Device” is
now asserted, as well and data transmission from the
“Transmitting Device” to the “Receiving Device” is now
permitted.
Figure 42 shows the RXDA input receiving data after
-RTSA has been asserted. However, in this example, this
newly received character now causes RHRA of the
“Receiving Device” to be full. The FFULLA indicator
status is now asserted and RTSA (of the “Receiving
Device”) is now automatically negated via the Receiver
control over the RTS signal. Therefore, transmission
from Channel B of the Transmitting Device is, once again,
inhibited.
Figure 43 presents a flow diagram illustrating an
algorithm that could be used in implementing the
Receiver-Controlled RTS/CTS Handshaking Mode.