CS452 - Real-Time Programming - Fall 2011

Lecture 16 - UART Interrupts

Public Service Annoucements

1. Due date of kernel 4 (Friday, 28 October)
2. Saturday November 5, 11.00 to 13.00. Open house for high school students.

Serial I/O

See pdf.

What you need to think about

1. FIFOs
   • Enable bit in Command/Status Register
2. Bus structure
3. Interrupts
   • Programmed I/O: no FIFO
   • Batched I/O: FIFO
4. Flow control

FIFO

Why do FIFOs exist in UARTS?

To use the FIFO effectively you must be able to turn off the transmitter & receiver independently.

But look at UARTE in UARTxCtrl

• UART Enable.
• If this bit is set to 1, the UART is enabled.
  • Data transmission and reception occurs for UART signals.
• If this bit is set to 0, the UART is disabled.
  • Transmission from the FIFO is turned off,
  • but so is reception, so you may miss incoming data you want.

Bus Structure

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

• CPU clocked by CPU clock
• System buses clocked by several different clocks
• UART clocked by its own clock
• The clocks were not suitably synchronized

Why doesn't anybody care?

• UARTs are used at the beginning of the development process
• Once other I/O (ethernet, USB, etc.) is working, UARTs are no longer used, except by the boot loader

Interrupts

Five interrupts in the device

These interrupts are separately enabled and disabled.

1. Transmit
   • FIFO enabled
     • Asserted when transmit FIFO is less than half full.
     • Cleared when transmit FIFO is more than half full.
   • FIFO disabled
     • Asserted when holding register is empty
     • Cleared on write to the holding register
   • Not conditioned by enable.
2. Receive
   • FIFO enabled
     • Asserted when receive FIFO is half full
     • Cleared when receive FIFO is read to less than half full.
   • FIFO disabled
     • Asserted when receive buffer is full
     • Cleared when receive buffer is read
3. Modem status
   • Asserted when hardware flow control bits change
   • Cleared when the modem status register is written
4. Receive timeout
   • Asserted when receive FIFO is not empty and 32 bit periods pass with no new data
   • Cleared when all data has been read from FIFO
5. Combined
   • OR of the four above interrupts
   • Asserted when at least one of the above interrupts is asserted
   • Cleared when all the above interrupts are not asserted.

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

• Base the state machine on bits in the status registers

Make a separate state machine for flow control

Implementation without FIFO, without Flow Control

Receive Interrupt

Kernel

1. Check for EVENT_BLOCKED Notifier
2. Read byte from UART
   • Interrupt automatically cleared
3. Ready Notifier and return byte

Transmit

There is a transmit buffer (probably circular)

Interrupt

Kernel

1. Check for EVENT_BLOCKED Notifier
2. Ready Notifier

Notifier

1. Send to server for byte
2. Write byte to UART

Server

1. If no byte available, then
   • wait for Client to do Putc( )
2. Reply byte

Client Putc

Server

1. If Notifier waiting
   • Reply byte to Notifier

   else

   • Add byte to buffer
2. Reply `done' to Client

Implementation without FIFO, with Flow Control

Receive

Same as above.

Transmit

There is a transmit buffer and a CTS state variable

Transmit Interrupt

Kernel

1. Check for EVENT_BLOCKED Notifier
2. Ready Notifier

Notifier

1. Send to server for byte
2. Write byte to UART

Server

1. If buffer empty
   • Wait for Putc
2. If !CTS
   • Add byte to buffer

   else

   • Reply byte to Notifier

Client Putc

Server

1. If Notifier waiting && CTS
   • Reply byte to Notifier

   else

   • Add byte to buffer

CTS Interrupt

Kernel

1. Check for EVENT_BLOCKED CTSNotifier
2. Turn off interrupt in UART
3. Ready CTSNotifier

CTSNotifier

1. Send CTS toggle message to Server

Server

1. Reply to CTSNotifier
2. Toggle CTS
3. Read UART modem status
4. while( CTS != UART modem status CTS ) Read UART modem status
5. If Notifier waiting && buffer not empty
   • Reply byte to Notifier

Debugging Real-time Programs

The most common set of debugging tools used by experienced programmers is the oldest: printf, grep & stack trace.

• The power of these tools is greatly enhanced by strong conventions in code formatting.

Debugging real-time programs, at its base, is just the same as any other debugging, and just the same as empirical science.

1. Gather data.
2. Create a model that explains the data
3. Test the model
4. If the model is not correct, go to 1.
5. Remember that the model is ALWAYS provisional: data collected later may invalidate it, no matter how much data has confirmed it.

But real-time programs are harder to debug. Very few programs are entirely free of critical races, which are the worst type of bug, lurking for weeks months or years in seemingly correct code, the appearing when innocuous, unconnected changes occur.

RedBoot

The memory contents are not wiped by reset. Some of the most difficult errors can be detected only by using the contents of memory after a reset.

On some types of exceptions RedBoot will attempt to connect with gdb. In such cases it writes a bunch of gibberish on the bottom of the monitor screen. Among that gibberish is the address of the instruction that caused the exception. Using the load map generated by the linker you can find

• the function that your application was running when the exception occurred, and
• the assembly language instruction where the exception occurred.

It is usually pretty easy to figure out which line of C source was responsible for the instruction.

Stack Trace

In single-threaded programs this is often the most useful tool.

• Anything that terminates execution abnormally prints the set of active stack frames
• Minimal version
  • name of calling function
  • line number of call
• Extreme version
  • values of arguments
  • values of local variables

What is the equivalent of a stack trace in a real-time multi-tasking environment?

• Most would say it is the set of tasks, and the run state of each.
• That information is available starting at the set of task descriptors, but how do you get it in an understandable way?

Breakpoint

What does it do?

• snapshot of the system
  • This means that computation, including respose to interrupts, must stop, or it isn't a snapshot.
• provides interactive tools for examining kernel data structures, such as
  • task descriptors
  • lists and queues
  • stacks, including the program counter and local variables, of individual tasks
• restart system immediately afterwards
  • If you want to continue where processing stopped you must make certain that all state is saved when you enter Beakpoint and restored when you leave it. What about pending interrupts? You can't stop the entire universe!
  • Otherwise you can re-enter RedBoot.

How do you get it started?

• function call, which you insert in your code when compiling.
  • The easiest and fastest form to implement.
  • Having the call as part of ASSERT is common.
  • Has to exit to RedBoot. (Jump to x00.)
• system call instead of function call, which respects the kernel/user distinction.
• an exception triggered externally
  • at initialization
    1. Set up the system so that the external event will generate an exception
    2. E.g. attach a button to PDIO on the third connector, set up ICU.
  • at run-time
    1. Trigger the interrupt
    2. Switch to Breakpoint in the event handler
    3. Either exit to RedBoot,
    4. Or clean up pending interrupts and resume execution.

Breakpoint is a special case of a particular sort of tool that is very common.

• condition occurs => information is made available
• breakpoint provides the information interactively (`interactively' = `on the time scale of the user')
  • it can stop the system completely. How?
  • but it has limited ability to stop the real world
    • i.e., it hides some bugs

Getting information closer to real-time.

Return to:

• Bill Cowan's Fall 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page