CS452 - Real-Time Programming - Winter 2013

Lecture 12 - Hardware Interrupts

Public Service Annoucements

Assignment 3

Clock Server, Task Structure

A New Kernel Primitive: int AwaitEvent( int EventType )

How is AwaitEvent Used?

There should (almost) always be a task blocked on AwaitEvent for every interrupt type. Why?
A server cannot call AwaitEvent. Why?
We call the task that calls AwaitEvent a Notifier. Why?

Code for a typical Notifier

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

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

Somewhere there is a list of event types
- Application programmer knows the list
- Kernel can respond to each event type on the list
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:

You need a common request type, or possibly a union.
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: