Changeset bb4b574 in rtems


Ignore:
Timestamp:
Apr 25, 2000, 1:15:14 PM (21 years ago)
Author:
Joel Sherrill <joel.sherrill@…>
Branches:
4.10, 4.11, 4.8, 4.9, 5, master
Children:
2ba8875
Parents:
0765f9b
Message:

Merged changes from 4.5 branch and removed that branch.

Location:
doc
Files:
11 edited

Legend:

Unmodified
Added
Removed
  • doc/Make.config

    r0765f9b rbb4b574  
    55#
    66
    7 RTEMS_VERSION=4.5-beta1b
     7RTEMS_VERSION=4.5-beta2
    88#DOC_INSTALL_BASE=/usr1/rtems/tmp/rtemsdoc-$(RTEMS_VERSION)
    99DOC_INSTALL_BASE=/home/httpd/html/rtems/rtemsdoc-$(RTEMS_VERSION)
    1010# DOC_INSTALL_BASE=/home/httpd/html/rtems/doc/rtems
    1111
    12 SRCDIR=/usr1/rtems/rtemsdoc-work
     12SRCDIR=/usr1/rtems/4.5-work/rtems-doc
    1313
    1414BMENU=$(SRCDIR)/tools/bmenu/bmenu
  • doc/common/setup.texi

    r0765f9b rbb4b574  
    1111@c
    1212
    13 @set RTEMS-RELEASE 4.5-beta1b
     13@set RTEMS-RELEASE 4.5-beta2
    1414@set RTEMS-EDITION 1
    15 @set RTEMS-VERSION 4.5-beta1b
    16 @set RTEMS-UPDATE-DATE February 23 2000
    17 @set RTEMS-UPDATE-MONTH February 2000
     15@set RTEMS-VERSION 4.5-beta2
     16@set RTEMS-UPDATE-DATE April 13 2000
     17@set RTEMS-UPDATE-MONTH April 2000
    1818
    1919@c
  • doc/porting/interrupts.t

    r0765f9b rbb4b574  
    194194@end example
    195195
    196 If the CPU_HAS_SOFTWARE_INTERRUPT_STACK macro is set to TRUE, then RTEMS automatically allocates the stack memory in the initialization of the Interrupt Manager and the switch to that stack is performed in _ISR_Handler on the outermost interrupt.  The _CPU_Interrupt_stack_low and _CPU_Interrupt_stack_high variables contain the addresses of the the lowest and highest addresses of the memory allocated for the interrupt stack.  Although technically only one of these addresses is required to switch to the interrupt stack, by always providing both addresses, the port has more options avaialble to it without requiring modifications to the portable parts of the executive.  Whether the stack  grows up or down, this give the CPU dependent code the option of picking the version it wants to use.
     196If the CPU_HAS_SOFTWARE_INTERRUPT_STACK macro is set to TRUE, then RTEMS automatically allocates the stack memory in the initialization of the Interrupt Manager and the switch to that stack is performed in @code{_ISR_Handler} on the outermost interrupt.  The _CPU_Interrupt_stack_low and _CPU_Interrupt_stack_high variables contain the addresses of the the lowest and highest addresses of the memory allocated for the interrupt stack.  Although technically only one of these addresses is required to switch to the interrupt stack, by always providing both addresses, the port has more options avaialble to it without requiring modifications to the portable parts of the executive.  Whether the stack  grows up or down, this give the CPU dependent code the option of picking the version it wants to use.
    197197
    198198@example
     
    284284
    285285We put the actual user ISR address in _ISR_vector_table.  This will be
    286 used by the _ISR_Handler so the user gets control.
     286used by the @code{_ISR_Handler} so the user gets control.
    287287
    288288@example
     
    313313@subsection Interrupt Dispatching
    314314
    315 The _ISR_Handler routine provides the RTEMS interrupt management.
     315The @code{_ISR_Handler} routine provides the RTEMS interrupt management.
    316316 
    317317@example
     
    327327
    328328Also note that the exact order is to a large extent flexible.  Hardware
    329 will dictate a sequence for a certain subset of _ISR_Handler while
     329will dictate a sequence for a certain subset of @code{_ISR_Handler} while
    330330requirements for setting the RTEMS state variables that indicate the
    331 interrupt nest level (XX) and dispatching disable level (XXX) will also
     331interrupt nest level (@code{_ISR_Nest_level}) and dispatching disable
     332level (@code{_Thread_Dispatch_disable_level}) will also
    332333restrict the allowable order.
    333334
    334 Upon entry to the "common" _ISR_Handler, the vector number must be
     335Upon entry to @code{_ISR_Handler}, @code{_Thread_Dispatch_disable_level} is
     336zero if the interrupt occurred while outside an RTEMS service call.
     337Conversely, it will be non-zero if interrupting an RTEMS service
     338call.  Thus, @code{_Thread_Dispatch_disable_level} will always be
     339greater than or equal to @code{_ISR_Nest_level} and not strictly
     340equal. 
     341
     342Upon entry to the "common" @code{_ISR_Handler}, the vector number must be
    335343available.  On some CPUs the hardware puts either the vector number or the
    336344offset into the vector table for this ISR in a known place.  If the
     
    338346RTEMS for this port will contain a set of distinct interrupt entry points
    339347which somehow place the vector number in a known place (which is safe if
    340 another interrupt nests this one) and branches to _ISR_Handler.
     348another interrupt nests this one) and branches to @code{_ISR_Handler}.
    341349
    342350@example
     
    362370 
    363371if ( !_ISR_Signals_to_thread_executing )
    364     _ISR_Signals_to_thread_executing = FALSE;
    365372    goto the label "exit interrupt (simple case)"
     373
     374_ISR_Signals_to_thread_executing = FALSE;
    366375
    367376call _Thread_Dispatch() or prepare to return to _ISR_Dispatch
     
    373382 return from interrupt
    374383@end example
     384
     385Some ports have the special routine @code{_ISR_Dispatch} because
     386the CPU has a special "interrupt mode" and RTEMS must switch back
     387to the task stack and/or non-interrupt mode before invoking
     388@code{_Thread_Dispatch}.  For example, consider the MC68020 where
     389upon return from the outermost interrupt, the CPU must switch
     390from the interrupt stack to the master stack before invoking
     391@code{_Thread_Dispatch}.  @code{_ISR_Dispatch} is the special port
     392specific wrapper for @code{_Thread_Dispatch} used in this case.
    375393 
    376394@subsection ISR Invoked with Frame Pointer
  • doc/porting/prioritybitmap.t

    r0765f9b rbb4b574  
    2828routines is used to maintain and search the bit map array.
    2929
     30When manipulating the bitmap array, RTEMS internally divides the
     318 bits of the task priority into "major" and "minor" components.
     32The most significant 4 bits are the major component, while the least
     33significant are the minor component.  The major component of a priority
     34value is used to determine which 16-bit wide entry in the
     35@code{_Priority_Bit_map} array is associated with this priority.
     36Each element in the @code{_Priority_Bit_map} array has a bit
     37in the @code{_Priority_Major_bit_map} associated with it. 
     38That bit is cleared when all of the bits in a particular
     39@code{_Priority_Bit_map} array entry are zero.
     40
     41The minor component of a priority is used to determine
     42specifically which bit in @code{_Priority_Bit_map[major]}
     43indicates whether or not there is a ready to execute task
     44at the priority.
     45
     46 
    3047@section _Priority_Bit_map_control Type
    3148
    32 The _Priority_Bit_map_Control type is the fundamental data type of the
     49The @code{_Priority_Bit_map_Control} type is the fundamental data type of the
    3350priority bit map array used to determine which priorities have ready
    3451tasks.  This type may be either 16 or 32 bits wide although only the 16
     
    4259
    4360The _CPU_Bitfield_Find_first_bit routine sets _output to the bit number of
    44 the first bit set in _value.  _value is of CPU dependent type
    45 Priority_Bit_map_control.  A stub version of this routine is as follows:
     61the first bit set in @code{_value}.  @code{_value} is of CPU dependent type
     62@code{Priority_Bit_map_control}.  A stub version of this routine is as follows:
    4663
    4764@example
     
    5168  @}
    5269@end example
     70
     71
    5372
    5473There are a number of variables in using a "find first bit" type
     
    7089Cases (2),(3), (4) are handled by the macros _CPU_Priority_mask() and
    7190_CPU_Priority_bits_index().  These three form a set of routines which must
    72 logically operate together.  Bits in the _value are set and cleared based
     91logically operate together.  Bits in the @code{_value} are set and cleared based
    7392on masks built by CPU_Priority_mask().  The basic major and minor values
    7493calculated by _Priority_Major() and _Priority_Minor() are "massaged" by
     
    155174@section Bit Scan Support
    156175
    157 The _CPU_Priority_bits_index routine translates the bit numbers returned by _CPU_Bitfield_Find_first_bit() into something suitable for use as a major or minor component of a priority.  For example, the find first bit routine may number the bits in a way that is difficult to map into the major and minor components of the priority.  This routine allows that unwieldy form to be converted into something easier to process.  See the discussion of that routine for more details.
     176The @code{_CPU_Priority_bits_index} routine translates the bit numbers
     177returned by @code{_CPU_Bitfield_Find_first_bit()} into something
     178suitable for use as a major or minor component of a priority. 
     179The find first bit routine may number the bits in a
     180way that is difficult to map into the major and minor components
     181of the priority.  For example, when finding the first bit set in
     182the value 0x8000, a CPU may indicate that bit 15 or 16 is set
     183based on whether the least significant bit is "zero" or "one".
     184Similarly, a CPU may only scan 32-bit values and consider the
     185most significant bit to be bit zero or one.  In this case, this
     186would be bit 16 or 17.
     187
     188This routine allows that unwieldy form to be converted
     189into a normalized form that is easier to process and use
     190as an index. 
    158191
    159192@example
  • doc/porting/taskcontext.t

    r0765f9b rbb4b574  
    170170@end example
    171171
    172 This is_fp parameter is TRUE if the thread is to be a floating point
     172The @code{is_fp} parameter is TRUE if the thread is to be a floating point
    173173thread.  This is typically only used on CPUs where the FPU may be easily
    174174disabled by software such as on the SPARC where the PSR contains an enable
     
    177177a deferred floating point context switch is safe.
    178178
     179The @code{_stack_base} parameter is the base address of the memory area
     180allocated for use as the task stack.  It is critical to understand that
     181@code{_stack_base} may not be the starting stack pointer for this task.
     182On CPU families where the stack grows from high addresses to lower ones,
     183(i.e. @code{CPU_STACK_GROWS_UP} is FALSE) the starting stack point
     184will be near the end of the stack memory area or close to
     185@code{_stack_base} + @code{_size}.  Even on CPU families where the stack
     186grows from low to higher addresses, there may be some required
     187outermost stack frame that must be put at the address @code{_stack_base}.
     188
     189The @code{_size} parameter is the requested size in bytes of the stack for
     190this task.  It is assumed that the memory area @code{_stack_base}
     191is of this size.
     192
    179193XXX explain other parameters and check prototype
    180194
     
    189203  Context_Control  *heir
    190204);
     205@end example
     206
     207This routine begins by saving the current state of the
     208CPU (i.e. the context) in the context area at @code{run}.
     209Then the routine should load the CPU context pointed to
     210by @code{heir}.  Loading the new context will cause a
     211branch to its task code, so the task that invoked
     212@code{_CPU_Context_switch} will not run for a while. 
     213When, eventually, a context switch is made to load
     214context from @code{*run} again, this task will resume
     215and @code{_CPU_Context_switch} will return to its caller.
     216
     217Care should be exercise when writing this routine.  All
     218registers assumed to be preserved across subroutine calls
     219must be preserved.  These registers may be saved in
     220the task's context area or on its stack.  However, the
     221stack pointer and address to resume executing the task
     222at must be included in the context (normally the subroutine
     223return address to the caller of @code{_Thread_Dispatch}.
     224The decision of where to store the task's context is based
     225on numerous factors including the capabilities of
     226the CPU architecture itself and simplicity as well
     227as external considerations such as debuggers wishing
     228to examine a task's context.  In this case, it is
     229often simpler to save all data in the context area.
     230
     231Also there may be special considerations
     232when loading the stack pointers or interrupt level of the
     233incoming task.  Independent of CPU specific considerations,
     234if some context is saved on the task stack, then the porter
     235must ensure that the stack pointer is adjusted @b{BEFORE}
     236to make room for this context information before the
     237information is written.  Otherwise, an interrupt could
     238occur writing over the context data.  The following is
     239an example of an @b{INCORRECT} sequence:
     240
     241@example
     242save part of context beyond current top of stack
     243interrupt pushes context -- overwriting written context
     244interrupt returns
     245adjust stack pointer
    191246@end example
    192247
  • doc/started/gdb.t

    r0765f9b rbb4b574  
    6767If any files are found with the .rej extension, a patch has been rejected.
    6868This should not happen with a good patch file.
    69 
    70 To see the files that have been modified use the sequence:
    71 
    72 @example
    73 cd tools/@value{GDB-UNTAR}
    74 find . -name "*.orig" -print
    75 @end example
    76 
    77 The files that are found, have been modified by the patch file.
    7869
    7970@end ifset
  • doc/started/intro.t

    r0765f9b rbb4b574  
    128128@subsection RTEMS Mailing List
    129129
    130 rtems-list@@OARcorp.com
     130rtems-users@@OARcorp.com
    131131
    132 This mailing list is dedicated to discussion of issues related
    133 to RTEMS.  If you have questions about RTEMS, wish to make
    134 suggestions, or just want to pick up hints, this is a good
    135 list to subscribe to.  Subscribe by sending a message with
    136 the one line "subscribe" to rtems-list-request@@OARcorp.com.
     132This mailing list is dedicated to the discussion of issues related
     133to RTEMS, including GNAT/RTEMS.  If you have questions about RTEMS,
     134wish to make suggestions, or just want to pick up hints, this is a
     135good list to subscribe to.  Subscribe by sending an empty mail
     136message to rtems-users-subscribe@@OARcorp.com.  Messages sent
     137to rtems-users@@OARcorp.com are posted to the list.
    137138
    138139@subsection CrossGCC Mailing List
  • doc/started/sample.t

    r0765f9b rbb4b574  
    3737@example
    3838cd tools/hello_world_c
    39 gmake
     39make
    4040@end example
     41
     42NOTE: GNU make is the preferred @code{make} utility.  Other @code{make}
     43implementations may work but all testing is done with GNU make.
    4144
    4245If no errors are detected during the sample application build, it is
     
    5154
    5255@example
    53 tools/hello_world_c/o-<BOARD_SUPPORT_PACKAGE>/<filename>.exe
     56tools/hello_world_c/o-optimize/<filename>.exe
    5457@end example
    5558
  • doc/started_ada/intro.t

    r0765f9b rbb4b574  
    128128@subsection RTEMS Mailing List
    129129
    130 rtems-list@@OARcorp.com
     130rtems-users@@OARcorp.com
    131131
    132 This mailing list is dedicated to discussion of issues related
    133 to RTEMS.  If you have questions about RTEMS, wish to make
    134 suggestions, or just want to pick up hints, this is a good
    135 list to subscribe to.  Subscribe by sending a message with
    136 the one line "subscribe" to rtems-list-request@@OARcorp.com.
     132This mailing list is dedicated to the discussion of issues related
     133to RTEMS, including GNAT/RTEMS.  If you have questions about RTEMS,
     134wish to make suggestions, or just want to pick up hints, this is a
     135good list to subscribe to.  Subscribe by sending an empty mail
     136message to rtems-users-subscribe@@OARcorp.com.  Messages sent
     137to rtems-users@@OARcorp.com are posted to the list.
    137138
    138139@subsection CrossGCC Mailing List
  • doc/started_ada/sample.t

    r0765f9b rbb4b574  
    3333@example
    3434cd tools/hello_world_ada
    35 gmake -f Makefile.<BOARD_SUPPORT_PACKAGE>
     35make -f Makefile.<BOARD_SUPPORT_PACKAGE>
    3636@end example
     37
     38NOTE: GNU make is the preferred @code{make} utility.  Other @code{make}
     39implementations may work but all testing is done with GNU make.
    3740
    3841If the BSP specific modifications to the Makefile were correct and
     
    4851
    4952@example
    50 tools/hello_world_ada/o-<BOARD_SUPPORT_PACKAGE>/<filename>.exe
     53tools/hello_world_ada/o-optimize/<filename>.exe
    5154@end example
    5255
  • doc/user/sem.t

    r0765f9b rbb4b574  
    194194
    195195@item @code{@value{RPREFIX}SIMPLE_BINARY_SEMAPHORE} - restrict values to
    196 0 and 1 and do not allow nested access.
     1960 and 1, do not allow nested access, allow deletion of locked semaphore.
    197197
    198198@item @code{@value{RPREFIX}NO_INHERIT_PRIORITY} - do not use priority
     
    453453
    454454@item @code{@value{RPREFIX}SIMPLE_BINARY_SEMAPHORE} - restrict values to
    455 0 and 1 and do not allow nested access.
     4550 and 1, block on nested access, allow deletion of locked semaphore.
    456456
    457457@item @code{@value{RPREFIX}NO_INHERIT_PRIORITY} - do not use priority
Note: See TracChangeset for help on using the changeset viewer.