CS452 - Real-Time Programming - Winter 2015

Lecture 14 - Notifier/Server, UART Interrupts

Public Service Annoucements

  1. Due date for kernel3: 9 February, 2015
  2. Results of performance measurement

Serial I/O

See pdf.

FIFO

Why do FIFOs exist in UARTS?

The Big Blunder

To use the FIFO effectively you must be able to turn off the transmitter & receiver independently. We would like to receive when we are not transmitting.

But look at UARTE in UARTxCtrl

The Little Blunder

`It is assumed that various configuration registers for the UART are not written more than once in quick succession, in order to insure proper synchronization of configuration information across the implementation. Such registers include UART1Ctrl and UART1LinCtrlHigh. ... In between the two writes, at least two UARTCLK periods must occur. Under worst case conditions, at least 55 HCLK periods must separate the two writes. The simplest way to due [sic] this is separate the two writes by 55 NOPs.'

Why does this occur?

Why doesn't anybody care?

Timing Inconsistencies

CTS timing.

Terminal Control Code Timing

Interrupts

Five interrupts in the device

These interrupts are separately enabled and disabled.

  1. Transmit
  2. Receive
  3. Modem status
  4. Receive timeout
  5. Combined

Three inputs to the PIC

  1. Transmit
  2. Receive
  3. Combined

Easy way to use interrupts

Enable only combined; read UART registers to decide what to do.

Think of the receive and transmit parts of the UART as separate state machines


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

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?

Conjunction detection and buffer could just as easily be in the Notifier

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.


Return to: