forked from Imagelibrary/rtems
2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
* wksheets.texi: Remove from CVS. * timing.texi: Remove from CVS.
This commit is contained in:
Ralf Corsepius
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user