CS452 - Real-Time Programming - Fall 2010
Lecture 12 - Hardware Interrupts
Pubilic Service Announcements
- Happy Thanksgiving
What is a Hardware Interrupt?
In the CPU
- Test interrupt signal before fetching the next instruction
- actually AND of INT and CPSR bit
- If asserted, change mode to IRQ
- Disable interrupt in CPSR
- 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 priority mechanism
- 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?
- Kernel executes with interrupts disabled
- Context switch into user task turns on interrupts
- Before fetching the first user task instruction test interrupt
signal
- If asserted, re-initiate interrupt processing
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
Two Link Registers
- One to return from interrupt
- In the registers of the interrupt handling code
- To return to the interrupted task in the right place
- 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
- Several places where you can read state
- Several places where you can block interrupt flow
- Trigger hardware interrupt from software
- 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
- This allows you to separate them in developing/debugging
Kernel Provision for Interrupts
- Initialize the kernel with interrupts disabled
- Turn on interrupts by having user PSW with interrupts enabled
- First instruction of user task might not execute immediately
- Find source of interrupt
- Turn off source of interrupt
- In device
- In ICU
- PSR remains with IRQ disabled
- Handle interrupt
- Find waiting task
- Make waiting task READY
- Reschedule and activate
Three Free Choices
- Rescheduling
- Volatile Data
- 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
- leave protection off
- enable in VICxIntEnable when you are ready to handle the interrupt
On an interrupt
- Read VICxIRQStatus
- Choose which interrupt you wish to handle
- Clear the interrupt source in the device
For debugging
- 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 not masked
|
| 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.
|
Vectored Operation
Procedure
Initialization
- Write kernel entry point into VICxDefVectAddr
- If desired write special entry point into VICxVectAddry
- When ready to accept interrupts write source and enable into
VICxVectCntly
When an interrupt occurs
- Read VICxVectAddr to find address
- Move result to PC
- When service is complete write VICxVectAddr to start priority
hardware
| Register Name |
Offset |
R/W |
Description |
| VICxVectAddr |
0x030 |
R/W |
Read: address of vector for highest priority interrupt
Write: service complete, enable priority hardware
|
| VICxDefVectAddr |
0x034 |
R/W |
Default vector address |
| VICxVectAddry |
0x100+4y |
R/W |
Vector address for interrupt y |
| VICxVectCntly |
0x200+4y |
R/W |
Control register for interrupt y
Bit[0-4]: interrupt source for interrupt y
Bit[5]: enable vectored interrupt y
|
Return to: