CD1284 Datasheet, PDF (97/176 Pages) Intel Corporation – IEEE 1284-Compatible Parallel Interface Controller with Two High-Speed Asynchronous Serial Ports

IEEE 1284-Compatible Parallel Interface Controller — CD1284
6.4
6.4.1
least-significant two bits; the main driver software must perform the necessary
functions. As with the receive and transmit routines, the Interrupt register, this
time the MIR, is used to force the CD1284 into the service context. */
service_mdm( )
{
char
save_mir, channel, save_car, mdm_status;
save_mir = inportb(MIR);
*/
channel = save_mir & 0x03;
save_car = inportb(CAR);
outportb(CAR, save_mir);
*/
mdm_status = inportb(MISR);
changed */
outportb(MIR, save_mir & 0x3f)
outportb(CAR, save_car);
return(mdm_status | channel);
}
/* retrieve and save modem interrupt value
/* extract channel number from the MIR*/
/* save CAR for restore */
/* switch CD1284 to service ack. context
/* get status of which modem signals
/* terminate the service ack. sequence */
/* restore CAR */
Hardware-Activated Service Examples
In nearly all respects, the way that the CPU interacts with the CD1284 during hardware-activated
service acknowledge is the same as software-activated methods. The main difference is that the
SVCACK* input signals perform the context switch automatically, relieving that duty from the
CPU. The result is the same: the CAR is set to point to the correct channel and the device is placed
in the proper internal mode to service the request.
When the SVCACK* input is activated, a read cycle is performed. The CD1284 places the contents
of the appropriate Interrupt Vector register (RIVR, TIVR, MIVR) of the channel requesting service
on the data bus. The CPU uses the information provided to determine the type of service and the ID
number of the device being accessed in the case of daisy-chained multiple CD1284s.
At the end of the service routine, the CPU writes a dummy value to the EOSRR. This causes the
switch out of the service acknowledge context and restores the environment to what it was before
the service began. Again, the parallel port service is slightly different and it is shown separately.
The following code fragments show the differences between this type of service acknowledge and
the types shown above for the software-activated context switch. Only the beginning and ending
steps are shown; the code between is very similar to the previous examples. These routines can be
executed as the result of a hardware interrupt or by software polling as in the previous examples.
For the purpose of this discussion, the method of arriving at the proper service routine is not
important.
Serial Receive Service
/* The receive service acknowledge cycle begins by executing a service acknowledge
cycle, which activates the SVCACKR* input. The data obtained as a result of this
‘read’ cycle is the contents of the RIVR register of the channel making the service
request. The service routine decodes the vector in the least significant three bits
to determine if the data is ‘good’ or ‘bad’ (exception). The context switch is done
automatically when the SVCACKR* signal is activated and the CAR does not need to be
loaded. The routine reads the RICR to determine the requesting channel number. If
this is a multiple–CD1284 system using daisy-chaining, the routine extracts the chip
ID from the upper five bits of the RIVR. */
service_rec( )
{
Datasheet
97