RTOS/rtems
1
0
Fork 0
forked from Imagelibrary/rtems
Code Pull Requests Activity

2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>

Browse Source 
* wksheets.texi: Remove from CVS.
	* timing.texi: Remove from CVS.
This commit is contained in:
Ralf Corsepius
2003-01-22 05:53:29 +00:00
parent 4b1f9242ae
commit a454e88d34
3 changed files with 5 additions and 897 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
doc/supplements/arm/ChangeLog
View File

@@ -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> 2003-01-21 Joel Sherrill <joel@OARcorp.com>
* stamp-vti, version.texi: Regenerated. * stamp-vti, version.texi: Regenerated.

460
doc/supplements/arm/timing.texi
View File

@@ -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

437
doc/supplements/arm/wksheets.texi
View File

@@ -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