CS452 - Real-Time Programming - Spring 2017

Lecture 12 - AwaitEvent, Clock Server

Pubilc Service Annoucements

  1. Due date for kernel 3: 5 June, 2017.

Context Switches for Interrupts

Difference from Software Interrupts

It is impossible to predict where they occur

Assymmetry between User Task and Kernel

Scratch registers of the user task must be saved.

Scratch registers of the kernel need not be saved.

Four link registers must be put in the correct places.

  1. One to return from interrupt
  2. One allowing the interrupting task to return from the function that was executing when it was interrupted.
  3. One allowing IRQ mode code to return from whatever function it is executing when the interrupt occurs.
  4. One allowing code executing in svc mode to return from whatever function called it.

Helpful Features of the ICU

Because the ICU was designed by programmers it has a few features that are helpful to programmers

  1. Several places where you can read state
  2. Several places where you can block interrupt flow
  3. Trigger hardware interrupt from software


The Hardware in the Trains Lab

32-bit Timer

Base address: 0x80810080

The four registers of the timer.
Offset Function R/W Bits Comments
0x0 Timer3Load R/W 32: <Load/Reload Value>
0x4 Timer3Value R 32:<Current value> Set when Load is written,
even when counting
0x8 Timer3Control R/W 32:the lowest order bits are <CLKSEL>xx<MODE><ENABLE> <CLKSEL>: 0, 2KHz clock; 1, 508KHz
<MODE>: 1, count continuously; 0, count once
<ENABLE>: Clock turned on
No bit for turning interrupts off and on
0xc Timer3Clear W 32: Writing anything clears the interrupt

Interrupt Control Unit (ICU)

The actual device is the ARM PL190, and there are two of them in the SoC. In the Cirrus documentation they are called VIC1 and VIC2.

Base addresses

Basic Operation

VIC powers up with

Most likely you will change only the last of them.

Procedure

Initialization

  1. leave protection off, unless you are in doubt about your partner's ethics or competence.
  2. enable in VICxIntEnable only when you are ready to handle the interrupt

On an interrupt, the kernel

  1. reads the VICxIRQStatus register,
  2. chooses which interrupt to handle and
  3. clears the interrupt source in the device.

For debugging

  1. Use VICxSoftInt and VICxSoftIntClear to turn interrupt sources off and on in software

Hardware Definitions

Registers for Basic Operation
Register Name Offset R/W Description
VICxIRQStatus 0x00 RO One bit for each interrupt source

1 if interrupt is asserted and enabled

VICxFIQStatus 0x04 RO As above for FIQ
VICxRawIntr 0x08 RO As above but not masked
VICxIntSelect 0x0c R/W 0: IRQ, 1: FIQ
VICxIntEnable 0x10 R/W 0: Masked, 1: Enabled
VICxIntEnClear 0x14 WO Clears bits in VICxIntEnable
VICxSoftInt 0x18 R/W Asserts interrupt from software
VICxSoftIntClear 0x1c WO Clears interrupt from software
VICxProtection 0x20 R/W Bit 0 enables protection from user mode access
VICxVectAddr 0x30 R/W Enables priority hardware

See documentation.


Non-vectored Operation

Initialization

  1. Create user tasks with interrupts enabled.
  2. Enable interrupt in device
  3. Enable interrupt in ICU
  4. Enable interrupt in CPU, by MOVS whenever a task is activated.

Normal operation

When a hardware interrupt occurs you find yourself in IRQ mode. Next, you

  1. Remember that you started in IRQ mode.
  2. Switch to svc mode.
  3. Do the context switch.
  4. Look at the active interrupt sources; decide which one you will service; turn it off.
  5. Find which task is blocked waiting for the interrupt.
  6. Set up its return value, and make it ready.
Tasks waiting on interrupts are normally high priority, and usually run right away.

If a second interrupt occurs immediately

  1. The CPU checks AND( IRQ, NOT( IRQ disabled bit set in CPSR ) ) before each instruction fetch.
  2. If it is asserted an IRQ exception is taken in place of next instruction fetch.
  3. Context switch into kernel
  4. Turn off interrupt in device

AwaitEvent

The final Kernel Primitive

... except for Destroy

int AwaitEvent( int eventType )

More About AwaitEvent

Argument

  1. Somewhere there is a list of event types
  2. This is not very portable

Processing in the kernel

Clock Server, Task Structure

What does the clock server do?

How is AwaitEvent Used?

AwaitEvent is used to update the time.

Generalizing
  1. There should (almost) always be a task blocked on AwaitEvent for every interrupt type, at least when interrupts are enabled. Why?
  2. A server cannot call AwaitEvent. Why?
  3. We call the task that calls AwaitEvent a Notifier. Why?
  4. Code for a typical Notifier
      struct delivery {
          int type;
          int data;
      }
      
      void notifier( ) {
          struct delivery request;
          // Initialization, probably including device
          // Synchronization
          request.type = NOTIFIER;
          FOREVER {
              request.data = AwaitEvent( evtType );
              Send( server, &request, ... );
          }
      }
  5. Code for a typical server
      void server( ) {
          struct delivery request;
          // create notifier
          // other initialization
          // synchronization
          FOREVER {
              Receive( &requester, &request, ... );
              switch ( request.type ) {
              case NOTIFIER:
                  Reply( notifier );
                  data = request.data;
                  // use data
              case CLIENT:
                  ...
              }
          }
      }

HALT versus an Idle Task

What do you do when there are no tasks ready to run? Some tasks are probably blocked on AwaitEvent, and will run as soon as an interrupt occurs. What do you do?


Clock Server

Primitives

int Time( )
int Delay( int ticks )
int DelayUntil( int ticks )

Pseudo-implementation

void clock( ) {
    // Create Notifier and send  any initialization data
    // Initialize self
    FOREVER {
        Receive( &requester, &request, ... );
        switch ( request.type ) {
        case NOTIFIER:
            Reply( notifier, ... )
            // update time and check for terminated delays
        case TIME_REQUEST:
            Reply( requester, time,... )
        case DELAY_REQUEST: 
            // Add requester to list of suspended tasks
        }
        // Reply to suspended tasks that have timed out
    }
}

Comments:

  1. You need a common request type, or possibly a union.
  2. You should notice a typical server pattern.

It's normal to sort the list of suspended tasks. Why?


Return to: