CD1865 datasheet(60/150 Pages) INTEL

60 / 150 page

CD1865 — Intelligent Eight-Channel Communications Controller

Datasheet

7.1.3

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).

7.1.4

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)

CD1865 Datasheet(PDF) 60 Page - Intel Corporation

CD1865 Datasheet(HTML) 60 Page - Intel Corporation

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ...More

Datasheet Download

Link URL