CS452 - Real-Time Programming - Spring 2016

Lecture 13 - Notifier/Server, UART Interrupts

Public Service Annoucements

  1. Due date for kernel3: 6 June, 2016.
  2. Performance measurements
  3. Due date for k4?

Serial I/O

See pdf.


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 Transmit: write data.
Receive: read 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


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


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


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


As Above


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 )


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


likely queue

congestion in


likely queue


in notifer



one per channel?

one per direction?

how should they

be paired?



certain queue


in server

likely queue

congestion in


best performance,

most tasks

How should we handle a terminal?


  1. Line editing

Echo -- Either


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

Timing Inconsistencies

CTS timing.

Terminal Control Code Timing

Return to: