CS452 - Real-Time Programming - Spring 2017

Lecture 14 - Notifier/Server, UART Interrupts

Public Service Annoucements

  1. Due date for kernel4: 12 June, 2017.
  2. Performance measurements of SRR.

Serial I/O

A UART is not an elegant device. Its design reflects hardware and software trade-offs that existed in the 1960s and 1970s. See pdf.

FIFO

Why do FIFOs exist in UARTS? An interesting story that recurs over and over again as technology advances.

The Amusing 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 to separate the two writes by 55 NOPs.'

Why does this occur?

Why doesn't anybody care?

Serial I/O 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

Registers of the UART

Offset Register Function
0x00 data Write: data to transmit.
Read: received data.
0x04 Interrupt enable
0x08 Status/control Read: interrupts asserted.
Write: FIFO control.
0x0c Line control
0x10 Modem control
0x14 Line status
0x18 Modem status.
0x1c Scratch.

Three inputs to the PIC

  1. Transmit
  2. Receive
  3. Combined

Easy way to use interrupts

Enable only combined; read UART register to decide which interrupt(s) are asserted.

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


Implementation of Serial I/O

Assume.

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.

Timing Inconsistencies

CTS timing.

Terminal Control Code Timing


Return to: