Embedded Real-Time Systems Processing interrupts Lecturer Department University

2 Outline Interrupt processing in real-time systems Limitations of ISRs ISR-to-task communication

3 A bit of history … Interrupt – a signal from hardware indicating need for attention Introduced to avoid wasting processor ’ s time in polling loops Commonly used technique for computer multi- tasking

4 Interrupts processing The CPU interrupts execution of the current tasks and transfers control to the corresponding interrupt service routine (ISR) hardware interrupt controller CPU ISR Current task Interrupt signal

5 Classification Synchronous – predictable, occur at known times (e.g. system clock) Asynchronous – can occur at any time, when a device needs attention Software interrupts – generated by CPU executing an instruction Maskable – can be ignored Non-maskable – cannot be ignored (usually notify about serious system problem)

6 Interrupt service routines Reacts on the interrupt signals from the hardware performing necessary hardware management operations data exchange with user application tasks (I/O) notification of the application tasks about the external events Important part of a real-time OS: task scheduling disk I/O networking other examples …

7 Interrupt processing in RTOS ISRs block the highest priority task – interferes with the task scheduler, affects real- time behaviour Solution – defer interaction with hardware acknowledge interrupt queue work for a normal task (e.g. a device driver task) ISR Driver task Work queue Interrupt call Ack./disable

8 Interrupt processing in RTOS (contd.) All ISRs are executed in a special context: outside of any task ’ s context interrupt handling involves no context switch fast response Downside: limits what ISRs can do (since they have no task context) more on this later …

9 Connecting ISR code to interrupts intConnect (vector, function, parameter) connects a C function to an interrupt vector – the interrupt vector (interrupt number) function – the ISR parameter – optional ISR parameter (e.g. using the same ISR code for handling different interrupt sources in a similar way) Interrupt Vector Table: maps interrupt vector numbers to the corresponding ISR addresses “ vector ” above specifies the offset in the interrupt vector table

10 Interrupt vector table Details vary for different CPU architectures, but the basic idea is the same: hardware interrupt signals are mapped onto entries in the IVT when interrupt occurs, the CPU uses the corresponding IVT entry to locate the ISR … … interrupt vector Hardware interrupt levels n n+1 n+2

11 Using C functions as ISRs Cannot vector directly to C functions – need to save the state of the interrupted task! RTOS builds a wrapper around ISR

12 Interrupt stack Special memory space storing the state of the CPU for the interrupted task allocating dynamic variables used by the ISR code Interrupt stack in RTOS use the same stack for all ISRs (where allowed by the CPU architecture) Where architecture does not support special ISR stack (e.g. Intel x86), use the stack of the interrupted task What is a potential problem here? How to address it?

13 Interrupt calls (summary)

14 Limitations of ISRs ISRs do not run in a regular task context: no task to block data normally stored in the task control block is unavailable Limitations: any calls requiring a task control block cannot be used (so, inspect details of a call in question!) cannot invoke routines that might cause the caller to block – no task to block, cannot block the OS kernel! e.g. cannot take semaphore (might block)

15 Limitation of ISRs (contd.) cannot call malloc() or free() – both of these take a semaphore (WHY?) cannot call routines that call malloc() or free() e.g. any creation or deletion routines. must not perform I/O through RTOS drivers: might block some require task control block to access file descriptors (e.g. the standard input/output/error)

16 Interrupt-to-task communication Once interrupt is detected and processed by the ISR, we need to inform the appropriate task about the external event The idea is the same as for inter-task communication … Tasks should be able to wait until an event occurs … except need to take into account the limitations of ISRs hardware ISR Application task Interrupt ?

17 Interrupt-to-task communication Shared memory ISR writes data into shared memory, e.g. set a flag value Semaphores ISR gives a semaphore. The task can try to take it. If there were no interrupt, the task will be blocked until the event occurs. Message queues ISR can send a message for a task to receive. Remember to use NO_WAIT though! If the queue is full, the message is discarded.

18 Debugging ISRs RTOS supplies a logging facility a logging task prints text messages to the system console specifically designed so that ISRs could use it common way to print messages from ISR... /* log a message */ msgLog(“some message”);... /* get messages from queue */... printf(msg);... message queue ISR:Logging task: Remember tLogTask?

19 Summary Interrupts allow computer systems to react on events from hardware while efficiently using CPU resources In real-time systems, can interfere with task scheduling. Solution – do minimum work in ISR, defer processing for a driver task Limitations on what you can do in ISRs