CS452 - Real-Time Programming - Fall 2011

Lecture 12 - Hardware Interrupts II

Public Service Annoucements

1. Due date of kernel 3 (Monday, 17 October)

Hardware Interrupts

Up to this point the kernel is not able to accept input from the outside world, or to affect the outside world. Thus, the possibility of an event occurring that must be followed by a timely response is not an issue. Hardware interrupts change that rosy world.

In a distant era of CPU design (somewhere around the MC68000) the interrupt changed its status from afterthought to crucial in the designer's mind. Its name also changed, from `interrupt' to `exception'.

What is a Hardware Interrupt?

The first issue is level versus edge dependent.

• This is determined by where the latch is located
  • in the CPU
  • in the ICU
  • in the device
• Read the documentation carefully

In the CPU

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

In the Interrupt Control Unit (ICU)

• Several interrupts may be present when an interrupt occurs
  • One is chosen, by a priority mechanism
  • Put in a special place
  • Software can choose to ignore priority mechanism in ICU
• Clearing one interrupt may just expose another one

In the Peripheral Hardware

• Several interrupts may be present
  • ORed in peripheral hardware
  • ORed in glue hardware
  • Rare that there is a interrupt priority mechanism
    • There is no inherent relationship between task priorities and interrupt priorities.
    • The relationship is created by the application programmer.
• Clearing one interrupt can expose another one

When two interrupts are present

May have been two present when interrupt processing started

• in which case interrupt occurring now is known to be of lower priority

May have occurred since interrupt processing started

• in which case interrupt occurring now may be of higher priority

What happens next? Whatever the case,

1. Kernel executes with interrupts disabled
2. Context switch into user task turns on interrupts
   • How?
3. Before fetching the first user task instruction test interrupt signal
4. It is asserted, interrupt processing restarts immediately

For this behaviour to do the job the time spent inside the kernel must be small compared to latencies acceptable to the objectives of the application.

Context Switches for Interrupts

Difference from Software Interrupts

It is impossible to predict where they occur

• You may have made some assumptions about when they occur

Assymmetry between User Task and Kernel

Scratch Registers must be saved

• including the IP

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 return from the interrupted function to whatever called it.
   • 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

Kernel Provision for Interrupts

1. Initialize the kernel with interrupts disabled
2. Turn on interrupts by having user PSW with interrupts enabled
   • First instruction of user task might not execute immediately
3. Find source of interrupt
   • Query ICU
   • Query device
4. Turn off source of interrupt
   • In device
   • In ICU
   • PSR remains with IRQ disabled
5. Handle interrupt
   • Find waiting task
   • Make waiting task READY
6. Reschedule and activate

Three Free Choices

1. Rescheduling
2. Volatile Data
3. Re-enabling interrupts

The Hardware in the Trains Lab

Timer

Interrupt Control Unit (ICU)

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

Vectored Operation

Procedure

Initialization

1. Write kernel entry point into VICxDefVectAddr
2. If desired write special entry point into VICxVectAddry
3. When ready to accept interrupts write source and enable into VICxVectCntly

When an interrupt occurs

1. Read VICxVectAddr to find address
2. Move result to PC
3. When service is complete write VICxVectAddr to start priority hardware

Return to:

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