Professional Documents
Culture Documents
Interrupt Routine of RTOS
Interrupt Routine of RTOS
INTRODUCTION
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.
SYNOPSIS
TERMINOLOGY
ARCHITECTURE
CONCLUSION
REFERENCES
1
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. 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. 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:
Symbo Meaning
l
CC: Context Create. Create context for ISR2. This typically involves creating a stack
frame and alerting the scheduler to schedule it next.
2
CR: Context Restore. Restore context of scheduled entity
ISR: Interrupt Service Routine. Traditional ISR, allowed to interact with application
threads through RTOS services.
ISR1: Interrupt Service Routine, Part-1. Similar to traditional ISR, but not allowed to
interact with RTOS.
ISR2: Interrupt Service Routine, Part-2. Scheduled entity run in a thread or super-thread
context. Allowed to interact with RTOS services and threads.
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.
3
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.
4
In both preemption and non-preemption cases, the segmented approach takes longer.
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
REFERENCES
http://rtos.com/articles/18835
https://www.csun.edu/~jeffw/Courses/COMP598EA/Lectures/OSServices/OSServ
ices_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-rtos-
environment---part-1
5
6