From 8d7393ad5f760a5dbaa5767a9ce586bbe18fce8e Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Tue, 30 Jul 2002 21:43:53 +0000 Subject: 2002-07-30 Joel Sherrill * BSP_TIMES, ChangeLog, Makefile.am, arm.texi, bsp.t, callconv.t, cpumodel.t, cputable.t, fatalerr.t, intr_NOTIMES.t, memmodel.t, preface.texi, stamp-vti, timeBSP.t, timing.texi, version.texi, wksheets.texi: New files as ARM supplement initial version added. --- doc/supplements/arm/BSP_TIMES | 247 ++++++++++++++++++++ doc/supplements/arm/ChangeLog | 7 + doc/supplements/arm/Makefile.am | 109 +++++++++ doc/supplements/arm/arm.texi | 114 +++++++++ doc/supplements/arm/bsp.t | 93 ++++++++ doc/supplements/arm/callconv.t | 73 ++++++ doc/supplements/arm/cpumodel.t | 85 +++++++ doc/supplements/arm/cputable.t | 109 +++++++++ doc/supplements/arm/fatalerr.t | 37 +++ doc/supplements/arm/intr_NOTIMES.t | 196 ++++++++++++++++ doc/supplements/arm/memmodel.t | 38 +++ doc/supplements/arm/preface.texi | 49 ++++ doc/supplements/arm/stamp-vti | 4 + doc/supplements/arm/timeBSP.t | 113 +++++++++ doc/supplements/arm/timing.texi | 460 +++++++++++++++++++++++++++++++++++++ doc/supplements/arm/version.texi | 4 + doc/supplements/arm/wksheets.texi | 437 +++++++++++++++++++++++++++++++++++ 17 files changed, 2175 insertions(+) create mode 100644 doc/supplements/arm/BSP_TIMES create mode 100644 doc/supplements/arm/ChangeLog create mode 100644 doc/supplements/arm/Makefile.am create mode 100644 doc/supplements/arm/arm.texi create mode 100644 doc/supplements/arm/bsp.t create mode 100644 doc/supplements/arm/callconv.t create mode 100644 doc/supplements/arm/cpumodel.t create mode 100644 doc/supplements/arm/cputable.t create mode 100644 doc/supplements/arm/fatalerr.t create mode 100644 doc/supplements/arm/intr_NOTIMES.t create mode 100644 doc/supplements/arm/memmodel.t create mode 100644 doc/supplements/arm/preface.texi create mode 100644 doc/supplements/arm/stamp-vti create mode 100644 doc/supplements/arm/timeBSP.t create mode 100644 doc/supplements/arm/timing.texi create mode 100644 doc/supplements/arm/version.texi create mode 100644 doc/supplements/arm/wksheets.texi (limited to 'doc/supplements') diff --git a/doc/supplements/arm/BSP_TIMES b/doc/supplements/arm/BSP_TIMES new file mode 100644 index 0000000000..1ddb23ca5a --- /dev/null +++ b/doc/supplements/arm/BSP_TIMES @@ -0,0 +1,247 @@ +# +# CPU MODEL/BSP Timing and Size Information +# +# $Id$ +# + +# +# CPU Model Information +# +RTEMS_BSP generic-arm9dtmi +RTEMS_CPU_MODEL arm9dtmi +# +# Interrupt Latency +# +# NOTE: In general, the text says it is hand-calculated to be +# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +# Mhz and this was last calculated for Release +# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. +# +RTEMS_MAXIMUM_DISABLE_PERIOD TBD +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 100 +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD ss-20020730 +# +# Context Switch Times +# +RTEMS_NO_FP_CONTEXTS 35 +RTEMS_RESTORE_1ST_FP_TASK 39 +RTEMS_SAVE_INIT_RESTORE_INIT 66 +RTEMS_SAVE_IDLE_RESTORE_INIT 66 +RTEMS_SAVE_IDLE_RESTORE_IDLE 68 +# +# Task Manager Times +# +RTEMS_TASK_CREATE_ONLY 148 +RTEMS_TASK_IDENT_ONLY 350 +RTEMS_TASK_START_ONLY 76 +RTEMS_TASK_RESTART_CALLING_TASK 95 +RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89 +RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124 +RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92 +RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125 +RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149 +RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142 +RTEMS_TASK_DELETE_CALLING_TASK 170 +RTEMS_TASK_DELETE_SUSPENDED_TASK 138 +RTEMS_TASK_DELETE_BLOCKED_TASK 143 +RTEMS_TASK_DELETE_READY_TASK 144 +RTEMS_TASK_SUSPEND_CALLING_TASK 71 +RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43 +RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45 +RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67 +RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31 +RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64 +RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106 +RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14 +RTEMS_TASK_MODE_NO_RESCHEDULE 16 +RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23 +RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60 +RTEMS_TASK_GET_NOTE_ONLY 33 +RTEMS_TASK_SET_NOTE_ONLY 33 +RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16 +RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56 +RTEMS_TASK_WAKE_WHEN_ONLY 117 +# +# Interrupt Manager +# +RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12 +RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9 +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9 +RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1 +RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8 +RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54 +# +# Clock Manager +# +RTEMS_CLOCK_SET_ONLY 86 +RTEMS_CLOCK_GET_ONLY 1 +RTEMS_CLOCK_TICK_ONLY 17 +# +# Timer Manager +# +RTEMS_TIMER_CREATE_ONLY 28 +RTEMS_TIMER_IDENT_ONLY 343 +RTEMS_TIMER_DELETE_INACTIVE 43 +RTEMS_TIMER_DELETE_ACTIVE 47 +RTEMS_TIMER_FIRE_AFTER_INACTIVE 58 +RTEMS_TIMER_FIRE_AFTER_ACTIVE 61 +RTEMS_TIMER_FIRE_WHEN_INACTIVE 88 +RTEMS_TIMER_FIRE_WHEN_ACTIVE 88 +RTEMS_TIMER_RESET_INACTIVE 54 +RTEMS_TIMER_RESET_ACTIVE 58 +RTEMS_TIMER_CANCEL_INACTIVE 31 +RTEMS_TIMER_CANCEL_ACTIVE 34 +# +# Semaphore Manager +# +RTEMS_SEMAPHORE_CREATE_ONLY 60 +RTEMS_SEMAPHORE_IDENT_ONLY 367 +RTEMS_SEMAPHORE_DELETE_ONLY 58 +RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109 +RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87 +# +# Message Manager +# +RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200 +RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341 +RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80 +RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123 +RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123 +RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133 +RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114 +RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29 +RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39 +# +# Event Manager +# +RTEMS_EVENT_SEND_NO_TASK_READIED 24 +RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60 +RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 +RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 +RTEMS_EVENT_RECEIVE_AVAILABLE 28 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84 +# +# Signal Manager +# +RTEMS_SIGNAL_CATCH_ONLY 15 +RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37 +RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54 +# +# Partition Manager +# +RTEMS_PARTITION_CREATE_ONLY 70 +RTEMS_PARTITION_IDENT_ONLY 341 +RTEMS_PARTITION_DELETE_ONLY 42 +RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35 +RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33 +RTEMS_PARTITION_RETURN_BUFFER_ONLY 43 +# +# Region Manager +# +RTEMS_REGION_CREATE_ONLY 63 +RTEMS_REGION_IDENT_ONLY 348 +RTEMS_REGION_DELETE_ONLY 39 +RTEMS_REGION_GET_SEGMENT_AVAILABLE 52 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123 +RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136 +# +# Dual-Ported Memory Manager +# +RTEMS_PORT_CREATE_ONLY 35 +RTEMS_PORT_IDENT_ONLY 340 +RTEMS_PORT_DELETE_ONLY 39 +RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26 +RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27 +# +# IO Manager +# +RTEMS_IO_INITIALIZE_ONLY 4 +RTEMS_IO_OPEN_ONLY 2 +RTEMS_IO_CLOSE_ONLY 1 +RTEMS_IO_READ_ONLY 2 +RTEMS_IO_WRITE_ONLY 3 +RTEMS_IO_CONTROL_ONLY 2 +# +# Rate Monotonic Manager +# +RTEMS_RATE_MONOTONIC_CREATE_ONLY 32 +RTEMS_RATE_MONOTONIC_IDENT_ONLY 341 +RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39 +RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51 +RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48 +RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54 +RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74 +RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31 +# +# Size Information +# +# +# xxx alloted for numbers +# +RTEMS_DATA_SPACE 723 +RTEMS_MINIMUM_CONFIGURATION 18,980 +RTEMS_MAXIMUM_CONFIGURATION 36,438 +# x,xxx alloted for numbers +RTEMS_CORE_CODE_SIZE 12,674 +RTEMS_INITIALIZATION_CODE_SIZE 970 +RTEMS_TASK_CODE_SIZE 3,562 +RTEMS_INTERRUPT_CODE_SIZE 54 +RTEMS_CLOCK_CODE_SIZE 334 +RTEMS_TIMER_CODE_SIZE 1,110 +RTEMS_SEMAPHORE_CODE_SIZE 1,632 +RTEMS_MESSAGE_CODE_SIZE 1,754 +RTEMS_EVENT_CODE_SIZE 1,000 +RTEMS_SIGNAL_CODE_SIZE 418 +RTEMS_PARTITION_CODE_SIZE 1,164 +RTEMS_REGION_CODE_SIZE 1,494 +RTEMS_DPMEM_CODE_SIZE 724 +RTEMS_IO_CODE_SIZE 686 +RTEMS_FATAL_ERROR_CODE_SIZE 24 +RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212 +RTEMS_MULTIPROCESSING_CODE_SIZE 6.952 +# xxx alloted for numbers +RTEMS_TIMER_CODE_OPTSIZE 184 +RTEMS_SEMAPHORE_CODE_OPTSIZE 172 +RTEMS_MESSAGE_CODE_OPTSIZE 288 +RTEMS_EVENT_CODE_OPTSIZE 56 +RTEMS_SIGNAL_CODE_OPTSIZE 56 +RTEMS_PARTITION_CODE_OPTSIZE 132 +RTEMS_REGION_CODE_OPTSIZE 160 +RTEMS_DPMEM_CODE_OPTSIZE 132 +RTEMS_IO_CODE_OPTSIZE 00 +RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184 +RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332 +# xxx alloted for numbers +RTEMS_BYTES_PER_TASK 400 +RTEMS_BYTES_PER_TIMER 68 +RTEMS_BYTES_PER_SEMAPHORE 124 +RTEMS_BYTES_PER_MESSAGE_QUEUE 148 +RTEMS_BYTES_PER_REGION 144 +RTEMS_BYTES_PER_PARTITION 56 +RTEMS_BYTES_PER_PORT 36 +RTEMS_BYTES_PER_PERIOD 36 +RTEMS_BYTES_PER_EXTENSION 64 +RTEMS_BYTES_PER_FP_TASK 332 +RTEMS_BYTES_PER_NODE 48 +RTEMS_BYTES_PER_GLOBAL_OBJECT 20 +RTEMS_BYTES_PER_PROXY 124 +# x,xxx alloted for numbers +RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872 diff --git a/doc/supplements/arm/ChangeLog b/doc/supplements/arm/ChangeLog new file mode 100644 index 0000000000..b62a0bcbeb --- /dev/null +++ b/doc/supplements/arm/ChangeLog @@ -0,0 +1,7 @@ +2002-07-30 Joel Sherrill + + * BSP_TIMES, ChangeLog, Makefile.am, arm.texi, bsp.t, callconv.t, + cpumodel.t, cputable.t, fatalerr.t, intr_NOTIMES.t, memmodel.t, + preface.texi, stamp-vti, timeBSP.t, timing.texi, version.texi, + wksheets.texi: New files as ARM supplement initial version added. + diff --git a/doc/supplements/arm/Makefile.am b/doc/supplements/arm/Makefile.am new file mode 100644 index 0000000000..ba10564e53 --- /dev/null +++ b/doc/supplements/arm/Makefile.am @@ -0,0 +1,109 @@ +# +# COPYRIGHT (c) 1988-2002. +# On-Line Applications Research Corporation (OAR). +# All rights reserved. +# +# $Id$ +# + + +PROJECT = arm +EDITION = 1 + +include $(top_srcdir)/project.am +include $(top_srcdir)/supplements/supplement.am + +GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ + fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \ + timeBSP.texi +COMMON_FILES = $(top_srcdir)/common/setup.texi \ + $(top_srcdir)/common/cpright.texi $(top_srcdir)/common/timemac.texi + +FILES = preface.texi + +info_TEXINFOS = arm.texi +arm_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) + +# +# Chapters which get automatic processing +# + +$(srcdir)/cpumodel.texi: cpumodel.t + $(BMENU2) -p "Preface" \ + -u "Top" \ + -n "Calling Conventions" < $< > $@ + +$(srcdir)/callconv.texi: callconv.t + $(BMENU2) -p "CPU Model Dependent Features Floating Point Unit" \ + -u "Top" \ + -n "Memory Model" < $< > $@ + +$(srcdir)/memmodel.texi: memmodel.t + $(BMENU2) -p "Calling Conventions User-Provided Routines" \ + -u "Top" \ + -n "Interrupt Processing" < $< > $@ + +# Interrupt Chapter: +# 1. Replace Times and Sizes +# 2. Build Node Structure +$(srcdir)/intr.texi: intr_NOTIMES.t BSP_TIMES + ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \ + $(BMENU2) -p "Memory Model Flat Memory Model" \ + -u "Top" \ + -n "Default Fatal Error Processing" > $@ + +$(srcdir)/fatalerr.texi: fatalerr.t + $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ + -u "Top" \ + -n "Board Support Packages" < $< > $@ + +$(srcdir)/bsp.texi: bsp.t + $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ + -u "Top" \ + -n "Processor Dependent Information Table" < $< > $@ + +$(srcdir)/cputable.texi: cputable.t + $(BMENU2) -p "Board Support Packages Processor Initialization" \ + -u "Top" \ + -n "Memory Requirements" < $< > $@ + +# Worksheets Chapter: +# 1. Obtain the Shared File +# 2. Replace Times and Sizes +# 3. Build Node Structure + +$(srcdir)/wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES + ${REPLACE2} -p $(srcdir)/BSP_TIMES \ + $(top_srcdir)/common/wksheets.t | \ + $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ + -u "Top" \ + -n "Timing Specification" > $@ + +# Timing Specification Chapter: +# 1. Copy the Shared File +# 3. Build Node Structure + +$(srcdir)/timing.texi: $(top_srcdir)/common/timing.t + $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ + -u "Top" \ + -n "MYBSP Timing Data" < $< > $@ + +# Timing Data for BSP BSP Chapter: +# 1. Copy the Shared File +# 2. Replace Times and Sizes +# 3. Build Node Structure + +$(srcdir)/timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t + cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t + @echo >>timeBSP_.t + @echo "@tex" >>timeBSP_.t + @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t + @echo "@end tex" >>timeBSP_.t + ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \ + $(BMENU2) -p "Timing Specification Terminology" \ + -u "Top" \ + -n "Command and Variable Index" > $@ +CLEANFILES += timeBSP_.t + +EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ + intr_NOTIMES.t memmodel.t timeBSP.t diff --git a/doc/supplements/arm/arm.texi b/doc/supplements/arm/arm.texi new file mode 100644 index 0000000000..12624f1e29 --- /dev/null +++ b/doc/supplements/arm/arm.texi @@ -0,0 +1,114 @@ +\input texinfo @c -*-texinfo-*- +@c %**start of header +@setfilename arm +@setcontentsaftertitlepage +@syncodeindex vr fn +@synindex ky cp +@paragraphindent 0 +@c %**end of header + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@c +@c Master file for the ARM Applications Supplement +@c + +@include version.texi +@include common/setup.texi + +@ifset use-ascii +@dircategory RTEMS Target Supplements +@direntry +* RTEMS ARM Applications Supplement: (arm). +@end direntry +@end ifset + +@c +@c Title Page Stuff +@c + +@c +@c I don't really like having a short title page. --joel +@c +@c @shorttitlepage RTEMS ARM Applications Supplement + +@setchapternewpage odd +@settitle RTEMS ARM Applications Supplement +@titlepage +@finalout + +@title RTEMS ARM Applications Supplement +@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} +@sp 1 +@subtitle @value{UPDATED} +@author On-Line Applications Research Corporation +@page + +@include common/cpright.texi +@end titlepage + +@c This prevents a black box from being printed on "overflow" lines. +@c The alternative is to rework a sentence to avoid this problem. + +@include preface.texi +@include cpumodel.texi +@include callconv.texi +@include memmodel.texi +@include intr.texi +@include fatalerr.texi +@include bsp.texi +@include cputable.texi +@include wksheets.texi +@include timing.texi +@include timeBSP.texi +@ifinfo +@node Top, Preface, (dir), (dir) +@top arm + +This is the online version of the RTEMS ARM +Applications Supplement. + +@menu +* Preface:: +* CPU Model Dependent Features:: +* Calling Conventions:: +* Memory Model:: +* Interrupt Processing:: +* Default Fatal Error Processing:: +* Board Support Packages:: +* Processor Dependent Information Table:: +* Memory Requirements:: +* Timing Specification:: +* MYBSP Timing Data:: +* Command and Variable Index:: +* Concept Index:: +@end menu + +@end ifinfo +@c +@c +@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here +@c + +@node Command and Variable Index, Concept Index, MYBSP Timing Data Rate Monotonic Manager, Top +@unnumbered Command and Variable Index + +There are currently no Command and Variable Index entries. + +@c @printindex fn + +@node Concept Index, , Command and Variable Index, Top +@unnumbered Concept Index + +There are currently no Concept Index entries. +@c @printindex cp + +@contents +@bye + diff --git a/doc/supplements/arm/bsp.t b/doc/supplements/arm/bsp.t new file mode 100644 index 0000000000..657c359a96 --- /dev/null +++ b/doc/supplements/arm/bsp.t @@ -0,0 +1,93 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@chapter Board Support Packages + +@section Introduction + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of XXX specific BSP +issues. For more information on developing a BSP, refer to the +chapter titled Board Support Packages in the RTEMS +Applications User's Guide. + +@section System Reset + +An RTEMS based application is initiated or +re-initiated when the XXX processor is reset. When the +XXX is reset, the processor performs the following actions: + +@itemize @bullet +@item The tracing bits of the status register are cleared to +disable tracing. + +@item The supervisor interrupt state is entered by setting the +supervisor (S) bit and clearing the master/interrupt (M) bit of +the status register. + +@item The interrupt mask of the status register is set to +level 7 to effectively disable all maskable interrupts. + +@item The vector base register (VBR) is set to zero. + +@item The cache control register (CACR) is set to zero to +disable and freeze the processor cache. + +@item The interrupt stack pointer (ISP) is set to the value +stored at vector 0 (bytes 0-3) of the exception vector table +(EVT). + +@item The program counter (PC) is set to the value stored at +vector 1 (bytes 4-7) of the EVT. + +@item The processor begins execution at the address stored in +the PC. +@end itemize + +@section Processor Initialization + +The address of the application's initialization code +should be stored in the first vector of the EVT which will allow +the immediate vectoring to the application code. If the +application requires that the VBR be some value besides zero, +then it should be set to the required value at this point. All +tasks share the same XXX's VBR value. Because interrupts +are enabled automatically by RTEMS as part of the initialize +executive directive, the VBR MUST be set before this directive +is invoked to insure correct interrupt vectoring. If processor +caching is to be utilized, then it should be enabled during the +reset application initialization code. + +In addition to the requirements described in the +Board Support Packages chapter of the Applications User's +Manual for the reset code which is executed before the call to +initialize executive, the XXX version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the XXX remains in the supervisor state. + +@item Must set the M bit of the status register to remove the +XXX from the interrupt state. + +@item Must set the master stack pointer (MSP) such that a +minimum stack size of MINIMUM_STACK_SIZE bytes is provided for +the initialize executive directive. + +@item Must initialize the XXX's vector table. +@end itemize + +Note that the BSP is not responsible for allocating +or installing the interrupt stack. RTEMS does this +automatically as part of initialization. If the BSP does not +install an interrupt stack and -- for whatever reason -- an +interrupt occurs before initialize_executive is invoked, then +the results are unpredictable. + diff --git a/doc/supplements/arm/callconv.t b/doc/supplements/arm/callconv.t new file mode 100644 index 0000000000..167f5b8fa5 --- /dev/null +++ b/doc/supplements/arm/callconv.t @@ -0,0 +1,73 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@chapter Calling Conventions + +@section Introduction + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage +@item parameter passing +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@section Processor Background + +The ARM architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the branch and link (@code{bl}) instruction. This instruction +saves the return address in the @code{lr} register. Returning +from a subroutine only requires that the return address be +moved into the program counter (@code{pc}), possibly with +an offset. It is is important to +note that the @code{bl} instruction does not +automatically save or restore any registers. It is the +responsibility of the high-level language compiler to define the +register preservation and usage convention. + +@section Calling Mechanism + +All RTEMS directives are invoked using the @code{bl} +instruction and return to the user application via the +mechanism described above. + +@section Register Usage + +As discussed above, the ARM's call and return mechanism dos +not automatically save any registers. RTEMS uses the registers +@code{r0}, @code{r1}, @code{r2}, and @code{r3} as scratch registers and +per ARM calling convention, the @code{lr} register is altered +as well. These registers are not preserved by RTEMS directives +therefore, the contents of these registers should not be assumed +upon return from any RTEMS directive. + +@section Parameter Passing + +RTEMS assumes that ARM calling conventions are followed and that +the first four arguments are placed in registers @code{r0} through +@code{r3}. If there are more arguments, than that, then they +are place on the stack. + +@section User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + diff --git a/doc/supplements/arm/cpumodel.t b/doc/supplements/arm/cpumodel.t new file mode 100644 index 0000000000..c19b879d49 --- /dev/null +++ b/doc/supplements/arm/cpumodel.t @@ -0,0 +1,85 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@chapter CPU Model Dependent Features + +@section Introduction + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +ARM, SPARC, and PA-RISC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. Each processor family supported by +RTEMS has a list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This chapter presents the set of features which vary +across ARM implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +cpukit/score/cpu/arm/rtems/score/arm.h based upon the particular CPU +model defined on the compilation command line. + +@section CPU Model Name + +The macro @code{CPU_MODEL_NAME} is a string which designates +the architectural level of this CPU model. The following is +a list of the settings for this string based upon @code{gcc} +CPU model predefines: + +@example +__ARM_ARCH4__ "ARMv4" +__ARM_ARCH4T__ "ARMv4T" +__ARM_ARCH5__ "ARMv5" +__ARM_ARCH5T__ "ARMv5T" +__ARM_ARCH5E__ "ARMv5E" +__ARM_ARCH5TE__ "ARMv5TE" +@end example + +@section Count Leading Zeroes Instruction + +The macro @code{ARM_HAS_CLZ} is set to 1 to indicate that +the architectural version has the @code{clz} instruction. +On ARM architectural version 5 and above, the count +leading zeroes instruction (@code{clz}) is available and +can be used to speed up the find first bit operation. +The use of this instruction significantly speeds up the +scheduling associated with a thread blocking. + +@section Floating Point Unit + +The macro ARM_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. It does not matter whether the hardware floating +point support is incorporated on-chip or is an external +coprocessor. + diff --git a/doc/supplements/arm/cputable.t b/doc/supplements/arm/cputable.t new file mode 100644 index 0000000000..75d0fc15f6 --- /dev/null +++ b/doc/supplements/arm/cputable.t @@ -0,0 +1,109 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@chapter Processor Dependent Information Table + +@section Introduction + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@section CPU Dependent Information Table + +The XXX version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the XXX. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +@group +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 idle_task_stack_size; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + /* XXX CPU family dependent stuff */ +@} rtems_cpu_table; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the user provided routine which is invoked +once RTEMS APIs are initialized. This routine will be invoked +before any system tasks are created. Interrupts are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine that is invoked immediately before the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine that is invoked immediately after the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item idle_task_stack_size +is the size of the RTEMS idle task stack in bytes. +If this number is less than MINIMUM_STACK_SIZE, then the +idle task's stack will be MINIMUM_STACK_SIZE in byte. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item XXX +is where the CPU family dependent stuff goes. + +@end table diff --git a/doc/supplements/arm/fatalerr.t b/doc/supplements/arm/fatalerr.t new file mode 100644 index 0000000000..8a703718ea --- /dev/null +++ b/doc/supplements/arm/fatalerr.t @@ -0,0 +1,37 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@chapter Default Fatal Error Processing + +@section Introduction + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@section Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the @code{rtems_fatal_error_occurred} directive when there is +no user handler configured or the user handler returns control to +RTEMS. The default fatal error handler performs the +following actions: + +@itemize @bullet +@item disables processor interrupts, +@item places the error code in @b{r0}, and +@item executes an infinite loop (@code{while(0);} to +simulate a halt processor instruction. +@end itemize + diff --git a/doc/supplements/arm/intr_NOTIMES.t b/doc/supplements/arm/intr_NOTIMES.t new file mode 100644 index 0000000000..4efc1d80b4 --- /dev/null +++ b/doc/supplements/arm/intr_NOTIMES.t @@ -0,0 +1,196 @@ +@c +@c Interrupt Stack Frame Picture +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@chapter Interrupt Processing + +@section Introduction + +Different types of processors respond to the +occurrence of an interrupt in its own unique fashion. In +addition, each processor type provides a control mechanism to +allow for the proper handling of an interrupt. The processor +dependent response to the interrupt modifies the current +execution state and results in a change in the execution stream. +Most processors require that an interrupt handler utilize some +special control mechanisms to return to the normal processing +stream. Although RTEMS hides many of the processor dependent +details of interrupt processing, it is important to understand +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the XXX's +interrupt response and control mechanisms as they pertain to +RTEMS. + +@section Vectoring of an Interrupt Handler + +Depending on whether or not the particular CPU +supports a separate interrupt stack, the XXX family has two +different interrupt handling models. + +@subsection Models Without Separate Interrupt Stacks + +Upon receipt of an interrupt the XXX family +members without separate interrupt stacks automatically perform +the following actions: + +@itemize @bullet +@item To Be Written +@end itemize + +@subsection Models With Separate Interrupt Stacks + +Upon receipt of an interrupt the XXX family +members with separate interrupt stacks automatically perform the +following actions: + +@itemize @bullet +@item saves the current status register (SR), + +@item clears the master/interrupt (M) bit of the SR to +indicate the switch from master state to interrupt state, + +@item sets the privilege mode to supervisor, + +@item suppresses tracing, + +@item sets the interrupt mask level equal to the level of the +interrupt being serviced, + +@item pushes an interrupt stack frame (ISF), which includes +the program counter (PC), the status register (SR), and the +format/exception vector offset (FVO) word, onto the supervisor +and interrupt stacks, + +@item switches the current stack to the interrupt stack and +vectors to an interrupt service routine (ISR). If the ISR was +installed with the interrupt_catch directive, then the RTEMS +interrupt handler will begin execution. The RTEMS interrupt +handler saves all registers which are not preserved according to +the calling conventions and invokes the application's ISR. +@end itemize + +A nested interrupt is processed similarly by these +CPU models with the exception that only a single ISF is placed +on the interrupt stack and the current stack need not be +switched. + +The FVO word in the Interrupt Stack Frame is examined +by RTEMS to determine when an outer most interrupt is being +exited. Since the FVO is used by RTEMS for this purpose, the +user application code MUST NOT modify this field. + +The following shows the Interrupt Stack Frame for +XXX CPU models with separate interrupt stacks: + +@ifset use-ascii +@example +@group + +----------------------+ + | Status Register | 0x0 + +----------------------+ + | Program Counter High | 0x2 + +----------------------+ + | Program Counter Low | 0x4 + +----------------------+ + | Format/Vector Offset | 0x6 + +----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\strut\vrule#& +\hbox to 2.00in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 0.50in{\enskip\hfil#\hfil} +\cr +\multispan{3}\hrulefill\cr +& Status Register && 0x0\cr +\multispan{3}\hrulefill\cr +& Program Counter High && 0x2\cr +\multispan{3}\hrulefill\cr +& Program Counter Low && 0x4\cr +\multispan{3}\hrulefill\cr +& Format/Vector Offset && 0x6\cr +\multispan{3}\hrulefill\cr +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + + +
Status Register0x0
Program Counter High0x2
Program Counter Low0x4
Format/Vector Offset0x6
+
+@end html +@end ifset + +@section Interrupt Levels + +Eight levels (0-7) of interrupt priorities are +supported by XXX family members with level seven (7) being +the highest priority. Level zero (0) indicates that interrupts +are fully enabled. Interrupt requests for interrupts with +priorities less than or equal to the current interrupt mask +level are ignored. + +Although RTEMS supports 256 interrupt levels, the +XXX family only supports eight. RTEMS interrupt levels 0 +through 7 directly correspond to XXX interrupt levels. All +other RTEMS interrupt levels are undefined and their behavior is +unpredictable. + +@section Disabling of Interrupts by RTEMS + +During the execution of directive calls, critical +sections of code may be executed. When these sections are +encountered, RTEMS disables interrupts to level seven (7) before +the execution of this section and restores them to the previous +level upon completion of the section. RTEMS has been optimized +to insure that interrupts are disabled for less than +RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz processor with +zero wait states. These numbers will vary based the +number of wait states and processor speed present on the target board. +[NOTE: The maximum period with interrupts disabled is hand calculated. This +calculation was last performed for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +Non-maskable interrupts (NMI) cannot be disabled, and +ISRs which execute at this level MUST NEVER issue RTEMS system +calls. If a directive is invoked, unpredictable results may +occur due to the inability of RTEMS to protect its critical +sections. However, ISRs that make no system calls may safely +execute as non-maskable interrupts. + +@section Interrupt Stack + +RTEMS allocates the interrupt stack from the +Workspace Area. The amount of memory allocated for the +interrupt stack is determined by the interrupt_stack_size field +in the CPU Configuration Table. During the initialization +process, RTEMS will install its interrupt stack. + +The XXX port of RTEMS supports a software managed +dedicated interrupt stack on those CPU models which do not +support a separate interrupt stack in hardware. + + diff --git a/doc/supplements/arm/memmodel.t b/doc/supplements/arm/memmodel.t new file mode 100644 index 0000000000..bf543364c7 --- /dev/null +++ b/doc/supplements/arm/memmodel.t @@ -0,0 +1,38 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@chapter Memory Model + +@section Introduction + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@section Flat Memory Model + +Members of the ARM family newer than Version 3 support a flat +32-bit address space with addresses ranging from 0x00000000 to +0xFFFFFFFF (4 gigabytes). Each address is represented by a +32-bit value and is byte addressable. +The address may be used to reference a +single byte, word (2-bytes), or long word (4 bytes). Memory +accesses within this address space are performed in the endian +mode that the processor is configured for. In general, ARM +processors are used in little endian mode. + +Some of the ARM family members such as the +920 and 720 include an MMU and thus support virtual memory and +segmentation. RTEMS does not support virtual memory or +segmentation on any of the ARM family members. + diff --git a/doc/supplements/arm/preface.texi b/doc/supplements/arm/preface.texi new file mode 100644 index 0000000000..27bb11a558 --- /dev/null +++ b/doc/supplements/arm/preface.texi @@ -0,0 +1,49 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@node Preface, CPU Model Dependent Features, Top, Top +@end ifinfo +@unnumbered Preface + +The Real Time Executive for Multiprocessor Systems (RTEMS) +is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +This document discusses the ARM architecture dependencies +in this port of RTEMS. The ARM family has a wide variety +of implementations by a wide range of vendors. Consequently, +there are 100's of CPU models within it. + +It is highly recommended that the ARM +RTEMS application developer obtain and become familiar with the +documentation for the processor being used as well as the +documentation for the ARM architecture as a whole. + +@subheading Architecture Documents + +For information on the ARM architecture, +refer to the following documents available from Arm, Limited +(@file{http//www.arm.com/}). There does not appear to +be an electronic version of a manual on the architecture +in general on that site. The following book is a good +resource: + +@itemize @bullet +@item @cite{David Seal. "ARM Architecture Reference Manual." +Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.} + +@end itemize + + diff --git a/doc/supplements/arm/stamp-vti b/doc/supplements/arm/stamp-vti new file mode 100644 index 0000000000..e7474b6acc --- /dev/null +++ b/doc/supplements/arm/stamp-vti @@ -0,0 +1,4 @@ +@set UPDATED 30 July 2002 +@set UPDATED-MONTH July 2002 +@set EDITION ss-20020717 +@set VERSION ss-20020717 diff --git a/doc/supplements/arm/timeBSP.t b/doc/supplements/arm/timeBSP.t new file mode 100644 index 0000000000..742272f775 --- /dev/null +++ b/doc/supplements/arm/timeBSP.t @@ -0,0 +1,113 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@include common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@chapter MYBSP Timing Data + +@section Introduction + +The timing data for the ARM version of RTEMS is +provided along with the target dependent aspects concerning the +gathering of the timing data. The hardware platform used to +gather the times is described to give the reader a better +understanding of each directive time provided. Also, provided +is a description of the interrupt latency and the context switch +times as they pertain to the ARM version of RTEMS. + +@section Hardware Platform + +All times reported except for the maximum period +interrupts are disabled by RTEMS were measured using a Motorola +MYBSP CPU board. The MYBSP is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +Mhz board with SDRAM and no numeric coprocessor. A +countdown timer on this board was used to measure +elapsed time with a 20 nanosecond resolution. All +sources of hardware interrupts were disabled, although the +interrupt level of the ARM microprocessor allows all interrupts. + +The maximum period interrupts are disabled was +measured by summing the number of CPU cycles required by each +assembly language instruction executed while interrupts were +disabled. The worst case times of the ARM9DTMI microprocessor +were used for each instruction. Zero wait state memory was +assumed. The total CPU cycles executed with interrupts +disabled, including the instructions to disable and enable +interrupts, was divided by TBD to simulate a TBD Mhz processor. It +should be noted that the worst case instruction times +assume that the internal cache is disabled and that no +instructions overlap. + +@section Interrupt Latency + +The maximum period with interrupts disabled within +RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD +microseconds including the instructions +which disable and re-enable interrupts. The time required for +the processor to vector an interrupt and for the RTEMS entry +overhead before invoking the user's interrupt handler are a +total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds. These combine to yield a worst case +interrupt latency of less than +RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +Mhz. [NOTE: The maximum period with interrupts +disabled was last determined for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +It should be noted again that the maximum period with +interrupts disabled within RTEMS is hand-timed and based upon +worst case (i.e. CPU cache disabled and no instruction overlap) +times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz processor. +The interrupt vector and entry +overhead time was generated on an MYBSP benchmark platform +using the Multiprocessing Communications registers to generate +as the interrupt source. + +@section Context Switch + +The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS +microseconds on the MYBSP benchmark platform when no floating +point context is saved or restored. Additional execution time +is required when a TASK_SWITCH user extension is configured. +The use of the TASK_SWITCH extension is application dependent. +Thus, its execution time is not considered part of the raw +context switch time. + +The ARM processor benchmarked does not have a floating point +unit and consequently no FPU results are reported. + +@c Since RTEMS was designed specifically for embedded +@c missile applications which are floating point intensive, the +@c executive is optimized to avoid unnecessarily saving and +@c restoring the state of the numeric coprocessor. The state of +@c the numeric coprocessor is only saved when an FLOATING_POINT +@c task is dispatched and that task was not the last task to +@c utilize the coprocessor. In a system with only one +@c FLOATING_POINT task, the state of the numeric coprocessor will +@c never be saved or restored. When the first FLOATING_POINT task +@c is dispatched, RTEMS does not need to save the current state of +@c the numeric coprocessor. + +@c The exact amount of time required to save and restore +@c floating point context is dependent on whether an XXX or +@c XXX is being used as well as the state of the numeric +@c coprocessor. These numeric coprocessors define three operating +@c states: initialized, idle, and busy. RTEMS places the +@c coprocessor in the initialized state when a task is started or +@c restarted. Once the task has utilized the coprocessor, it is in +@c the idle state when floating point instructions are not +@c executing and the busy state when floating point instructions +@c are executing. The state of the coprocessor is task specific. + +The following table summarizes the context switch +times for the MYBSP benchmark platform: + diff --git a/doc/supplements/arm/timing.texi b/doc/supplements/arm/timing.texi new file mode 100644 index 0000000000..302a1391a8 --- /dev/null +++ b/doc/supplements/arm/timing.texi @@ -0,0 +1,460 @@ +@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/version.texi b/doc/supplements/arm/version.texi new file mode 100644 index 0000000000..e7474b6acc --- /dev/null +++ b/doc/supplements/arm/version.texi @@ -0,0 +1,4 @@ +@set UPDATED 30 July 2002 +@set UPDATED-MONTH July 2002 +@set EDITION ss-20020717 +@set VERSION ss-20020717 diff --git a/doc/supplements/arm/wksheets.texi b/doc/supplements/arm/wksheets.texi new file mode 100644 index 0000000000..dd7dcd74b1 --- /dev/null +++ b/doc/supplements/arm/wksheets.texi @@ -0,0 +1,437 @@ +@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: 723 +@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: 18,980 +@item Maximum Configuration: 36,438 +@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 (12,674, NA) +@item Initialization (970, NA) +@item Task (3,562, NA) +@item Interrupt (54, NA) +@item Clock (334, NA) +@item Timer (1,110, 184) +@item Semaphore (1,632, 172) +@item Message (1,754, 288) +@item Event (1,000, 56) +@item Signal (418, 56) +@item Partition (1,164, 132) +@item Region (1,494, 160) +@item Dual Ported Memory (724, 132) +@item I/O (686, 00) +@item Fatal Error (24, NA) +@item Rate Monotonic (1,212, 184) +@item Multiprocessing (6.952, 332) +@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 && 12,674 && NA && &\cr\noalign{\hrule} +&Initialization && 970 && NA && &\cr\noalign{\hrule} +&Task && 3,562 && NA && &\cr\noalign{\hrule} +&Interrupt && 54 && NA && &\cr\noalign{\hrule} +&Clock && 334 && NA && &\cr\noalign{\hrule} +&Timer && 1,110 && 184 && &\cr\noalign{\hrule} +&Semaphore && 1,632 && 172 && &\cr\noalign{\hrule} +&Message && 1,754 && 288 && &\cr\noalign{\hrule} +&Event && 1,000 && 56 && &\cr\noalign{\hrule} +&Signal && 418 && 56 && &\cr\noalign{\hrule} +&Partition && 1,164 && 132 && &\cr\noalign{\hrule} +&Region && 1,494 && 160 && &\cr\noalign{\hrule} +&Dual Ported Memory && 724 && 132 && &\cr\noalign{\hrule} +&I/O && 686 && 00 && &\cr\noalign{\hrule} +&Fatal Error && 24 && NA && &\cr\noalign{\hrule} +&Rate Monotonic && 1,212 && 184 && &\cr\noalign{\hrule} +&Multiprocessing && 6.952 && 332 && &\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
Core12,674NA
Initialization970NA
Task3,562NA
Interrupt54NA
Clock334NA
Timer1,110184
Semaphore1,632172
Message1,754288
Event1,00056
Signal41856
Partition1,164132
Region1,494160
Dual Ported Memory724132
I/O68600
Fatal Error24NA
Rate Monotonic1,212184
Multiprocessing6.952332
+ 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 * 400 +@item maximum_timers * 68 +@item maximum_semaphores * 124 +@item maximum_message_queues * 148 +@item maximum_regions * 144 +@item maximum_partitions * 56 +@item maximum_ports * 36 +@item maximum_periods * 36 +@item maximum_extensions * 64 +@item Floating Point Tasks * 332 +@item Task Stacks +@item maximum_nodes * 48 +@item maximum_global_objects * 20 +@item maximum_proxies * 124 +@item Fixed System Requirements of 8,872 +@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 && * 400 = &&&\cr\noalign{\hrule} +& maximum\_timers && * 68 = &&&\cr\noalign{\hrule} +& maximum\_semaphores && * 124 = &&&\cr\noalign{\hrule} +& maximum\_message\_queues && * 148 = &&&\cr\noalign{\hrule} +& maximum\_regions && * 144 = &&&\cr\noalign{\hrule} +& maximum\_partitions && * 56 = &&&\cr\noalign{\hrule} +& maximum\_ports && * 36 = &&&\cr\noalign{\hrule} +& maximum\_periods && * 36 = &&&\cr\noalign{\hrule} +& maximum\_extensions && * 64 = &&&\cr\noalign{\hrule} +& Floating Point Tasks && * 332 = &&&\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 && * 48 = &&&\cr\noalign{\hrule} +& maximum\_global\_objects && * 20 = &&&\cr\noalign{\hrule} +& maximum\_proxies && * 124 = &&&\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 && 8,872 &&&\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* 400 =
maximum_timers* 68 =
maximum_semaphores* 124 =
maximum_message_queues* 148 =
maximum_regions* 144 =
maximum_partitions* 56 =
maximum_ports* 36 =
maximum_periods* 36 =
maximum_extensions* 64 =
Floating Point Tasks* 332 =
Task Stacks
+ Total Single Processor Requirements
DescriptionEquationBytes Required
maximum_nodes* 48 =
maximum_global_objects* 20 =
maximum_proxies* 124 =
+ Total Multiprocessing Requirements
Fixed System Requirements8,872
Total Single Processor Requirements
Total Multiprocessing Requirements
+ Minimum Bytes for RTEMS Workspace
+
+@end html +@end ifset + + -- cgit v1.2.3