CS452 - Real-Time Programming - Winter 2016

Lecture 14 - Notifier/Server, UART Interrupts

Public Service Annoucements

  1. Due date for kernel3: 8 February, 2016.
  2. Results of performance measurement

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?

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 the RcvRdy/XmitRdy or the ORd interrupt(s) in the UART.
  2. Enable whichever interrupt(s) you plan to use in the 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 a byte received 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
Answer. You could manipulate the interrupts while handling AwaitEvent in the kernel.

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

Conjunction detection and buffering could just as easily be in the Notifier. Why is it not a good idea?

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

There is also the CTS "bug" to copnsider.

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 should we handle a terminal?


  1. Line editing

Echo -- Either


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: