Outline Basic Input / Output Interrupt hardware architecture - - PDF document

outline
SMART_READER_LITE
LIVE PREVIEW

Outline Basic Input / Output Interrupt hardware architecture - - PDF document

Interrupts and Exceptions Outline Basic Input / Output Interrupt hardware architecture Prioritized Interrupts Interrupt Vectors Interrupt Handling Interrupt Service Routines Interrupt Service Threads The Shared Data


slide-1
SLIDE 1

1

Interrupts and Exceptions

Embedded Operating Systems HPI

2

Outline

Basic Input / Output Interrupt hardware architecture

Prioritized Interrupts Interrupt Vectors

Interrupt Handling

Interrupt Service Routines Interrupt Service Threads

The Shared Data Problem (overhead slides) Operating systems : Interfacing Interrupt Handling

(eCos, Windows Ce)

slide-2
SLIDE 2

2

Embedded Operating Systems HPI

3

Motivation

Typical embedded systems react on external

events (e.g. closed-loop control)

Predictable response time required I/O architecture of operating system and

application have major influence on responsiveness of real-time system

High reliability required: software faults must be

handled, fault recovery – exception handling

Interrupt latency : important real-time

performance indication, must be bounded

Embedded Operating Systems HPI

4

Input and Output Devices

CPU status register data register

device mechanism

  • data registers hold

values that are treated as data by the device

  • status registers provide

information about the device operation

slide-3
SLIDE 3

3

Embedded Operating Systems HPI

5

Input Output Primitives

CPUs provide programming support for input and output

Special I/O instructions ( in, out ) Memory-mapped I/O

Addresses for the registers in I/O devices Normal memory read / write instructions can be used

Example : moving the byte “5” to parallel data register

mov dx, 0x03BC mov al, 0x5

  • ut dx, al

Embedded Operating Systems HPI

6

Busy-Wait I/O Programming (Polling)

// Copying characters from input to output while(true) { // read a character into achar while(read(IN_STATUS)==0); // wait until ready achar = (char) read (IN_DATA); // write achar write(OUT_DATA,achar); write(OUT_STATUS,1); // turn on device while(read(OUT_STATUS)!=0); // wait until done }

slide-4
SLIDE 4

4

Embedded Operating Systems HPI

7

Polling vs. Interrupts

Polling

Higher Sampling Frequencies, Higher Accuracy, Typical

rates up to 300 kHz

Overhead if no useful data on device Tradeoff : Precision vs. Utilization

Interrupt

Slower Reaction Times, Typical rates 20 kHz Less overhead, more efficient – no busy wait, data

processed if available

Fire rates must be known/bounded for real-time systems But longer processing time

Save: Stack Pointer, Program Counter, Context

Embedded Operating Systems HPI

8

Input and Output Devices

CPU status register data register device mechanism

  • I/O- device asserts the

interrupt request signal when it wants service from the CPU

  • CPU assert interrupt ackn.

signal when it is ready to handle the request device

interrupt request interrupt acknowledge data / address

slide-5
SLIDE 5

5

Embedded Operating Systems HPI

9

Implementation of Interrupts

CPU checks interrupt request line at the beginning of

execution of every instruction

If interrupt has been asserted, CPU will not fetch next

instruction pointed by the Program Counter (PC)

CPU saves current PC + some Context PC will be set to pre-defined interrupt handling routine Pointer to handler routine at fixed point in memory

(vector table), typically 0x00000000 or configurable

Special return instruction (iret) restores PC + saved

Context, next “normal” instruction executed

Embedded Operating Systems HPI

10

Trigger of Interrupts

Level Triggering Edge Triggering

slide-6
SLIDE 6

6

Embedded Operating Systems HPI

11

Handling multiple interrupts

Typical system has more that one I/O-device

System must provide more than one interrupt

request line

Interrupts and Polling ( check source in case of

interrupt )

Interrupt vectors allow the interrupting device to

specify its handler

Interrupt priorities : allow the CPU to recognize

some interrupts as more important than others

Embedded Operating Systems HPI

12

Prioritized Interrupts

device 1 device n device 2 … CPU

L1 L2 … Ln

interrupt acknowledge log2n

slide-7
SLIDE 7

7

Embedded Operating Systems HPI

13

Masking

Lower-priority interrupts must be disabled when higher-

priority interrupt is handled

If interrupt is acknowledged - CPU stores current

priority level into a special register

Some CPUs deactivate interrupts at all

Priorities of subsequent interrupts are checked against

the register

When interrupt handler exits, register must be reset Most architectures define special interrupt return

instruction

Embedded Operating Systems HPI

14

Interrupt Vectors

device CPU

interrupt request vector

interrupt acknowledge

handler 1 handler 3 handler 4 handler 2 vector 1 vector 2 vector 4 vector 3

interrupt vector table head

:CPU :device

Interrupt request interrupt acknowledge Interrupt vector T I M E

slide-8
SLIDE 8

8

Embedded Operating Systems HPI

15

Programmable Interrupt Controller

Shields operating system from electrical details of the

interrupt lines

Interrupt priorities can be configured by software Some PICs provide queues in order to reduce miss rate of

interrupts

Modern APIC architecture

supports more interrupt lines, faster to program, allows edge-triggered interrupts instead

  • f level-triggered interrupts

Embedded Operating Systems HPI

16

Synchronous Interrupts: Exceptions

Synchronous: caused by the execution of an

instruction

Caused by a specific (synchronous) machine

instruction

trap Motorola 68000, swi Arm, int 80x86 used to implement system calls

Caused by instructions with error condition

divide by zero page fault, alignment exception illegal instructions

Hardware errors

slide-9
SLIDE 9

9

Embedded Operating Systems HPI

17

Difference hardware / software interrupt (cont.)

Further interrupts are disabled as soon as an

hardware interrupt comes in, but not disabled in the case of a software interrupt

The handler of a software interrupt runs in the

context of the interrupting task

The ISR of a hardware interrupt has no

connected task context to run in

Some OS provide a separate context for

interrupt handlers

Embedded Operating Systems HPI

18

Classes of Exceptions

Class Cause A/S Return behavior Interrupt

Signal from I/O device Async Always returns to next instruction

Trap

Intentional exception

Sync

Always returns to next instruction

Fault

Potentially recoverable error

Sync

Might return to current instruction

Abort

Nonrecoverable error

Sync

Never returns

slide-10
SLIDE 10

10

Embedded Operating Systems HPI

19

Interrupts

Interrupt: occurs asynchronously as a result of signals from I/O devices that are external to the processor

  • Asynchronous: not caused by the execution of any

particular instruction

User program

Control passes to handler after current instruction finishes

Interrupt handler

Interrupt pin goes high during execution of current instruction

Icurr Inext

Interrupt handler runs Handler returns to next instruction

Example I/O devices:

  • network adapters
  • disk controllers
  • timer units
  • A/D converters

etc.

Embedded Operating Systems HPI

20

Traps

Trap: intentional exception that occurs as a result of executing an instruction

  • Synchronous: caused by the execution of an instruction

User program

Control passes to handler

Trap handler

Application makes a system call

syscall

Inext

Trap handler runs Handler returns to next instruction

Example Operating system call:

  • read a file
  • terminate a process

etc.

slide-11
SLIDE 11

11

Embedded Operating Systems HPI

21

Faults

Fault: Results from an error condition that a handler might be able to correct

  • Synchronous: caused by the execution of a particular instruction

User program

Control passes to handler

Fault handler

Current instruction causes a fault

Icurr

Fault handler runs

Handler either reexecutes current instruction

  • r aborts

abort

Example Page fault exception:

  • physical page not in

memory

Embedded Operating Systems HPI

22

Aborts

Abort: results from unrecoverable fatal error, typically hardware errors

  • Synchronous: caused by the execution of an instruction

User program

Control passes to handler

Abort handler

Fatal hardware error occurs

Icurr

Abort handler runs Handler returns to abort routine abort

Example Hardware errors:

  • parity error

(DRAM/SRAM bits corrupted)

  • machine check etc.
slide-12
SLIDE 12

12

Embedded Operating Systems HPI

23

Privileged Mode (User-/Kernelmode)

System calls can be performed by generation

  • f a software interrupt (trap)

System calls are handlers of software

interrupts !

Typically system calls copy data to registers or

the stack and trigger a software interrupt

For example : Windows NT uses interrupt 2Eh

to execute undocumented system calls

MSDOS uses interrupt 21h, BIOS functions

accessible via 10h, 13h, 16h (x86)

Embedded Operating Systems HPI

24

Interrupt Service Handler Interrupt Service Routines

Should be as short as possible (all other

interrupts could be disabled)

Launching of ISRs is not controlled by the

  • perating system, everything is done by the

CPU

Typically reading or writing of some registers

and buffer them for further reading

Deferred interrupt handling supported by most

  • perating systems
slide-13
SLIDE 13

13

Embedded Operating Systems HPI

25

Interrupt Handling

Embedded Operating Systems HPI

26

Interrupt overhead

CPU checks for pending interrupts at the beginning of

an instruction

Device receives the acknowledgment and sends the

CPU its interrupt vector

CPU finds interrupt handler using vector as index, save

the current value of PC and other internal CPU state

Device driver saves additional state, performs required

  • perations on the device, restores state, executed

interrupt return instruction

PC and other automatically saved state are restored

slide-14
SLIDE 14

14

Embedded Operating Systems HPI

27

Interrupt Latency

Total delay experienced by a device from

the time it raises an interrupt to:

The time at which its interrupt service routine

(ISR) begins to execute

request latency service time deadline ? time interrupt response time

Embedded Operating Systems HPI

28

Sources of Interrupt Latency

Hardware latency Completion of current instruction

Longest instructions are complex multiplies, read-

modify-write instructions (increment memory)

Block memory-to-memory single instructions

Time to complete all ISRs of higher priority

interrupts

Atomic operations ( disable all interrupts ) Time to save context of currently running task

slide-15
SLIDE 15

15

Embedded Operating Systems HPI

29

Interrupt Nesting

If the processor / operating system allow interrupt nesting, a ISR

servicing one interrupt can be pre-empted by higher interrupts

Increased code complexity, ISR must be implemented robust

against being pre-empted any time

Reentrant ISR allow an

interrupt to pre-empt its own ISR

Reservation of sufficient

stack space

Embedded Operating Systems HPI

30

Interrupt Nesting Using a Separate Stack Frame

slide-16
SLIDE 16

16

Embedded Operating Systems HPI

31

Interrupt Sharing

Allows different peripheral devices to be linked to the

same hardware interrupt

Can be implemented by checking status registers of

devices

Many operating systems accept multiple interrupt

handlers linked to the same hardware interrupt

Kernel registers its own ISR on the hardware interrupt,

which invokes one by one all ISRs registered by application programs

For low interrupt latency only one ISR per interrupt line

should be registered

Embedded Operating Systems HPI

32

Scheduling Multiple Devices

Actual worst case latency Device Service Time

900 Keyboard 800 1200 Disk 500 1300 Printer 400

K D P K D P K D P Req:K,D,P Req:D,P,K Req:K,P,D

  • No priorities, no pre-emption
  • What is the worst case latency seen by each device ?
slide-17
SLIDE 17

17

Embedded Operating Systems HPI

33

Weak (non-preemptive) Priorities

Actual worst case latency Device Service Time

900 Keyboard 800 800 Disk 500 1300 Printer 400

K D P K D P Req:K,P,D Req:P,D,K

  • Weak priority ordering : Check in prescribed sequence,

eg: Disk > Printer > Keyboard

Embedded Operating Systems HPI

34

Recurring Interrupts

Actual worst case latency Device Service Time

  • Max. Delay
  • Max. Freq.

900 Keyboard 800 100/s Disk 500 300 500/s 500 Printer 400 1000/s

D P K D P

D P K P

P

P D P

P D P

P D

  • Worst case latency is not all !
  • Keyboard service routine does not finish after 3ms !
slide-18
SLIDE 18

18

Embedded Operating Systems HPI

35

Global System Priorities

Embedded Operating Systems HPI

36

Deferred Service Routine

ISR should be as short as possible Most ISR only read or write data involved in the

communication with the peripheral device

Further processing is done in a separate task

included in operating system scheduling

During runtime of the deferred service routine

new interrupts of the same type will be accepted

Kernel functions calls possible

slide-19
SLIDE 19

19

Embedded Operating Systems HPI

37

Deferred Interrupt Routine

dsr_thread() { while(1) { wait_for_signal_from_isr(); process_data_of_ISR(); } } interrupt_handler() { reset_hardware(); do_isr_stuff(); send_signal_to_wake_up_dsr(); re_enable_interrupts(); }

Embedded Operating Systems HPI

38

Implementing an Interrupt Service Routine

Getting data from the ISR to the DSR should

be done in a non-blocking way

FIFOs, Shared Memory Circular Buffers

Don’t wait on semaphores or any other

potentially blocking system call

Semaphore signaling is often used Enable interrupts as fast as possible Mind the shared data problem !!

slide-20
SLIDE 20

20

Embedded Operating Systems HPI

39

Interrupts in the I/O Subsystem

fread read

I/O read

device read

IST ISR

system ISR

U S E R K E R N E L

Application Library I/O Subsystem Device driver ISR

return triggers SW interrupt call device driver Initiate hardware access

Hardware

return if data available interrupt blocked wake calls schedule return

Embedded Operating Systems HPI

40

Interfacing Interrupt- / Exception Handling

eCos Windows CE.NET

slide-21
SLIDE 21

21

Embedded Operating Systems HPI

41

eCos

Embedded Configurable Operating System Released 1998 by Cygnus Solutions Open source real-time operating system POSIX, µITRON compatible Fine-grained configurable kernel

Based on compiler pre-processing (source code)

Supports ARM, Hitachi H8-300, Intel x86,

MIPS, Matsushita AM3x, Motorola 68k, PowerPC, SuperH, SPARC and NEC V8xx

Embedded Operating Systems HPI

42

eCos

  • Kernel (HAL)

supported exception handling + installable user exception routines

  • Application

Exception Handling: application can manipulate vector service routine directly

slide-22
SLIDE 22

22

Embedded Operating Systems HPI

43

Setting up Exception Handlers

void cyg_exception_set_handler( cyg_code_t exception_number, cyg_exception_handler_t *new_handler, cyg_addrword_t new_data, cyg_exception_handler_t **old_handler, void **old_data); void cyg_exception_clear_handler( cyg_code_t exception_number); void cyg_exception_call_handler( cyg_handle_t thread, cyg_code_t exception_number, cyg_addrword_t exception_info );

Embedded Operating Systems HPI

44

Standard exception vectors supported by most IA32 CPUs

#define CYGNUM_HAL_VECTOR_DIV0 0 #define CYGNUM_HAL_VECTOR_DEBUG 1 #define CYGNUM_HAL_VECTOR_NMI 2 #define CYGNUM_HAL_VECTOR_BREAKPOINT 3 #define CYGNUM_HAL_VECTOR_OVERFLOW 4 #define CYGNUM_HAL_VECTOR_BOUND 5 #define CYGNUM_HAL_VECTOR_OPCODE 6 #define CYGNUM_HAL_VECTOR_NO_DEVICE 7 #define CYGNUM_HAL_VECTOR_DOUBLE_FAULT 8 #define CYGNUM_HAL_VECTOR_INVALID_TSS 10 #define CYGNUM_HAL_VECTOR_SEGV 11 #define CYGNUM_HAL_VECTOR_STACK_FAULT 12 #define CYGNUM_HAL_VECTOR_PROTECTION 13 #define CYGNUM_HAL_VECTOR_PAGE 14 #define CYGNUM_HAL_VECTOR_FPE 16 #define CYGNUM_HAL_VECTOR_ALIGNMENT 17

slide-23
SLIDE 23

23

Embedded Operating Systems HPI

45

eCos Interrupt Handling

Embedded Operating Systems HPI

46

eCos Interrupt Configuration

Option Name Use Separate Stack For Interrupts CDL Name CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK

Description: Allows a separate stack, maintained by the HAL, during interrupt processing. This eliminates the need for every thread stack to allow space for interrupt handlers. This option is enabled by default.

Option Nam Interrupt Stack Size CDL Name CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE

Description: Specifies, in bytes, the stack size for the interrupt stack. This is the stack that will be used for all interrupts when Use Separate Stack For Interrupts is enabled. The value for this

  • ption is dependent on the architecture and application, as well as other interrupt configu-

ration options, such as interrupt nesting. This stack is also used during the HAL startup

  • process. The default value for this option is 4096.

Option Name Allow Nested Interrupts CDL Name CYGSEM_HAL_COMMON_INTERRUPTS_ALLOW_NESTING

Description Causes the HAL default interrupt VSR to re-enable interrupts prior to invoking the interrupt handler. This allows other interrupts, typically of higher priority, to occur and be processed. This

  • ption is disabled by default.

Option Name

slide-24
SLIDE 24

24

Embedded Operating Systems HPI

47

eCos Interrupt Configuration (cont.)

Save minimum context on interrupt Chain all interrupts together Ignore spurious interrupts Use delayed service routines Use linked lists for DSRs Use fixed-size table for DSRs

Embedded Operating Systems HPI

48

Literature

“Embedded Development: Handling Exceptions and Interrupts in eCos”, www.informit.com

slide-25
SLIDE 25

25

Embedded Operating Systems HPI

49

Windows CE.Net

Embedded Operating Systems HPI

50

OAL ISR Handling

If the interrupt is INTR_TIMER0 (System Timer)

l Updates the CurMSec keeping time for the OS l Check to see if a reboot address has been registered

(RebootHandler)

If the interrupt is INTR_RTC

l The ISR checks to see if an alarm has expired

(SYSINTR_RTC_ALARM)

If the Interrupt is less that the INTR_MAXIMUM

l Call the Interrupt chain (NKCallIntrChain) l Sets the return value from the NKCallIntrChain to the return value l If the interrupt chain did not claim the interrupt: (SYSINTR_CHAIN)

Map the current hardware interrupt (OEMTranslateIRQ)

slide-26
SLIDE 26

26

Embedded Operating Systems HPI

51

OAL ISR Handling (cont.)

l If the interrupt was registered with HookInterrupt in OEMInit l Return the SYINTR value from OEMTranslateIRQ l If the interrupt was not registered return SYSINTR_NOP l Enables all but the current interrupt. (PICEnableInterrupt) l Does the proper end of interrupt to signal the PIC that the interrupt

is done (EOI)

The ISR returns one of the following:

l SYSINTR_NOP—No ISR claimed the interrupt l SYSINTR_RESCHED—Reschedule Timer has

expired

l SYSINTR—ISR has claimed the interrupt l SYSINTR_RTC_ALARM—Alarm has expired

Embedded Operating Systems HPI

52

Installable ISRs

OEM not completely responsible for the platform and the

application code

To install an ISR into a platform there are two required

steps:

Call the LoadIntChainHandler function to load the DLL

containing the ISR code.

The ISR must be coded to respond with a

SYSINTR_ . . . response as in the OAL ISR.

The LoadIntChainHandler function loads the ISR

dynamic-link library (DLL) into the kernel's address space

code cannot call any non-kernel functions including any

C-language runtime library functions

slide-27
SLIDE 27

27

Embedded Operating Systems HPI

53

IST Interrupt Handling Interrupt Initialization

The key steps in initializing an interrupt are:

  • Creating an Event
  • Getting the System Interrupt number for your IRQ
  • Creating an interrupt thread (IST) that is suspended
  • Calling InterruptInitialize to create an association of

the IRQ-Event

  • Creating an IST that is not suspended may cause

InterruptInitialize to fail because the event is already being waited on

  • Set the thread priority to the appropriate priority
  • Resuming the IST

Embedded Operating Systems HPI

54

IST Interrupt Handling IST-Interrupt Service Thread

The key components of an IST interrupt handling thread are:

Waiting for the Interrupt Event. Confirming that we have a pulsed event from the OS. Do any board level interrupt processing necessary to complete

the interrupt. In our example we confirm the interrupt.

Handling the interrupt in the shortest time possible. Create CELOGDATA to be viewed in Kernel Tracker. Check to see if the g_fPRRunning flag is set and then set the

g_hevPRStart Event.

Call InterruptDone().

The OS will not provide another interrupt on this IRQ until

InterruptDone is called

slide-28
SLIDE 28

28

Embedded Operating Systems HPI

55

Windows Ce.Net ISR Latency

A Maximum time that interrupts are off in the kernel. The kernel

seldom turns off interrupts, but when they are turned off, it is for a bounded amount of time.

B Time between when the kernel dispatches an interrupt and when

an ISR is actually invoked. The kernel uses this time to determine what ISR to run and to save any register that must be saved before proceeding.

C Time between when an ISR returns to the kernel and the kernel

actually stops processing the interrupt. This is the time when the kernel completes the ISR operation by restoring any states, such as registers, that were saved before the ISR was invoked.

Start of ISR =

Embedded Operating Systems HPI

56

Windows Ce.Net IST Latency

B Time between when the kernel dispatches an interrupt

and when an ISR is actually invoked. The kernel uses this time to determine what ISR to run and to save any register that must be saved before proceeding.

C Time between when ISR returns to the kernel and the

kernel actually stops processing the interrupt. This is the time when the kernel completes the ISR operation by restoring any state, such as registers, that were saved before the ISR was invoked. L Maximum time in a KCALL. M Time to schedule a thread.

Start of highest priority IST =

slide-29
SLIDE 29

29

Embedded Operating Systems HPI

57

Literature MSDN - Articles

“Interrupt Architecture in Microsoft Windows

CE .NET”

“Writing Reliable Native Code” “Designing and Optimizing Microsoft

Windows CE .NET for Real-Time Performance”

“Benchmarking Real-time Determinism in

Microsoft Windows CE”