path: root/doc/supplements/template/intr_NOTIMES.t
diff options
authorJoel Sherrill <>1998-10-19 13:01:33 +0000
committerJoel Sherrill <>1998-10-19 13:01:33 +0000
commitad0f33160f3bf7c9322c8b145e415687b819a917 (patch)
tree91860772d0f5f6ef662ad36bbbe36c5b39bcc2ea /doc/supplements/template/intr_NOTIMES.t
parent887173dd8cc92dbd96a441f1b742da3dbc197166 (diff)
Added chapter.
Diffstat (limited to 'doc/supplements/template/intr_NOTIMES.t')
1 files changed, 196 insertions, 0 deletions
diff --git a/doc/supplements/template/intr_NOTIMES.t b/doc/supplements/template/intr_NOTIMES.t
new file mode 100644
index 0000000000..deb645781a
--- /dev/null
+++ b/doc/supplements/template/intr_NOTIMES.t
@@ -0,0 +1,196 @@
+@c Interrupt Stack Frame Picture
+@c COPYRIGHT (c) 1988-1998.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c $Id$
+@chapter Interrupt Processing
+@section Introduction
+Different types of processors respond to the
+occurrence of an interrupt in its own unique fashion. In
+addition, each processor type provides a control mechanism to
+allow for the proper handling of an interrupt. The processor
+dependent response to the interrupt modifies the current
+execution state and results in a change in the execution stream.
+Most processors require that an interrupt handler utilize some
+special control mechanisms to return to the normal processing
+stream. Although RTEMS hides many of the processor dependent
+details of interrupt processing, it is important to understand
+how the RTEMS interrupt manager is mapped onto the processor's
+unique architecture. Discussed in this chapter are the XXX's
+interrupt response and control mechanisms as they pertain to
+@section Vectoring of an Interrupt Handler
+Depending on whether or not the particular CPU
+supports a separate interrupt stack, the XXX family has two
+different interrupt handling models.
+@subsection Models Without Separate Interrupt Stacks
+Upon receipt of an interrupt the XXX family
+members without separate interrupt stacks automatically perform
+the following actions:
+@itemize @bullet
+@item To Be Written
+@end itemize
+@subsection Models With Separate Interrupt Stacks
+Upon receipt of an interrupt the XXX family
+members with separate interrupt stacks automatically perform the
+following actions:
+@itemize @bullet
+@item saves the current status register (SR),
+@item clears the master/interrupt (M) bit of the SR to
+indicate the switch from master state to interrupt state,
+@item sets the privilege mode to supervisor,
+@item suppresses tracing,
+@item sets the interrupt mask level equal to the level of the
+interrupt being serviced,
+@item pushes an interrupt stack frame (ISF), which includes
+the program counter (PC), the status register (SR), and the
+format/exception vector offset (FVO) word, onto the supervisor
+and interrupt stacks,
+@item switches the current stack to the interrupt stack and
+vectors to an interrupt service routine (ISR). If the ISR was
+installed with the interrupt_catch directive, then the RTEMS
+interrupt handler will begin execution. The RTEMS interrupt
+handler saves all registers which are not preserved according to
+the calling conventions and invokes the application's ISR.
+@end itemize
+A nested interrupt is processed similarly by these
+CPU models with the exception that only a single ISF is placed
+on the interrupt stack and the current stack need not be
+The FVO word in the Interrupt Stack Frame is examined
+by RTEMS to determine when an outer most interrupt is being
+exited. Since the FVO is used by RTEMS for this purpose, the
+user application code MUST NOT modify this field.
+The following shows the Interrupt Stack Frame for
+XXX CPU models with separate interrupt stacks:
+@ifset use-ascii
+ +----------------------+
+ | Status Register | 0x0
+ +----------------------+
+ | Program Counter High | 0x2
+ +----------------------+
+ | Program Counter Low | 0x4
+ +----------------------+
+ | Format/Vector Offset | 0x6
+ +----------------------+
+@end group
+@end example
+@end ifset
+@ifset use-tex
+@sp 1
+\hbox to 2.00in{\enskip\hfil#\hfil}&
+\hbox to 0.50in{\enskip\hfil#\hfil}
+& Status Register && 0x0\cr
+& Program Counter High && 0x2\cr
+& Program Counter Low && 0x4\cr
+& Format/Vector Offset && 0x6\cr
+@end tex
+@end ifset
+@ifset use-html
+<TR><TD ALIGN=center><STRONG>Status Register</STRONG></TD>
+ <TD ALIGN=center>0x0</TD></TR>
+<TR><TD ALIGN=center><STRONG>Program Counter High</STRONG></TD>
+ <TD ALIGN=center>0x2</TD></TR>
+<TR><TD ALIGN=center><STRONG>Program Counter Low</STRONG></TD>
+ <TD ALIGN=center>0x4</TD></TR>
+<TR><TD ALIGN=center><STRONG>Format/Vector Offset</STRONG></TD>
+ <TD ALIGN=center>0x6</TD></TR>
+ </TABLE>
+@end html
+@end ifset
+@section Interrupt Levels
+Eight levels (0-7) of interrupt priorities are
+supported by XXX family members with level seven (7) being
+the highest priority. Level zero (0) indicates that interrupts
+are fully enabled. Interrupt requests for interrupts with
+priorities less than or equal to the current interrupt mask
+level are ignored.
+Although RTEMS supports 256 interrupt levels, the
+XXX family only supports eight. RTEMS interrupt levels 0
+through 7 directly correspond to XXX interrupt levels. All
+other RTEMS interrupt levels are undefined and their behavior is
+@section Disabling of Interrupts by RTEMS
+During the execution of directive calls, critical
+sections of code may be executed. When these sections are
+encountered, RTEMS disables interrupts to level seven (7) before
+the execution of this section and restores them to the previous
+level upon completion of the section. RTEMS has been optimized
+to insure that interrupts are disabled for less than
+zero wait states. These numbers will vary based the
+number of wait states and processor speed present on the target board.
+[NOTE: The maximum period with interrupts disabled is hand calculated. This
+calculation was last performed for Release
+Non-maskable interrupts (NMI) cannot be disabled, and
+ISRs which execute at this level MUST NEVER issue RTEMS system
+calls. If a directive is invoked, unpredictable results may
+occur due to the inability of RTEMS to protect its critical
+sections. However, ISRs that make no system calls may safely
+execute as non-maskable interrupts.
+@section Interrupt Stack
+RTEMS allocates the interrupt stack from the
+Workspace Area. The amount of memory allocated for the
+interrupt stack is determined by the interrupt_stack_size field
+in the CPU Configuration Table. During the initialization
+process, RTEMS will install its interrupt stack.
+The XXX port of RTEMS supports a software managed
+dedicated interrupt stack on those CPU models which do not
+support a separate interrupt stack in hardware.