CS452 - Real-Time Programming - Spring 2015

Lecture 14 - Notifier/Server, UART Interrupts

Public Service Annoucements

  1. Due date for kernel3: 8 June, 2015
  2. Results of performance measurement

Serial I/O

See pdf.

Implementation of Serial I/O

FIFO is assumed to be turned off; buffers are assumed to be in the server.

The simplest way to handle the interrupts is to turn on only the combined interrupt and then look at the registers of the device.

To identify the current interrupt

Read UARTxIntIDIntClr at 0x800[bc]001c

Providing I/O for the terminal

Initialization

  1. Enable RcvRdy, XmitRdy interrupts in UART.
  2. Enable combined interrupt in ICU

Receiving

Notifier EVT_BL on RcvRdy event

  1. Interrupt occurs, AwaitEvent returns with received byte.
  2. Notifier sends byte to server
  3. Server replies,
  4. Notifier returns to the EVT_BL state
  5. After a while server runs again
  6. Server checks GetQ
  7. If ( ! GetQ_Empty )
  8. Else put byte in RcvQ

When server receives Get request from client

  1. Server checks RcvQ
  2. If ( ! RcvQ_Empty )
  3. Else put client in GetQ
Other possibilities

  1. Read the UART in the Notifier.
  2. Read the UART in the Server.

Transmitting

Transmitting is a little more tricky because two conditions must be met.

  1. Byte available to transmit
  2. Transmit holding register empty

Assume we put conjunction detection in the server

When server receives Put request from client

  1. Is Notifier ready?
  2. If ( Ready ) Reply( notifier, byte ); Reply( client, ... )
  3. Else insert byte in XmitQ; Reply( client, ... )

When server receives Ready request from Notifier

  1. If ( XmitQEmpty ) Mark notifier ready
  2. Else Extract byte from XmitQ; Reply( notifier, byte ); Reply( client )

The Notifier

The procedure described here breaks an abstraction barrier. Is there any other way to do what you want?

  1. Enable XmitRdy interrupt
  2. byte = AwaitEvt( XmitRdy )
  3. Disable XmitRdy interrupt in UART
  4. Send( server, ready, byte )
  5. Write byte on UART
  6. Go to top

This procedure assumes that the transmit bit never resets once it is set. Is this true?

Other Ideas

  1. Conjunction detection and buffer in the Notifier
  2. Write the UART in the Server
  3. Disable and enable Xmit interrupt in the kernel

Providing I/O for the train controller

Receiving

As Above

Transmitting

For transmitting three conditions must be set

  1. Byte available to transmit
  2. Holding register empty
  3. CTS asserted

Task Structure

We are supposed to support

int Get( int port )

and

int Put( int port, char c )

These are wrappers for sends to one or more serial servers.

You will probably want something more complex in addition to Get and Put.

How many servers and notifiers?

one server two servers four servers
one

notifier

likely queue

congestion in

server

likely queue

congestion

in notifer

two

notifiers

one per channel?

one per direction?

how should they

be paired?

four

notifiers

certain queue

congestion

in server

likely queue

congestion in

server

best performance,

most tasks

How should we handle a terminal?

Issues

  1. Line editing

Echo -- Either

Or

Many other issues come up below as we consider possible task structures.

How ahould we handle the train controller

Bandwidth of communication with the train controller will probably be the limiting factor in your trains project.


Return to: