CS452 - Real-Time Programming - Spring 2013

Lecture 12 - Context Switch Redux

Pubilc Service Annoucements

1. Due date for kernel 2: 3 June.

Hardware Interrupts

What is a Hardware Interrupt?

In the CPU

1. Test interrupt signal before fetching the next instruction
   • actually AND of INT and the IRQ bit in the CPSR
2. If asserted, change mode to IRQ
3. Disable interrupt in CPSR
4. Put CPSR into SPSR_irq
5. Execute instruction at 0x18

In the Interrupt Control Unit (ICU)

• Several interrupts may be present
  • There are two options for deciding which one to service
    1. Software
       • Check ICU status registers to discover which interrupt(s) are present
       • Run an algorithm that decides which one to take
       • This permits context-dependent priorities
    2. Hardware
       • Program the ICU to a set of fixed priorities
       • Entry point of highest priority interrupt appears in ICU
       • Jump to it without requiring software priority resolution.
• Handling one interrupt sometimes exposes another one

In the Peripheral Hardware

• Several interrupt conditions may be present at one time
  • ORed in peripheral hardware
  • ORed in glue hardware
  • Rare that there is a priority mechanism
• Handling one interrupt sometimes exposes another one

When two interrupts are present

What should happen?

1. Kernel executes with interrupts disabled.
2. Context switch into user task turns on interrupts.
3. Before fetching the first user task instruction test IRQ input.
4. If asserted, re-initiate interrupt processing.

Context Switches for Interrupts

Difference from Software Interrupts

It is impossible to predict when hardware interrupts occur ( = where the PC is)

• Software intterrupts occur at only a few places in the code.
• You may have a kernel that takes this predictability for granted.

Assymmetry between User Task and Kernel

For the interrupted task,

1. scratch registers must be saved and restored, including IP
2. stack pointer must be stored
3. two link registers must be kept separate

For the kernel,

1. no need to save scratch registers
2. stack pointer preserved in S13_svc
3. link register preserved in R14_svc

Two Link Registers

1. One to return from interrupt
   • In the registers of the interrupt handling code
   • To return to the interrupted task in the right place
2. One to move to the caller's stack frame
   • In the registers of the interrupted task
   • To return to whatever started in interrupted task

Helpful Features of the ICU

1. Several places where you can read state
2. Several places where you can block interrupt flow
3. Trigger hardware interrupt from software
   • What makes interrupts hard is that you are doing two semi-hard things at once
     1. Making the hardware produce the interrupt
     2. Responding to the interrupt
   • This allows you to separate them in developing/debugging

The Hardware in the Trains Lab

32-bit Timer

Base address: 0x80810080

Three registers:

Interrupt Control Unit (ICU)

The actual device is the ARM PL190

The logic in this design is completely asynchronous, so it functions when the CPU clock is turned off.

• Important (= essential) for low power operation.

All input signals are

• active high
• level sensitive

Base addresses

• VIC1: 0x800B0000
• VIC2: 0x800C0000

Basic Operation

VIC powers up with

• all vectored interrupts disabled.
• all interrupts masked
• all interrupts giving IRQ

Procedure

Initialization

1. leave protection off
2. enable in VICxIntEnable when you are ready to handle the interrupt

On an interrupt

1. Read VICxIRQStatus
2. Choose which interrupt you wish to handle
3. Clear the interrupt source in the device

For debugging

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

Hardware Definitions

Helpful Features of the ICU

1. Several places where you can read state
2. Several places where you can block interrupt flow
3. Trigger hardware interrupt from softwareonce
   1. What makes interrupts hard is that you are doing two semi-hard things at once
      • Making the hardware produce the interrupt
      • Responding to the interrupt
   2. Software interrupt generation allows you to separate them in developing/debugging

Non-vectored Operation

Initialization

1. Enable interrupts in device
2. Enable interrupts in ICU
3. Enable interrupts in CPU, usually by MOVS

Interrupt occurs

1. AND of IRQ and NOT( IRQ disabled bit in CPSR ) is checked before each instruction fetch.
2. If set IRQ exception is taken in place of next instruction fetch.
   • Possibly zero instructions of active task are executed.
   • Make sure that this case works
3. Context switch into kernel

   ---

   Context switch novelties

   Difference from Software Interrupts

   • It is impossible to predict where they occur
   • You may inadvertently have made some assumptions about when they occur
   • Scratch Registers must be saved
     • r0-3
     • IP -- used only very occasionally by gcc
   • Two Link Registers
     • One to return from interrupt
     • One to return from the interrupted task to whatever called it

   ---

4. Turn off interrupt in device
   • Should turn off interrupt in ICU
   • What about IRQ?

You are now ready to process the interrupt in the kernel

Clock Server, Task Structure

A New Kernel Primitive: int AwaitEvent( int EventType )

How is AwaitEvent Used?

1. There should (almost) always be a task blocked on AwaitEvent for every interrupt type. 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

   void notifier( ) {
       Receive( &server, &evtType, ... );
       // Initialization, probably including device
       Reply( server, ... );
       FOREVER {
           data = AwaitEvent( evtType );
           Send( server, &data, ... );
       }
   }

5. Code for a typical server

   void server( ) {
       notifier = Create( HIGHEST, ... );
       // other initialization
       Send( notifier, &evtType, ... );
       FOREVER {
           Receive( &requester, &request, ... );
           switch ( request.type ) {
           case NOTIFIER:
               Reply( notifier );
               data = request.data;
               // use data
           case CLIENT:
               ...
           }
       }
   }

More About AwaitEvent

Argument

1. Somewhere there is a list of event types
   • Application programmer knows the list
   • Kernel can respond to each event type on the list
2. This is not very portable
   • The list would normally be the union of all types occurring on all hardware
   • This is the Windows problem

Processing in the kernel

• Initialization
  1. Kernel initialization has IRQ masked
  2. Kernel initializes ICU
  3. For each device
     1. Kernel initializes hardware
     2. Kernel turns on interrupt(s) in the device
  4. Kernel starts first user task
  5. Eventually, Notifier is created
  6. Notifier
     1. initializes device
     2. turns on interrupt(s) in the device
     3. turns on interrupt(s) in the ICU
     4. calls AwaitEvent
• Procedure
  1. Kernel
     1. identifies interrupt source
     2. identifies the correct Notifier
     3. acquires volatile data
     4. re-enables interrupt in the device
     5. re-enables interrupt in the ICU
     6. re-enables interrupt in the CPU during task activation (eg, movs)
     7. puts volatile data into AwaitEvent's return value
     8. Makes Notifier ready
  2. Notifier
     1. collects and packages data
     2. sends to server
  3. Eventually Server
     1. Replies to Notifier
     2. Acts on the data
• Advantage
  • Clean consistent user code
• Disadvantage
  • Kernel has to know a lot about the hardware.
  • Hardware knowledge split between Notifier and kernel

HALT versus an Idle Task

What do you do when there are no tasks to run?

• Idle task
  • lowest priority
  • diagnose system: at least % of time idle should be known.
  • search for ETI
• HALT
  • turns off CPU clock
  • save power (battery)
  • provided two ways
    1. through System Controller Co-processor
    2. through the TS-7200 clock controller
  • IRQ path is asynchronous, so it works when the clock is off

Clock Server

Primitives

int Time( )

• Clock server starts at zero when it initializes
• Unit of time is tick

int Delay( int ticks )

• Note error returns
• You might want to add an error for negative arguments
  • ticks is usually calculated, and a negative value is an early warning of falling behind.

int DelayUntil( int ticks )

• Can be constructed from the above two primitives.

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
        case TIME_REQUEST:
            Reply( requester, time,... )
        case DELAY_REQUEST: 
            // Add requester to list of suspended tasks
        }
        // Reply to any timed-out tasks
    }
}

Comments:

1. You need a common request type, or possibly a union.
2. You should notice a typical server pattern.
   • Notifier updates data
   • Client who can be serviced now is serviced
   • Client who needs service in the future is suspended
   • List of suspended tasks is checked regularly

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

Return to:

• Bill Cowan's lecture notes for CS452 in s13
• Bill Cowan's Spring 2013 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page