CS452 - Real-Time Programming - Fall 2009

Lecture 14 - AwaitEvent

How to do it

Find source of the interrupt
- see below for different methods
Save state of interrupted task
- integrate information from user mode and irq mode
Restore kernel state
- now executing in svc mode
EITHER, process interrupt in kernel
1. acquire volatile data from device
2. turn off interrupt source
  - in device
  - in PIC
3. set up return value for AwaitEvent
4. schedule
5. exit from kernel
  - movs, or equivalent, moves SPSR to CPSR
  - goes to user mode
  - turns on interrupts
OR, process interrupt in notifier
1. exit, without scheduling, to notifier in svc mode
2. acquire volatile data from device
3. turn off interrupt source
  - in device
  - in PIC
4. turn on interrupts & return to user mode in one instruction

Your code should operate correctly if there is another interrupt waiting which is taken immediately after interrupts are enabled.

ISRs that do all the work
- somewhat better version of your polling loop
- fewer failed tests, but possibly more overhead
- not very modular
ISRs that work asynchronously
- leave behind a flag and volatile data
- picked up and processed the next time the kernel runs
ISRs that trigger other processes
- modular
- direct chain to required action


	Monolithic ISRs	Signals	Task chains	Comments
Non-nested	Yes	Yes	No: User tasks interruptable	Better not be very much to do. Test interrupt sources in order of priority.
Nested	Not usually	No. Trying to do minimal work	Yes: prioritized within task structure	Not very useful without priorities elsewhere Interrupts block-structured
Prioritized Nested	When there is too much to do.	No. Trying to do minimal work	Interruptable kernel, OR free with prioritized tasks	Hard to get right Do only higher priority nested
Prioritized: software	No	No	Yes	Minimal interruption for lower priority
Prioritized: hardware	Yes, if processing is long	Yes, for simultaneous interrupts	Yes, for simultaneous interrupts	No interruption for lower priority
Vectored, with priority	Yes, for speed	Yes, for speed	Not usually worth it	This cuts out polling of the interrupt controller and the devices.

Status: which interrupts are active
- conditioned by ICU masks
- unconditioned (ICU inputs) RAW
Enable: allows interrupts to be asserted
- ARM has a distinct register for clearing
SoftInt: sets an interrupt from a particular source
Vector address
- Priority hardware selectes the highest priority asserted and enabled interrupt
  - This tells which it is when you read it
- Priority hardware reprocesses when you write it.

Two controllers, daisy-chained

Registers at

47 registers per controller

Priority

Making programming easier

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

HALT

Return to: