From a454e88d34be216c74e26fa196cc861fe09a1f03 Mon Sep 17 00:00:00 2001 From: Ralf Corsepius Date: Wed, 22 Jan 2003 05:53:29 +0000 Subject: 2003-01-22 Ralf Corsepius * wksheets.texi: Remove from CVS. * timing.texi: Remove from CVS. --- doc/supplements/arm/ChangeLog | 5 + doc/supplements/arm/timing.texi | 460 -------------------------------------- doc/supplements/arm/wksheets.texi | 437 ------------------------------------ 3 files changed, 5 insertions(+), 897 deletions(-) delete mode 100644 doc/supplements/arm/timing.texi delete mode 100644 doc/supplements/arm/wksheets.texi (limited to 'doc/supplements') 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 + + * wksheets.texi: Remove from CVS. + * timing.texi: Remove from CVS. + 2003-01-21 Joel Sherrill * 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 -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ComponentIncludedNot IncludedSize
CorenaNA
InitializationnaNA
TasknaNA
InterruptnaNA
ClocknaNA
Timernana
Semaphorenana
Messagenana
Eventnana
Signalnana
Partitionnana
Regionnana
Dual Ported Memorynana
I/Onana
Fatal ErrornaNA
Rate Monotonicnana
Multiprocessingnana
- Total Code Space Requirements
-
-@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 -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DescriptionEquationBytes Required
maximum_tasks* na =
maximum_timers* na =
maximum_semaphores* na =
maximum_message_queues* na =
maximum_regions* na =
maximum_partitions* na =
maximum_ports* na =
maximum_periods* na =
maximum_extensions* na =
Floating Point Tasks* na =
Task Stacks
- Total Single Processor Requirements
DescriptionEquationBytes Required
maximum_nodes* na =
maximum_global_objects* na =
maximum_proxies* na =
- Total Multiprocessing Requirements
Fixed System Requirementsna
Total Single Processor Requirements
Total Multiprocessing Requirements
- Minimum Bytes for RTEMS Workspace
-
-@end html -@end ifset - - -- cgit v1.2.3