summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorRalf Corsepius <ralf.corsepius@rtems.org>2003-01-22 05:53:29 +0000
committerRalf Corsepius <ralf.corsepius@rtems.org>2003-01-22 05:53:29 +0000
commita454e88d34be216c74e26fa196cc861fe09a1f03 (patch)
tree2e5e67bc062ba7033ee114d438692e8f635a5664 /doc
parent4b1f9242ae2fb343ee2c91a5ced93cb03ce3b929 (diff)
downloadrtems-a454e88d34be216c74e26fa196cc861fe09a1f03.tar.bz2
2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
* wksheets.texi: Remove from CVS. * timing.texi: Remove from CVS.
Diffstat (limited to '')
-rw-r--r--doc/supplements/arm/ChangeLog5
-rw-r--r--doc/supplements/arm/timing.texi460
-rw-r--r--doc/supplements/arm/wksheets.texi437
3 files changed, 5 insertions, 897 deletions
diff --git a/doc/supplements/arm/ChangeLog b/doc/supplements/arm/ChangeLog
index 7f92db7674..b2dc56795a 100644
--- a/doc/supplements/arm/ChangeLog
+++ b/doc/supplements/arm/ChangeLog
@@ -1,3 +1,8 @@
+2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
+
+ * wksheets.texi: Remove from CVS.
+ * timing.texi: Remove from CVS.
+
2003-01-21 Joel Sherrill <joel@OARcorp.com>
* stamp-vti, version.texi: Regenerated.
diff --git a/doc/supplements/arm/timing.texi b/doc/supplements/arm/timing.texi
deleted file mode 100644
index 302a1391a8..0000000000
--- a/doc/supplements/arm/timing.texi
+++ /dev/null
@@ -1,460 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-
-@node Timing Specification, Timing Specification Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top
-
-@chapter Timing Specification
-@ifinfo
-@menu
-* Timing Specification Introduction::
-* Timing Specification Philosophy::
-* Timing Specification Methodology::
-@end menu
-@end ifinfo
-
-
-@node Timing Specification Introduction, Timing Specification Philosophy, Timing Specification, Timing Specification
-
-@section Introduction
-
-This chapter provides information pertaining to the
-measurement of the performance of RTEMS, the methods of
-gathering the timing data, and the usefulness of the data. Also
-discussed are other time critical aspects of RTEMS that affect
-an applications design and ultimate throughput. These aspects
-include determinancy, interrupt latency and context switch times.
-
-
-@node Timing Specification Philosophy, Timing Specification Determinancy, Timing Specification Introduction, Timing Specification
-
-@section Philosophy
-@ifinfo
-@menu
-* Timing Specification Determinancy::
-* Timing Specification Interrupt Latency::
-* Timing Specification Context Switch Time::
-* Timing Specification Directive Times::
-@end menu
-@end ifinfo
-
-Benchmarks are commonly used to evaluate the
-performance of software and hardware. Benchmarks can be an
-effective tool when comparing systems. Unfortunately,
-benchmarks can also be manipulated to justify virtually any
-claim. Benchmarks of real-time executives are difficult to
-evaluate for a variety of reasons. Executives vary in the
-robustness of features and options provided. Even when
-executives compare favorably in functionality, it is quite
-likely that different methodologies were used to obtain the
-timing data. Another problem is that some executives provide
-times for only a small subset of directives, This is typically
-justified by claiming that these are the only time-critical
-directives. The performance of some executives is also very
-sensitive to the number of objects in the system. To obtain any
-measure of usefulness, the performance information provided for
-an executive should address each of these issues.
-
-When evaluating the performance of a real-time
-executive, one typically considers the following areas:
-determinancy, directive times, worst case interrupt latency, and
-context switch time. Unfortunately, these areas do not have
-standard measurement methodologies. This allows vendors to
-manipulate the results such that their product is favorably
-represented. We have attempted to provide useful and meaningful
-timing information for RTEMS. To insure the usefulness of our
-data, the methodology and definitions used to obtain and
-describe the data are also documented.
-
-
-@node Timing Specification Determinancy, Timing Specification Interrupt Latency, Timing Specification Philosophy, Timing Specification Philosophy
-
-@subsection Determinancy
-
-The correctness of data in a real-time system must
-always be judged by its timeliness. In many real-time systems,
-obtaining the correct answer does not necessarily solve the
-problem. For example, in a nuclear reactor it is not enough to
-determine that the core is overheating. This situation must be
-detected and acknowledged early enough that corrective action
-can be taken and a meltdown avoided.
-
-Consequently, a system designer must be able to
-predict the worst-case behavior of the application running under
-the selected executive. In this light, it is important that a
-real-time system perform consistently regardless of the number
-of tasks, semaphores, or other resources allocated. An
-important design goal of a real-time executive is that all
-internal algorithms be fixed-cost. Unfortunately, this goal is
-difficult to completely meet without sacrificing the robustness
-of the executive's feature set.
-
-Many executives use the term deterministic to mean
-that the execution times of their services can be predicted.
-However, they often provide formulas to modify execution times
-based upon the number of objects in the system. This usage is
-in sharp contrast to the notion of deterministic meaning fixed
-cost.
-
-Almost all RTEMS directives execute in a fixed amount
-of time regardless of the number of objects present in the
-system. The primary exception occurs when a task blocks while
-acquiring a resource and specifies a non-zero timeout interval.
-
-Other exceptions are message queue broadcast,
-obtaining a variable length memory block, object name to ID
-translation, and deleting a resource upon which tasks are
-waiting. In addition, the time required to service a clock tick
-interrupt is based upon the number of timeouts and other
-"events" which must be processed at that tick. This second
-group is composed primarily of capabilities which are inherently
-non-deterministic but are infrequently used in time critical
-situations. The major exception is that of servicing a clock
-tick. However, most applications have a very small number of
-timeouts which expire at exactly the same millisecond (usually
-none, but occasionally two or three).
-
-
-@node Timing Specification Interrupt Latency, Timing Specification Context Switch Time, Timing Specification Determinancy, Timing Specification Philosophy
-
-@subsection Interrupt Latency
-
-Interrupt latency is the delay between the CPU's
-receipt of an interrupt request and the execution of the first
-application-specific instruction in an interrupt service
-routine. Interrupts are a critical component of most real-time
-applications and it is critical that they be acted upon as
-quickly as possible.
-
-Knowledge of the worst case interrupt latency of an
-executive aids the application designer in determining the
-maximum period of time between the generation of an interrupt
-and an interrupt handler responding to that interrupt. The
-interrupt latency of an system is the greater of the executive's
-and the applications's interrupt latency. If the application
-disables interrupts longer than the executive, then the
-application's interrupt latency is the system's worst case
-interrupt disable period.
-
-The worst case interrupt latency for a real-time
-executive is based upon the following components:
-
-@itemize @bullet
-@item the longest period of time interrupts are disabled
-by the executive,
-
-@item the overhead required by the executive at the
-beginning of each ISR,
-
-@item the time required for the CPU to vector the
-interrupt, and
-
-@item for some microprocessors, the length of the longest
-instruction.
-@end itemize
-
-The first component is irrelevant if an interrupt
-occurs when interrupts are enabled, although it must be included
-in a worst case analysis. The third and fourth components are
-particular to a CPU implementation and are not dependent on the
-executive. The fourth component is ignored by this document
-because most applications use only a subset of a
-microprocessor's instruction set. Because of this the longest
-instruction actually executed is application dependent. The
-worst case interrupt latency of an executive is typically
-defined as the sum of components (1) and (2). The second
-component includes the time necessry for RTEMS to save registers
-and vector to the user-defined handler. RTEMS includes the
-third component, the time required for the CPU to vector the
-interrupt, because it is a required part of any interrupt.
-
-Many executives report the maximum interrupt disable
-period as their interrupt latency and ignore the other
-components. This results in very low worst-case interrupt
-latency times which are not indicative of actual application
-performance. The definition used by RTEMS results in a higher
-interrupt latency being reported, but accurately reflects the
-longest delay between the CPU's receipt of an interrupt request
-and the execution of the first application-specific instruction
-in an interrupt service routine.
-
-The actual interrupt latency times are reported in
-the Timing Data chapter of this supplement.
-
-
-@node Timing Specification Context Switch Time, Timing Specification Directive Times, Timing Specification Interrupt Latency, Timing Specification Philosophy
-
-@subsection Context Switch Time
-
-An RTEMS context switch is defined as the act of
-taking the CPU from the currently executing task and giving it
-to another task. This process involves the following components:
-
-@itemize @bullet
-@item Saving the hardware state of the current task.
-
-@item Optionally, invoking the TASK_SWITCH user extension.
-
-@item Restoring the hardware state of the new task.
-@end itemize
-
-RTEMS defines the hardware state of a task to include
-the CPU's data registers, address registers, and, optionally,
-floating point registers.
-
-Context switch time is often touted as a performance
-measure of real-time executives. However, a context switch is
-performed as part of a directive's actions and should be viewed
-as such when designing an application. For example, if a task
-is unable to acquire a semaphore and blocks, a context switch is
-required to transfer control from the blocking task to a new
-task. From the application's perspective, the context switch is
-a direct result of not acquiring the semaphore. In this light,
-the context switch time is no more relevant than the performance
-of any other of the executive's subroutines which are not
-directly accessible by the application.
-
-In spite of the inappropriateness of using the
-context switch time as a performance metric, RTEMS context
-switch times for floating point and non-floating points tasks
-are provided for comparison purposes. Of the executives which
-actually support floating point operations, many do not report
-context switch times for floating point context switch time.
-This results in a reported context switch time which is
-meaningless for an application with floating point tasks.
-
-The actual context switch times are reported in the
-Timing Data chapter of this supplement.
-
-
-@node Timing Specification Directive Times, Timing Specification Methodology, Timing Specification Context Switch Time, Timing Specification Philosophy
-
-@subsection Directive Times
-
-Directives are the application's interface to the
-executive, and as such their execution times are critical in
-determining the performance of the application. For example, an
-application using a semaphore to protect a critical data
-structure should be aware of the time required to acquire and
-release a semaphore. In addition, the application designer can
-utilize the directive execution times to evaluate the
-performance of different synchronization and communication
-mechanisms.
-
-The actual directive execution times are reported in
-the Timing Data chapter of this supplement.
-
-
-@node Timing Specification Methodology, Timing Specification Software Platform, Timing Specification Directive Times, Timing Specification
-
-@section Methodology
-@ifinfo
-@menu
-* Timing Specification Software Platform::
-* Timing Specification Hardware Platform::
-* Timing Specification What is measured?::
-* Timing Specification What is not measured?::
-* Timing Specification Terminology::
-@end menu
-@end ifinfo
-
-
-@node Timing Specification Software Platform, Timing Specification Hardware Platform, Timing Specification Methodology, Timing Specification Methodology
-
-@subsection Software Platform
-
-The RTEMS timing suite is written in C. The overhead
-of passing arguments to RTEMS by C is not timed. The times
-reported represent the amount of time from entering to exiting
-RTEMS.
-
-The tests are based upon one of two execution models:
-(1) single invocation times, and (2) average times of repeated
-invocations. Single invocation times are provided for
-directives which cannot easily be invoked multiple times in the
-same scenario. For example, the times reported for entering and
-exiting an interrupt service routine are single invocation
-times. The second model is used for directives which can easily
-be invoked multiple times in the same scenario. For example,
-the times reported for semaphore obtain and semaphore release
-are averages of multiple invocations. At least 100 invocations
-are used to obtain the average.
-
-
-@node Timing Specification Hardware Platform, Timing Specification What is measured?, Timing Specification Software Platform, Timing Specification Methodology
-
-@subsection Hardware Platform
-
-Since RTEMS supports a variety of processors, the
-hardware platform used to gather the benchmark times must also
-vary. Therefore, for each processor supported the hardware
-platform must be defined. Each definition will include a brief
-description of the target hardware platform including the clock
-speed, memory wait states encountered, and any other pertinent
-information. This definition may be found in the processor
-dependent timing data chapter within this supplement.
-
-
-@node Timing Specification What is measured?, Timing Specification What is not measured?, Timing Specification Hardware Platform, Timing Specification Methodology
-
-@subsection What is measured?
-
-An effort was made to provide execution times for a
-large portion of RTEMS. Times were provided for most directives
-regardless of whether or not they are typically used in time
-critical code. For example, execution times are provided for
-all object create and delete directives, even though these are
-typically part of application initialization.
-
-The times include all RTEMS actions necessary in a
-particular scenario. For example, all times for blocking
-directives include the context switch necessary to transfer
-control to a new task. Under no circumstances is it necessary
-to add context switch time to the reported times.
-
-The following list describes the objects created by
-the timing suite:
-
-@itemize @bullet
-@item All tasks are non-floating point.
-
-@item All tasks are created as local objects.
-
-@item No timeouts are used on blocking directives.
-
-@item All tasks wait for objects in FIFO order.
-
-@end itemize
-
-In addition, no user extensions are configured.
-
-
-@node Timing Specification What is not measured?, Timing Specification Terminology, Timing Specification What is measured?, Timing Specification Methodology
-
-@subsection What is not measured?
-
-The times presented in this document are not intended
-to represent best or worst case times, nor are all directives
-included. For example, no times are provided for the initialize
-executive and fatal_error_occurred directives. Other than the
-exceptions detailed in the Determinancy section, all directives
-will execute in the fixed length of time given.
-
-Other than entering and exiting an interrupt service
-routine, all directives were executed from tasks and not from
-interrupt service routines. Directives invoked from ISRs, when
-allowable, will execute in slightly less time than when invoked
-from a task because rescheduling is delayed until the interrupt
-exits.
-
-
-@node Timing Specification Terminology, MYBSP Timing Data, Timing Specification What is not measured?, Timing Specification Methodology
-
-@subsection Terminology
-
-The following is a list of phrases which are used to
-distinguish individual execution paths of the directives taken
-during the RTEMS performance analysis:
-
-@table @b
-@item another task
-The directive was performed
-on a task other than the calling task.
-
-@item available
-A task attempted to obtain a resource and
-immediately acquired it.
-
-@item blocked task
-The task operated upon by the
-directive was blocked waiting for a resource.
-
-@item caller blocks
-The requested resoure was not
-immediately available and the calling task chose to wait.
-
-@item calling task
-The task invoking the directive.
-
-@item messages flushed
-One or more messages was flushed
-from the message queue.
-
-@item no messages flushed
-No messages were flushed from
-the message queue.
-
-@item not available
-A task attempted to obtain a resource
-and could not immediately acquire it.
-
-@item no reschedule
-The directive did not require a
-rescheduling operation.
-
-@item NO_WAIT
-A resource was not available and the
-calling task chose to return immediately via the NO_WAIT option
-with an error.
-
-@item obtain current
-The current value of something was
-requested by the calling task.
-
-@item preempts caller
-The release of a resource caused a
-task of higher priority than the calling to be readied and it
-became the executing task.
-
-@item ready task
-The task operated upon by the directive
-was in the ready state.
-
-@item reschedule
-The actions of the directive
-necessitated a rescheduling operation.
-
-@item returns to caller
-The directive succeeded and
-immediately returned to the calling task.
-
-@item returns to interrupted task
-The instructions
-executed immediately following this interrupt will be in the
-interrupted task.
-
-@item returns to nested interrupt
-The instructions
-executed immediately following this interrupt will be in a
-previously interrupted ISR.
-
-@item returns to preempting task
-The instructions
-executed immediately following this interrupt or signal handler
-will be in a task other than the interrupted task.
-
-@item signal to self
-The signal set was sent to the
-calling task and signal processing was enabled.
-
-@item suspended task
-The task operated upon by the
-directive was in the suspended state.
-
-@item task readied
-The release of a resource caused a
-task of lower or equal priority to be readied and the calling
-task remained the executing task.
-
-@item yield
-The act of attempting to voluntarily release
-the CPU.
-
-@end table
-
-
diff --git a/doc/supplements/arm/wksheets.texi b/doc/supplements/arm/wksheets.texi
deleted file mode 100644
index 0732f86151..0000000000
--- a/doc/supplements/arm/wksheets.texi
+++ /dev/null
@@ -1,437 +0,0 @@
-@c ****** This comment is here to remind you not to edit the wksheets.t
-@c ****** in any directory but common.
-@c
-@c Figures ...
-@c RTEMS RAM Workspace Worksheet
-@c RTEMS Code Space Worksheet
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-
-@node Memory Requirements, Memory Requirements Introduction, Processor Dependent Information Table CPU Dependent Information Table, Top
-
-@chapter Memory Requirements
-@ifinfo
-@menu
-* Memory Requirements Introduction::
-* Memory Requirements Data Space Requirements::
-* Memory Requirements Minimum and Maximum Code Space Requirements::
-* Memory Requirements RTEMS Code Space Worksheet::
-* Memory Requirements RTEMS RAM Workspace Worksheet::
-@end menu
-@end ifinfo
-
-
-@node Memory Requirements Introduction, Memory Requirements Data Space Requirements, Memory Requirements, Memory Requirements
-
-@section Introduction
-
-Memory is typically a limited resource in real-time
-embedded systems, therefore, RTEMS can be configured to utilize
-the minimum amount of memory while meeting all of the
-applications requirements. Worksheets are provided which allow
-the RTEMS application developer to determine the amount of RTEMS
-code and RAM workspace which is required by the particular
-configuration. Also provided are the minimum code space,
-maximum code space, and the constant data space required by
-RTEMS.
-
-
-@node Memory Requirements Data Space Requirements, Memory Requirements Minimum and Maximum Code Space Requirements, Memory Requirements Introduction, Memory Requirements
-
-@section Data Space Requirements
-
-RTEMS requires a small amount of memory for its
-private variables. This data area must be in RAM and is
-separate from the RTEMS RAM Workspace. The following
-illustrates the data space required for all configurations of
-RTEMS:
-
-@itemize @bullet
-@item Data Space: na
-@end itemize
-
-
-@node Memory Requirements Minimum and Maximum Code Space Requirements, Memory Requirements RTEMS Code Space Worksheet, Memory Requirements Data Space Requirements, Memory Requirements
-
-@section Minimum and Maximum Code Space Requirements
-
-A maximum configuration of RTEMS includes the core
-and all managers, including the multiprocessing manager.
-Conversely, a minimum configuration of RTEMS includes only the
-core and the following managers: initialization, task, interrupt
-and fatal error. The following illustrates the code space
-required by these configurations of RTEMS:
-
-@itemize @bullet
-@item Minimum Configuration: na
-@item Maximum Configuration: na
-@end itemize
-
-
-@node Memory Requirements RTEMS Code Space Worksheet, Memory Requirements RTEMS RAM Workspace Worksheet, Memory Requirements Minimum and Maximum Code Space Requirements, Memory Requirements
-
-@section RTEMS Code Space Worksheet
-
-The RTEMS Code Space Worksheet is a tool provided to
-aid the RTEMS application designer to accurately calculate the
-memory required by the RTEMS run-time environment. RTEMS allows
-the custom configuration of the executive by optionally
-excluding managers which are not required by a particular
-application. This worksheet provides the included and excluded
-size of each manager in tabular form allowing for the quick
-calculation of any custom configuration of RTEMS. The RTEMS
-Code Space Worksheet is below:
-
-@ifset use-ascii
-@page
-@end ifset
-@ifset use-tex
-@page
-@end ifset
-
-@page
-@center @b{RTEMS Code Space Worksheet}
-@sp 1
-
-@ifset use-ascii
-
-The following is a list of the components of the RTEMS code space. The first
-number in parentheses is the size when the component is included,
-while the second number indicates its size when not included. If the second
-number is "NA", then the component must always be included.
-
-@itemize @bullet
-@item Core (na, NA)
-@item Initialization (na, NA)
-@item Task (na, NA)
-@item Interrupt (na, NA)
-@item Clock (na, NA)
-@item Timer (na, na)
-@item Semaphore (na, na)
-@item Message (na, na)
-@item Event (na, na)
-@item Signal (na, na)
-@item Partition (na, na)
-@item Region (na, na)
-@item Dual Ported Memory (na, na)
-@item I/O (na, na)
-@item Fatal Error (na, NA)
-@item Rate Monotonic (na, na)
-@item Multiprocessing (na, na)
-@end itemize
-@end ifset
-
-@ifset use-tex
-
-@tex
-\line{\hskip 0.50in\vbox{\offinterlineskip\halign{
-\vrule\strut#&
-\hbox to 2.25in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.00in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.00in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.25in{\enskip\hfil#\hfil}&
-\vrule#\cr
-\noalign{\hrule}
-&\bf Component && \bf Included && \bf Not Included && \bf Size &\cr\noalign{\hrule}
-&Core && na && NA && &\cr\noalign{\hrule}
-&Initialization && na && NA && &\cr\noalign{\hrule}
-&Task && na && NA && &\cr\noalign{\hrule}
-&Interrupt && na && NA && &\cr\noalign{\hrule}
-&Clock && na && NA && &\cr\noalign{\hrule}
-&Timer && na && na && &\cr\noalign{\hrule}
-&Semaphore && na && na && &\cr\noalign{\hrule}
-&Message && na && na && &\cr\noalign{\hrule}
-&Event && na && na && &\cr\noalign{\hrule}
-&Signal && na && na && &\cr\noalign{\hrule}
-&Partition && na && na && &\cr\noalign{\hrule}
-&Region && na && na && &\cr\noalign{\hrule}
-&Dual Ported Memory && na && na && &\cr\noalign{\hrule}
-&I/O && na && na && &\cr\noalign{\hrule}
-&Fatal Error && na && NA && &\cr\noalign{\hrule}
-&Rate Monotonic && na && na && &\cr\noalign{\hrule}
-&Multiprocessing && na && na && &\cr\noalign{\hrule}
-&\multispan 5 \bf\hfil Total Code Space Requirements\qquad\hfil&&&\cr\noalign{\hrule}
-}}\hfil}
-@end tex
-@end ifset
-
-@ifset use-html
-@html
-<CENTER>
- <TABLE COLS=4 WIDTH="80%" BORDER=2>
-<TR><TD ALIGN=center><STRONG>Component</STRONG></TD>
- <TD ALIGN=center><STRONG>Included</STRONG></TD>
- <TD ALIGN=center><STRONG>Not Included</STRONG></TD>
- <TD ALIGN=center><STRONG>Size</STRONG></TD></TR>
-<TR><TD ALIGN=center>Core</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>NA</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Initialization</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>NA</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Task</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>NA</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Interrupt</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>NA</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Clock</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>NA</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Timer</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Semaphore</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Message</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Event</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Signal</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Partition</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Region</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Dual Ported Memory</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>I/O</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Fatal Error</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>NA</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Rate Monotonic</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center>Multiprocessing</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>na</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=center COLSPAN=3>
- <STRONG>Total Code Space Requirements</STRONG></TD>
- <TD><BR></TD></TR>
- </TABLE>
-</CENTER>
-@end html
-@end ifset
-
-@page
-
-@c ****** Next node is set by a sed script in the document Makefile.
-@c ****** This comment is here to remind you not to edit the wksheets.t
-@c ****** in any directory but common.
-
-
-@node Memory Requirements RTEMS RAM Workspace Worksheet, Timing Specification, Memory Requirements RTEMS Code Space Worksheet, Memory Requirements
-
-@section RTEMS RAM Workspace Worksheet
-
-The RTEMS RAM Workspace Worksheet is a tool provided
-to aid the RTEMS application designer to accurately calculate
-the minimum memory block to be reserved for RTEMS use. This
-worksheet provides equations for calculating the amount of
-memory required based upon the number of objects configured,
-whether for single or multiple processor versions of the
-executive. This information is presented in tabular form, along
-with the fixed system requirements, allowing for quick
-calculation of any application defined configuration of RTEMS.
-The RTEMS RAM Workspace Worksheet is provided below:
-
-@ifset use-ascii
-@page
-@end ifset
-@ifset use-tex
-@sp 2
-@end ifset
-
-@center @b{RTEMS RAM Workspace Worksheet}
-@sp 2
-
-@ifset use-ascii
-The total RTEMS RAM Workspace required is the sum of the following:
-
-@itemize @bullet
-@item maximum_tasks * na
-@item maximum_timers * na
-@item maximum_semaphores * na
-@item maximum_message_queues * na
-@item maximum_regions * na
-@item maximum_partitions * na
-@item maximum_ports * na
-@item maximum_periods * na
-@item maximum_extensions * na
-@item Floating Point Tasks * na
-@item Task Stacks
-@item maximum_nodes * na
-@item maximum_global_objects * na
-@item maximum_proxies * na
-@item Fixed System Requirements of na
-@end itemize
-@end ifset
-
-@ifset use-tex
-@tex
-\line{\hskip 0.75in\vbox{\offinterlineskip\halign{
-\vrule\strut#&
-\hbox to 3.0in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 0.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.25in{\enskip\hfil#\hfil}&
-\vrule#\cr
-\noalign{\hrule}
-& \bf Description && \bf Equation && \bf Bytes Required &\cr\noalign{\hrule}
-& maximum\_tasks && * na = &&&\cr\noalign{\hrule}
-& maximum\_timers && * na = &&&\cr\noalign{\hrule}
-& maximum\_semaphores && * na = &&&\cr\noalign{\hrule}
-& maximum\_message\_queues && * na = &&&\cr\noalign{\hrule}
-& maximum\_regions && * na = &&&\cr\noalign{\hrule}
-& maximum\_partitions && * na = &&&\cr\noalign{\hrule}
-& maximum\_ports && * na = &&&\cr\noalign{\hrule}
-& maximum\_periods && * na = &&&\cr\noalign{\hrule}
-& maximum\_extensions && * na = &&&\cr\noalign{\hrule}
-& Floating Point Tasks && * na = &&&\cr\noalign{\hrule}
-& Task Stacks &&\hskip 2.3em=&&&\cr\noalign{\hrule}
-& Total Single Processor Requirements &&&&&\cr\noalign{\hrule}
-}}\hfil}
-
-\line{\hskip 0.75in\vbox{\offinterlineskip\halign{
-\vrule\strut#&
-\hbox to 3.0in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 0.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.25in{\enskip\hfil#\hfil}&
-\vrule#\cr
-\noalign{\hrule}
-& \bf Description && \bf Equation && \bf Bytes Required &\cr\noalign{\hrule}
-& maximum\_nodes && * na = &&&\cr\noalign{\hrule}
-& maximum\_global\_objects && * na = &&&\cr\noalign{\hrule}
-& maximum\_proxies && * na = &&&\cr\noalign{\hrule}
-}}\hfil}
-
-\line{\hskip 0.75in\vbox{\offinterlineskip\halign{
-\vrule\strut#&
-\hbox to 3.0in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 0.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.25in{\enskip\hfil#\hfil}&
-\vrule#\cr
-\noalign{\hrule}
-& Total Multiprocessing Requirements &&&&&\cr\noalign{\hrule}
-& Fixed System Requirements && na &&&\cr\noalign{\hrule}
-& Total Single Processor Requirements &&&&&\cr\noalign{\hrule}
-& Total Multiprocessing Requirements &&&&&\cr\noalign{\hrule}
-& Minimum Bytes for RTEMS Workspace &&&&&\cr\noalign{\hrule}
-}}\hfil}
-@end tex
-@end ifset
-
-@ifset use-html
-@html
-<CENTER>
- <TABLE COLS=3 WIDTH="80%" BORDER=2>
-<TR><TD ALIGN=center><STRONG>Description</STRONG></TD>
- <TD ALIGN=center><STRONG>Equation</STRONG></TD>
- <TD ALIGN=center><STRONG>Bytes Required</STRONG></TD></TR>
-<TR><TD ALIGN=left>maximum_tasks</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>maximum_timers</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>maximum_semaphores</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>maximum_message_queues</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>maximum_regions</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>maximum_partitions</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>maximum_ports</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>maximum_periods</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>maximum_extensions</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>Floating Point Tasks</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left COLSPAN=2>Task Stacks</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left COLSPAN=2>
- <STRONG>Total Single Processor Requirements</STRONG></TD>
- <TD><BR></TD></TR>
-<TR></TR>
-<TR><TD ALIGN=center><STRONG>Description</STRONG></TD>
- <TD ALIGN=center><STRONG>Equation</STRONG></TD>
- <TD ALIGN=center><STRONG>Bytes Required</STRONG></TD></TR>
-<TR><TD ALIGN=left>maximum_nodes</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>maximum_global_objects</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left>maximum_proxies</TD>
- <TD ALIGN=right>* na =</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left COLSPAN=2>
- <STRONG>Total Multiprocessing Requirements</STRONG></TD>
- <TD><BR></TD></TR>
-<TR></TR>
-<TR><TD ALIGN=left COLSPAN=2>Fixed System Requirements</TD>
- <TD ALIGN=center>na</TD></TR>
-<TR><TD ALIGN=left COLSPAN=2>Total Single Processor Requirements</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left COLSPAN=2>Total Multiprocessing Requirements</TD>
- <TD><BR></TD></TR>
-<TR><TD ALIGN=left COLSPAN=2>
- <STRONG>Minimum Bytes for RTEMS Workspace</STRONG></TD>
- <TD><BR></TD></TR>
- </TABLE>
-</CENTER>
-@end html
-@end ifset
-
-