Interrupt Latency
• Real-time systems disable interrupts to
manipulate critical sections of code and enable interrupts when critical section has executed.
• The longer interrupts disabled, the higher the interrupt latency is.
interrupt latency =
Interrupt Response
• Interrupt response: the time between the reception of the interrupt and the start of the user code that handles the interrupt – accounts for all the overhead involved in
handling an interrupt
• For a foreground/background system and a non-preemptive kernel:
Response time = Interrupt latency + Time to save the CPU’s context
• For preemptive kernel
Response time = Interrupt latency + Time to save the CPU’s context + Execution time of the kernel ISR entry function
( to notify the kernel that an ISR is in progress and allows kernel to keep track of interrupt nesting, OSIntEnter( ) in uC/OS-2)
Interrupt Recovery
• The time required for the processor to return to the interrupted code.
• For a foreground/background system and a non-preemptive kernel:
Interrupt recovery
= Time to restore the CPU’s context
+ Time to execute the return from interrupt instruction
• For preemptive kernel:
Interrupt recovery
= Time to determine if a higher priority task is ready
+ Time to restore the CPU’s context of the highest priority task + Time to execute the return from interrupt instruction
ISR Processing Time
• ISRs should be as short as possible.
– there are no absolute limits on the amount of time for an ISR.
• If the ISR code is the most important code that needs to run at any given time, it could be as long as it needs to be.
• In most cases, the ISR should
– Recognize the interrupt– Obtain data or status from the interrupting device – Signal a task to perform a actual processing
• Overhead involved in signaling task
– the processing of the interruptBACKGROUND
CPU Context Saved Interrupt Request
Interrupt Latency
Interrupt Response Interrupt Recovery
BACKGROUND
ISR
User ISR Code TIME
CPU context restored
Interrupt latency, response, and recovery
(Foreground/Background)
Interrupt latency, response, and recovery
(Non-preemptive kernel)
TASK
CPU Context Saved Interrupt Request
Interrupt Latency
Interrupt Response Interrupt Recovery
TASK
ISR
User ISR Code TIME
CPU context restored
Interrupt latency, response, and recovery
(Preemptive kernel)
TASK
CPU Context Saved
Kernel's ISR Entry function Interrupt Request
Interrupt Latency Interrupt Response
Interrupt Recovery TASK
ISR
Kernel's ISR Exit function
User ISR Code TIME
CPU context restored
Kernel's ISR
Exit function CPU context
restored
TASK Interrupt Recovery
A
B
Non-Maskable Interrupts
• NMI’s can not be disabled.
– They are generally reserved for drastic events, such as the power-source is almost exhausted.
• You can not use kernel services to signal a task in ISR’s of NMI’s.
– Since interrupts can not be disabled in the ISR of an NMI.
– The size of global variable under this situation must be atomic. (i.e., byte, word, dword)
– Or, we can trigger another hardware interrupt which’s
ISR uses kernel services to signal the desired task.
Signaling a task from the ISR of an NMI
NMI
ISR ISR
Semaphore NMI Interrupt TASK
Issues interrupt by writing to an output port.
POST PEND
Non-Maskable Interrupts
Interrupt latency
= Time to execute longest instruction
+ Time to start executing the NMI ISR Interrupt response
= Interrupt latency
+ Time to save the CPU’s context Interrupt recovery
= Time to restore the CPU’s context
+ Time to execute the return from interrupt instruction
• NMI can still be disable by adding external circuits.
To Processor's NMI Input NMI Interrupt Source
Output Port
Disabling NMI’s
Clock Tick
• Clock tick is a periodically hardware event (interrupt) generated by a timer.
• The kernel utilize the timer to delay tasks and to periodically perform scheduling.
• The higher the tick rate,
– the better the responsiveness is.
– the better the schedulability is.
• Blocking due to clock tick resolution.
– the higher the overhead is.
Tick Interrupt
Tick ISR
All higher priority tasks
Delayed Task
t1
t2 t3
20 mS
(19 mS)
(17 mS) (27 mS)
Call to delay 1 tick (20 mS) Call to delay 1 tick (20 mS) Call to delay 1 tick (20 mS)
• A task delaying itself for one tick
• Higher priority tasks and ISRs execute prior to the task, which needs to delay for 1 tick
• A jitter occurs.
Tick Interrupt
Tick ISR
All higher priority tasks
Delayed Task
t1 t2 t3
20 mS
(6 mS) (19 mS) (27 mS)
Call to delay 1 tick (20 mS) Call to delay 1 tick (20 mS) Call to delay 1 tick (20 mS)
• The execution times of all higher priority tasks and ISRs are slightly less than 1 tick
• As a result, if you need to delay at least one tick, you must specify one extra tick
Tick Interrupt
Tick ISR
All higher priority tasks
Delayed Task
t1 t2
20 mS
(40 mS) (26 mS)
Call to delay 1 tick (20 mS) Call to delay 1 tick (20 mS)
• The execution times of all higher priority tasks and ISRs are more than 1 clock tick.
• The task that tries to delay for 1 tick actually executes two ticks later and violates its deadline.
Memory Requirements
• Most real-time applications are embedded systems. Memory requirements must be analyzable.
• A preemptible kernel requires more RAM/ROM space.
• Code size (ROM) = kernel size + application size
• RAM requirements can be significantly reduced if
– Stack size of every task can be differently specified
– A separate stack is used to handle ISR’s. (uC/OS-2 doesn’t, DOS does)
• RAM requirement = application requirement + kernel requirement + SUM(task stacks + MAX(ISR nesting))
• RAM requirement = application requirement + kernel requirement + SUM(task stacks) + MAX(ISR nesting)
– If a separate stack is prepared for ISR’s.
Memory Requirements
• We must be careful on the usages of tasks’ stacks:
– Large arrays and structures as local variables.
– Recursive function call.
– ISR nesting.
– Function calls with many arguments.
Advantages and Disadvantages of Real-Time Kernels
• A real-time kernel (RTOS) allows real-time applications to be designed and expanded easily.
– Functions can be added without requiring major changes to the software.
• The use of RTOS simplifies the design process by splitting the application code into separate tasks.
• With a preemptive RTOS, all time-critical events are handled as quickly and as efficiently as possible.
• An RTOS allows you to make better use of your resources by providing you with valuable services – semaphores, mailboxes, queues, time delays, timeouts, etc.
- Extra cost of the kernel.
- More ROM/RAM space.
- 2 to 4 percent additional CPU overhead.
- Cost of the RTOS: $70 ~ $30,000 !
- The maintenance cost: $100 ~ $5,000 per year !