CD1865 Datasheet, PDF (60/150 Pages) Intel Corporation – Intelligent Eight-Channel Communications Controller

CD1865 — Intelligent Eight-Channel Communications Controller
7.1.3
7.1.4
FIFO Timer Operations
The CD1865 uses the Receive FIFO Timer for two purposes. The first is to avoid ‘stuck’ (or
‘stale’) data in the FIFO caused by not receiving enough characters to trip the threshold, which
causes a service request to be issued. The second is to signal the host that there has been a relatively
long pause in received data. It is useful for the host to know that ‘no data has arrived lately’ when
managing relatively large I/O buffers. This event flushes the buffer up to the host for processing.
To avoid ‘stuck’ data, each time the CD1865 moves a character into a channel’s Receive FIFO, it
sets the channel’s Receive FIFO Timer to the value contained in the channel’s Receive Time-out
Period register (RTPR). If the timer expires before new data arrives, a Receive Good Data sub-type
service request is asserted for the channel if the Receive Data Enable bit in the is set.
The other receive timer option is to generate a service request for the first Receive Data Time-out
following the transfer of all data from the channel to the host. This is called the No New Data
Time-out (NNDT). This service request is a Receive Exception sub-type with a status type of
‘Time-out Exception’. There is no data character associated with the Time-out Exception status.
This option can be enabled or disabled by controlling the NNDT bit in the .
If enough data arrives to fill the Receive FIFO to the level set by the RxTh bits in COR3, or if a
special character arrives in the Receive FIFO and the RxSC bit of is set, the channel asserts the
Receive Data Service Request without waiting for the timer to expire.
If the timer times-out and the FIFO is not empty, the ‘stale data’ condition has occurred, and the
device posts a Receive Good Data Interrupt. If the timer times-out and there is no data, two
conditions are checked. First, a test is made to see if the feature is enabled, if it is true, then another
flag is tested to make sure this is the first time the condition has occurred. If this is true, a Receive
Exception Service Request is posted. (The NNDT internal flag is armed when the FIFO is
emptied).
Receive Service Requests
The Receive Service Request is unique as it has two sub-types; that is, it is capable of returning one
of two different vectors during a service request acknowledge cycle. The two sub-types are
Receive Good Data and Receive Exception. The reason there are two types within one category of
service request is because while Good Data and Exceptions require different handling, they are
both of equal priority and need to be serviced in the order they were received. Suppose, for
example, two good characters are received, then an erroneous character, then another good
character, then there must be a service request for the first 2 bytes of Good Data, then for the
Exception, and then for more Good Data. If Exception Service Requests were at a different level,
the erroneous character would be processed either before or after the Good Data, and not in normal
sequence. Receiver Service Requests are invoked under several conditions.
Conditions that cause a Receive Good Data Service Request are:
• Receive FIFO threshold reached or exceeded
• Receive FIFO time-out — interval between character receptions exceeds time-out value
Conditions that cause a Receive Exception Service Request are:
• Receive erroneous data (parity error)
• Framing error (No Stop bit)
• No data received time-out (optional)
60
Datasheet