Interrupt Routines in An Rtos Environment

INTERRUPT ROUTINES IN AN RTOS ENVIRONMENT
INTRODUCTION
Like stand-alone systems, embedded applications running on top of real-time
operating systems (RTOSes) require Interrupt Service Routines (ISRs) to handle interrupts
generated by external events. External events can be caused by just about anything, from an
asynchronous character arrival on a UART to a periodic timer interrupt. ISRs have the
responsibility of acknowledging the hardware condition and provide the initial handling of
data sent or received as required by the interrupt. An ISR often is responsible for providing
the RTOS with information necessary to provide services to application threads. Examples
include moving data into a buffer for processing, adding an entry to a queue for processing,
setting a value to indicate that an event has occurred, and so on. Since application code
execution is interrupted (delayed) during the execution of an ISR, most applications minimize
the amount of code in the ISR and rely instead on non-ISR code (an application Thread or
Task) to complete the processing. This allows the highest priority application code to be
executed as quickly as possible, and delayed as little as possible, even in situations with
intense interrupt activity.
RTOS Interrupt Architectures
A fundamental challenge in RTOS design is supporting asynchronous access to
internal RTOS data structures by interrupt routines and RTOS services. It cannot be allowed
that, while modifying a data structure, a service or ISR gets interrupted and a different service
or ISR makes unrelated modifications to the same structure, leaving it in a changed state for
the original code to (unknowingly) continue modifying. The results can be catastrophic. All
RTOSes must address this challenge and prevent multiple ISRs (or system calls) from
modifying the same structure at the same time.
There are at least two approaches, one used by the majority of RTOSes, and another
used by a few. The more popular approach is to briefly lockout interrupts while an ISR or
system service is modifying critical data structures inside the RTOS. This reliably prevents
any other program from jumping in and making uncoordinated changes to the critical area
being used by the executing code.
Another, less popular approach is not to disable interrupts in system service routines,
but instead (by rule or convention) not allow any asynchronous access to critical data
structures by ISRs or other service calls. Service call access to critical data structures from an
ISR is deferred to a secondary routine we denote ISR2, which gets executed along with
application threads under scheduler control. This approach also reliably prevents interference
with the actions of an executing system service call, by not allowing any threads or ISR2
routines, which might make system service calls, to execute until processing of critical data
structures is completed. This approach is called a Segmented Interrupt Architecture,
because it breaks up the processing required in response to an interrupt into multiple (usually
2) segments executed at different priorities. In this paper, we examine the performance
implications of each approach on real-time system responsiveness.
TERMINOLOGY
The following is a list of symbols used to represent the processing performed in each
type of RTOS interrupt architecture:
Symbol Meaning
CC:
Context Create. Create context for ISR2. This typically involves creating a stack
frame and alerting the scheduler to schedule it next.
CR:
Context Restore. Restore context of scheduled entity
CS:
Context Save. Saves the context of the running thread.

Interrupt Dispatcher. Applicable in single interrupt vector architectures like
ID:
PowerPC, MIPS, and ARM. On architectures like ColdFire, this item is done in
hardware.
ISR:
ISR1:
ISR2:
Interrupt Service Routine. Traditional ISR, allowed to interact with application

threads through RTOS services.
Interrupt Service Routine, Part-1. Similar to traditional ISR, but not allowed to
interact with RTOS.
Interrupt Service Routine, Part-2. Scheduled entity run in a thread or super-thread
context. Allowed to interact with RTOS services and threads.
ITRA: Interrupted Thread Running Again.

L:
Lockout. Interrupt lockout time.

2
S:
Scheduler. Schedule the most important thread or ISR2.
NT:
New Thread running.
1:
Start of ISR processing.
2:
End of ISR processing.
3:
New thread running preemption case.
4:
Return to interrupted thread.
BOLD: Items that are purely application code.

The Unified Interrupt Architecture
RTOSes that employ a unified architecture treat the ISR no differently than an ISR in
a stand-alone application. In this architecture, the ISR is allowed to make RTOS calls to
modify kernel data structures and to interact with application threads and other resources. To
do this, the RTOS disables interrupts over certain (typically very short) code segments,
thereby protecting common resources against asynchronous access from multiple ISRs or
system service calls.
ARCHITECTURE
RTOSes that do not disable interrupts during system services cannot make
modifications to RTOS data structures from within an ISR, because the ISR might be
interrupted by another interrupt, which then might attempt to use the same data structure. To
prevent this, segmented architectures basically disable the application scheduler, and divide
the interrupt processing into two (or more) pieces.
The first piece (ISR1) behaves like a traditional ISR but performs no interaction with
RTOS data structures. This enables it to run with interrupts enabled. The second piece (ISR2)
is a scheduled entity that makes all necessary RTOS data structure updates at the
application level, and is invoked through the processing in ISR1. Finally, application thread
processing can be performed once both ISR1 and ISR2 have been completed. This effectively
disables applications while ISR1 and ISR2 are operating, and defers context switching while
RTOS data structures are being modified.
The performance observations in this section are somewhat abstract. The amount of
time for RTOS performance objects (e.g. CS, CC, CR, etc.) on most RTOS products will be
somewhat similar. However, the segmented architecture products are typically larger
operating systems so their actual processing times for each RTOS performance object would
most likely be greater than a simpler unified interrupt architecture RTOS. In addition, if
memory protection or virtual addresses are supported, the time required to process an RTOS
block will most definitely be greater. The succeeding comparisons assume that the various
RTOSes take the same amount of time to perform the same RTOS operation. It is further
assumed that the time to perform ISR processing in the unified approach is equal to the sum
of the times to perform ISR1 and ISR2 in the segmented approach.
In both preemption and non-preemption cases, the segmented approach takes longer.
TOTAL SYSTEM OVERHEAD COMPARISON
Ironically, as can be seen in Figure-3, the total system overhead is greater in the RTOS
with a segmented interrupt architecture. In both the non-preemption and preemption cases the
segmented interrupt architecture RTOS introduces an additional (1*CS, 1*CR, 2*S, and
1*CC) of overhead.
CONCLUSION
The segmented RTOS architecture is claimed to have an advantage in its ability to
respond to interrupts. After all, if interrupts are disabled, response should be negatively
impacted, right? The whole idea behind not disabling interrupts is to make interrupt response
faster. However, while it sounds good, there are several practical problems introduced by this
approach. Although the segmented interrupt RTOS doesnt disable interrupts when
manipulating RTOS data structures inside service routines, the hardware itself does when
4
processing other interrupts. So the worst case L in the segmented interrupt RTOS is actually
the time interrupts are locked out during the processing of another interrupt.
REFERENCES
http://rtos.com/articles/18835
https://www.csun.edu/~jeffw/Courses/COMP598EA/Lectures/OSServices/OSService
s_html/text20.html
http://stackoverflow.com/questions/536506/how-do-real-time-operating-systems-work
http://www.slideshare.net/JOLLUSUDARSHANREDDY/munni-43871570
https://sites.google.com/site/rtosmifmim/home/interrupt-routines-in-an-rtosenvironment---part-1

Interrupt Routines in An Rtos Environment

Uploaded by

Copyright:

Available Formats

Interrupt Routines in An Rtos Environment

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Interrupt Routines in An Rtos Environment

Uploaded by

Copyright:

Available Formats

INTERRUPT ROUTINES IN AN RTOS ENVIRONMENT

Context Restore. Restore context of scheduled entity

Context Save. Saves the context of the running thread.

Interrupt Service Routine. Traditional ISR, allowed to interact with application

ITRA: Interrupted Thread Running Again.

Lockout. Interrupt lockout time.

Scheduler. Schedule the most important thread or ISR2.

New Thread running.

Start of ISR processing.

End of ISR processing.

New thread running preemption case.

Return to interrupted thread.

BOLD: Items that are purely application code.

You might also like