Zilog Z16C30 - Manual (Page 106)

5-39
Z16C30 USC ®
U SER ' S M ANUAL Z ILOG
UM97USC0100
The only trouble with the 32-bit RSB option is that software
has to know how long each received frame is, in order to
find the RSB that indicates the length. (This is somewhat
similar to trying to follow a forward-linked-list backward.)
Typically software will need to use the RCC FIFO to keep
track of frame lengths instead of, or in addition to, Receive
Status Blocks.
Figure 5-18 shows the contents of the first word of a
Receive Status Block; they are identical with the contents
of the RCSR with the following exceptions:
1. The channel forces the bits that correspond to
ExitedHunt and IdleRcved in the RCCR to 0. These are
“global” rather than “queued” status bits and must be
handled by software on a more or less real-time basis.
2. On USCs manufactured after June 1993, bit 5 of the
RSB status is a copy of the RCCF Ovflo bit that is
otherwise accessible as CCSR15. (Older USCs al-
ways store this bit as 0.) Because RCCF Ovflo does not
become 1 until an overwritten RCC residual value has
come to the top of the RCC FIFO, a 1 in this bit indicates
that the associated RCC residual value is not valid.
When RCCR Ovflo is 1, if software has an alternative
means of determining the length of the current frame,
such as an embedded length field or fixed-length
frames, it should use this alternative means to process
the frame. Otherwise it must discard the frame as
being unprocessable.
3. The LSBit of the first word of an RSB is a copy of the
LSBit of the RCC at the end of the frame, rather than the
RxAvail bit that’s in the RCCR. This bit is also available
in the RCC FIFO and in the second word of a 32-bit
RSB, but for 16-bit DMA operation it may be handy to
have it here, especially in a 16-bit RSB.
The CRCE/FE bit in an RSB reflects the CRC-correctness
of the frame in 802.3 and HDLC/SDLC modes, but not in
Transparent Bisync mode.
A 10 in RxStatBlk makes the IUSC also store the ending
value of the Receive Character Counter in a second 16-bit
word after the frame status word. This value indicates the
length of the frame.
Figure 5-14 illustrates that USCs manufactured before
June 1993 save this RCC value in a 16-bit latch called
RCHR, that is not directly accessible to software. Unfortu-
nately, this latch does not provide much buffering capacity
when successive short frames are received. Therefore,
newer USCs take the RCC value in a 32-bit RSB from the
four-entry RCC FIFO, which with older USCs was only used
by software. This allows up to four (short) frames to reside
in the RxFIFO simultaneously without loss of information.
To write software that is compatible with both kinds of
devices, either enable 32-bit RSBs or read the RCC FIFO,
BUT NOT BOTH!
5.19.5 Finding the End of a Received Frame
When software or an external Receive DMA controller
reads 16 bits from the RDR, and the Receiver has marked
the oldest character in the RxFIFO with RxBound states,
the channel only takes that one character out of the
RxFIFO. When the Receive DMA controller is doing 16-bit
transfers, software has several ways to figure out whether
the 16 bits preceding a RSB contain one or two characters/
bytes.
The most straightforward way is to compute the length of
the frame or message, by subtracting the ending RCC
value in the RCC FIFO or the second word of the RSB, from
the starting RCC value that the hardware took from RCLR.
(If the starting value was all ones, software can just ones-
complement the ending value.) Assuming the frame or
message started at a 16-bit boundary (an even address),
if the result is odd there’s one character in the 16-bit word
that precedes the RSB, while if it’s even there are two
characters in the word.
A “narrower” version of the same computation is that if bit
0 of the first or second word of the RSB is the same as the
units bit of the starting RCC value that came from RCLR,
then the preceding word contains two characters. If the
two bits are different the word contains only one character.
Still another method applies only when bits 2-1 of the first
word of the RSB, namely Abort/PE and Rx Overrun, are
both 0. (Most “modern” protocols don’t use parity check-
ing anyway.) The usual handling for an Rx Overrun condi-
tion in synchronous modes involves forcing the receiver
into Hunt mode for the start of the next frame or message,
which means that an RSB would never be stored for a
frame that encountered an overrun. When Abort/PE and
RxOver are both zero, if bit 14 of the first word of the RSB
(1stBE) is 1, there is one character in the preceding word,
while if bit 14 is 0 there are two characters in the word.
Figure 5-18 shows the first characters of the next frame
stored right after the RSB. This indicates that the DMA
controller didn’t switch memory buffers between the frames.
UM009402-0201