From adee597960ce3c5ff0ce303ae9ac25b7eebdfe32 Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Thu, 4 May 2000 19:45:17 +0000 Subject: Numerous changes based on comments from Stephan Wilms including a new section in the Getting Started called "Where to Go From Here", lots of index entries added, and more configuration table information. --- doc/user/clock.t | 22 +++++++++++++++++++--- doc/user/concepts.t | 42 ++++++++++++++++++++++++++++++++++++------ doc/user/conf.t | 25 +++++++++++++++++-------- doc/user/event.t | 9 +++++++-- doc/user/example.texi | 9 ++++++--- doc/user/fatal.t | 2 ++ doc/user/init.t | 6 +++--- doc/user/intr.t | 9 ++++++++- doc/user/io.t | 7 +++++++ doc/user/mp.t | 9 ++++++--- doc/user/rtmon.t | 5 +++-- doc/user/signal.t | 8 +++++++- doc/user/task.t | 30 ++++++++++++++++++++++-------- doc/user/timer.t | 1 + doc/user/userext.t | 32 +++++++++++++++++++------------- 15 files changed, 163 insertions(+), 53 deletions(-) (limited to 'doc/user') diff --git a/doc/user/clock.t b/doc/user/clock.t index f27748d4e3..be61b9651a 100644 --- a/doc/user/clock.t +++ b/doc/user/clock.t @@ -42,7 +42,9 @@ The clock facilities of the clock manager operate upon calendar time. These directives utilize the following date and time @value{STRUCTURE} for the native time and date format: + @ifset is-C +@findex rtems_time_of_day @example struct rtems_tod_control @{ rtems_unsigned32 year; /* greater than 1987 */ @@ -108,6 +110,8 @@ seconds since the RTEMS epoch of January 1, 1988. @subsection Clock Tick and Timeslicing +@cindex timeslicing + Timeslicing is a task scheduling discipline in which tasks of equal priority are executed for a specific period of time before control of the CPU is passed to another task. It is @@ -129,6 +133,8 @@ ready task of equal priority. @subsection Delays +@cindex delays + A sleep timer allows a task to delay for a given interval or up until a given time, and then wake and continue execution. This type of timer is created automatically by the @@ -140,6 +146,8 @@ sleep timer at a time. @subsection Timeouts +@cindex timeouts + Timeouts are a special type of timer automatically created when the timeout option is used on the @code{@value{DIRPREFIX}message_queue_receive}, @@ -190,8 +198,12 @@ the number of seconds since the RTEMS epoch, the number of ticks since the executive was initialized, and the number of ticks per second. The information returned by the @code{@value{DIRPREFIX}clock_get} directive is -dependent on the option selected by the caller. The following -options are available: +dependent on the option selected by the caller. This +is specified using one of the following constants +associated with the enumerated type +@code{@value{DIRPREFIX}clock_get_options}: + +@findex rtems_clock_get_options @itemize @bullet @item @code{@value{RPREFIX}CLOCK_GET_TOD} - obtain native style date and time @@ -325,8 +337,12 @@ The caller can always obtain the number of ticks per second (option is ticks since the executive was initialized option is @code{@value{RPREFIX}CLOCK_GET_TICKS_SINCE_BOOT}). -The data type expected for time_buffer is indicated below: +The @code{option} argument may taken on any value of the enumerated +type @code{rtems_clock_get_options}. The data type expected for +@code{time_buffer} is based on the value of @code{option} as +indicated below: +@findex rtems_clock_get_options @ifset is-C @itemize @bullet @item @code{@value{RPREFIX}CLOCK_GET_TOD} - (rtems_time_of_day *) diff --git a/doc/user/concepts.t b/doc/user/concepts.t index e81738be00..5afc317128 100644 --- a/doc/user/concepts.t +++ b/doc/user/concepts.t @@ -43,15 +43,32 @@ reflect the object's use in the application. Conversely, object IDs are designed to facilitate efficient object manipulation by the executive. +@subsection Object Names + @cindex object name +@findex rtems_object_name An object name is an unsigned thirty-two bit entity -associated with the object by the user. Although not required -by RTEMS, object names are typically composed of four ASCII -characters which help identify that object. For example, a task -which causes a light to blink might be called "LITE". Utilities -are provided to build an object name from four ASCII characters -and to decompose an object name into four ASCII characters. +associated with the object by the user. The data type +@code{@value{DIRPREFIX}name} is used to store object names. + +@findex rtems_build_name + +Although not required by RTEMS, object names are often +composed of four ASCII characters which help identify that object. +For example, a task which causes a light to blink might be +called "LITE". The @code{@value{DIRPREFIX}build_name} routine +is provided to build an object name from four ASCII characters. +@ifset is-C +The following example illustrates this: + +@example +rtems_object_name my_name; + +my_name = rtems_build_name( 'L', 'I', 'T', 'E' ); +@end example +@end ifset + However, it is not required that the application use ASCII characters to build object names. For example, if an application requires one-hundred tasks, it would be difficult to @@ -59,13 +76,18 @@ assign meaningful ASCII names to each task. A more convenient approach would be to name them the binary values one through one-hundred, respectively. +@subsection Object IDs + @cindex object ID @cindex object ID composition +@findex rtems_id @need 3000 An object ID is a unique unsigned thirty-two bit entity composed of three parts: object class, node, and index. +The data type @code{@value{DIRPREFIX}id} is used to store object IDs. + @ifset use-ascii @example @@ -259,6 +281,8 @@ known as a tick. The frequency of clock ticks is completely application dependent and determines the granularity and accuracy of all interval and calendar time operations. +@findex rtems_interval + By tracking time in units of ticks, RTEMS is capable of supporting interval timing functions such as task delays, timeouts, timeslicing, the delayed execution of timer service @@ -267,6 +291,8 @@ interval is defined as a number of ticks relative to the current time. For example, when a task delays for an interval of ten ticks, it is implied that the task will not execute until ten clock ticks have occurred. +All intervals are specified using data type +@code{@value{DIRPREFIX}interval}. A characteristic of interval timing is that the actual interval period may be a fraction of a tick less than the @@ -291,6 +317,10 @@ date and time. This allows selected time operations to be scheduled at an actual calendar date and time. For example, a task could request to delay until midnight on New Year's Eve before lowering the ball at Times Square. +The data type @code{@value{DIRPREFIX}time_of_day} is used to specify +calendar time in RTEMS services. +@xref{Clock Manager Time and Date Data Structures, , Time and Date Data Structures}. +@findex rtems_time_of_day Obviously, the directives which use intervals or wall time cannot operate without some external mechanism which diff --git a/doc/user/conf.t b/doc/user/conf.t index 235bf8047c..17692781c8 100644 --- a/doc/user/conf.t +++ b/doc/user/conf.t @@ -204,6 +204,7 @@ The RTEMS Configuration Table is defined in the following @value{LANGUAGE} @value{STRUCTURE}: @ifset is-C +@findex rtems_configuration_table @example @group typedef struct @{ @@ -262,7 +263,10 @@ RTEMS will invoke the fatal error handler during @code{@value{DIRPREFIX}initialize_executive}. When using the @code{confdefs.h} mechanism for configuring an RTEMS application, the value for this field corresponds -to the setting of the macro @code{CONFIGURE_EXECUTIVE_RAM_WORK_AREA}. +to the setting of the macro @code{CONFIGURE_EXECUTIVE_RAM_WORK_AREA} +which defaults to @code{NULL}. Normally, this field should be +configured as @code{NULL} as BSPs will assign memory for the +RTEMS RAM Workspace as part of system initialization. @item work_space_size is the calculated size of the @@ -278,9 +282,9 @@ is number of microseconds per clock tick. When using the @code{confdefs.h} mechanism for configuring an RTEMS application, the value for this field corresponds to the setting of the macro @code{CONFIGURE_MICROSECONDS_PER_TICK}. -If not defined by the application, then the @code{CONFIGURE_MAXIMUM_TASKS} -macro defaults to 10. -XXX +If not defined by the application, then the +@code{CONFIGURE_MICROSECONDS_PER_TICK} macro defaults to 10000 +(10 milliseconds). @item ticks_per_timeslice is the number of clock ticks for a timeslice. @@ -374,8 +378,8 @@ configuration. This field must be NULL when RTEMS is used in a single processor configuration. When using the @code{confdefs.h} mechanism for configuring an RTEMS application, the Multiprocessor Configuration Table -is automatically generated when the @code{CONFIGURE_MPTEST} -is defined. If @code{CONFIGURE_MPTEST} is not defined, the this +is automatically generated when the @code{CONFIGURE_MP_APPLICATION} +is defined. If @code{CONFIGURE_MP_APPLICATION} is not defined, the this entry is set to NULL. The generated table has the name @code{Multiprocessing_configuration}. @@ -412,6 +416,7 @@ this application. The RTEMS API Configuration Table is defined in the following @value{LANGUAGE} @value{STRUCTURE}: @ifset is-C +@findex rtems_api_configuration_table @example @group typedef struct @{ @@ -590,6 +595,8 @@ this application. The POSIX API Configuration Table is defined in the following @value{LANGUAGE} @value{STRUCTURE}: @ifset is-C +@findex posix_initialization_threads_table +@findex posix_api_configuration_table @example @group typedef struct @{ @@ -774,6 +781,7 @@ Initialization Task Table is defined in the following @value{LANGUAGE} @value{STRUCTURE}: @ifset is-C +@findex rtems_initialization_tasks_table @example typedef struct @{ rtems_name name; @@ -897,6 +905,7 @@ Driver Table is defined in the following @value{LANGUAGE} @value{STRUCTURE}: @ifset is-C +@findex rtems_driver_address_table @example typedef struct @{ rtems_device_driver_entry initialization; @@ -1164,9 +1173,9 @@ Multiprocessing chapter. When using the @code{confdefs.h} mechanism for configuring -an RTEMS application, the macro @code{CONFIGURE_MPTEST} must +an RTEMS application, the macro @code{CONFIGURE_MP_APPLICATION} must be defined to automatically generate the Multiprocessor Configuration Table. -If @code{CONFIGURE_MPTEST}, is not defined, then a NULL pointer +If @code{CONFIGURE_MP_APPLICATION}, is not defined, then a NULL pointer is configured as the address of this table. The format of the Multiprocessor Configuration Table is defined in diff --git a/doc/user/event.t b/doc/user/event.t index 028881be1a..5a3abfb58a 100644 --- a/doc/user/event.t +++ b/doc/user/event.t @@ -25,13 +25,18 @@ provided by the event manager are: @subsection Event Sets +@cindex event flag, definition @cindex event set, definition +@findex rtems_event_set An event flag is used by a task (or ISR) to inform another task of the occurrence of a significant situation. Thirty-two event flags are associated with each task. A collection of one or more event flags is referred to as an event -set. The application developer should remember the following +set. The data type @code{@value{DIRPREFIX}event_set} is used to manage +event sets. + +The application developer should remember the following key characteristics of event operations when utilizing the event manager: @@ -53,7 +58,7 @@ subsequent send operations to that same task have no effect. An event set is posted when it is directed (or sent) to a task. A pending event is an event that has been posted but not received. An event -condition is used to specify the events which the task desires to receive +condition is used to specify the event set which the task desires to receive and the algorithm which will be used to determine when the request is satisfied. An event condition is satisfied based upon one of two algorithms which are selected by the user. The diff --git a/doc/user/example.texi b/doc/user/example.texi index 70f6e32ea0..50ab07c4c4 100644 --- a/doc/user/example.texi +++ b/doc/user/example.texi @@ -18,8 +18,11 @@ * application. It contains a Configuration Table, a * user initialization task, and a simple task. * - * This example assumes that a board support package exists - * and invokes the initialize_executive() directive. + * This example assumes that a board support package exists. + * + * Most applications will actually use the confdefs.h method + * to generate their configuration. This is provided primarily + * for reference. */ #include "rtems.h" @@ -40,7 +43,7 @@ rtems_initialization_tasks_table init_task = @{ @}; rtems_configuration_table User_Configuration_Table = @{ - NULL, /* filled in by the BSP */ + NULL, /* dynamically assigned by the BSP */ 65536, /* executive RAM size */ 2, /* maximum tasks */ 0, /* maximum timers */ diff --git a/doc/user/fatal.t b/doc/user/fatal.t index b036611eb8..dbad064ec6 100644 --- a/doc/user/fatal.t +++ b/doc/user/fatal.t @@ -66,6 +66,8 @@ a specific target processor. @subsection Announcing a Fatal Error +@findex _Internal_errors_What_happened + The @code{@value{DIRPREFIX}fatal_error_occurred} directive is invoked when a fatal error is detected. Before invoking any user-supplied fatal error handlers or the RTEMS fatal error handler, the diff --git a/doc/user/init.t b/doc/user/init.t index 58045a0ab8..8e23816f7c 100644 --- a/doc/user/init.t +++ b/doc/user/init.t @@ -87,7 +87,7 @@ other task is made ready to execute. @subsection Initialization Manager Failure -The fatal_error_occurred directive will be called +The @code{@value{DIRPREFIX}ifatal_error_occurred} directive will be called from @code{@value{DIRPREFIX}initialize_executive} for any of the following reasons: @@ -307,8 +307,8 @@ be the same one passed to The application must use only one of the two initialization sequences: @code{@value{DIRPREFIX}initialize_executive} or -@code{@value{DIRPREFIX}nitialize_executive_early} and -@code{@value{DIRPREFIX}nitialize_executive_late}. +@code{@value{DIRPREFIX}initialize_executive_early} and +@code{@value{DIRPREFIX}initialize_executive_late}. @page @subsection INITIALIZE_EXECUTIVE_LATE - Complete Initialization and Start Multitasking diff --git a/doc/user/intr.t b/doc/user/intr.t index dac3b57141..8e5e9cb8de 100644 --- a/doc/user/intr.t +++ b/doc/user/intr.t @@ -43,13 +43,20 @@ processor and invokes the user's ISR. The user's ISR is responsible for processing the interrupt, clearing the interrupt if necessary, and device specific manipulation. +@findex rtems_vector_number + The @code{@value{DIRPREFIX}interrupt_catch} directive connects a procedure to -an interrupt vector. The interrupt service routine is assumed +an interrupt vector. The vector number is managed using +the @code{@value{DIRPREFIX}vector_number} data type. + +The interrupt service routine is assumed to abide by these conventions and have a prototype similar to the following: @ifset is-C +@findex rtems_isr + @example rtems_isr user_isr( rtems_vector_number vector diff --git a/doc/user/io.t b/doc/user/io.t index 9ab2be053e..a405994ec2 100644 --- a/doc/user/io.t +++ b/doc/user/io.t @@ -70,6 +70,13 @@ The exact usage of the minor number is driver specific, but is commonly used to distinguish between a number of devices controlled by the same driver. +@findex rtems_device_major_number +@findex rtems_device_minor_number + +The data types @code{@value{DIRPREFIX}device_major_number} and +@code{@value{DIRPREFIX}device_minor_number} are used to +manipulate device major and minor numbers, respectively. + @subsection Device Names @cindex device names diff --git a/doc/user/mp.t b/doc/user/mp.t index 5840d64ebb..69863ba872 100644 --- a/doc/user/mp.t +++ b/doc/user/mp.t @@ -301,6 +301,7 @@ been initialized. This component should be adhere to the following prototype: @ifset is-C +@findex rtems_mpci_entry @example @group rtems_mpci_entry user_mpci_initialization( @@ -465,13 +466,15 @@ MPCI layers will be built upon hardware which support a broadcast mechanism, others may be required to generate a copy of the packet for each node in the system. -Many MPCI layers use the packet_length field of the MP_packet_prefix +@c XXX packet_prefix structure needs to be defined in this document +Many MPCI layers use the @code{packet_length} field of the +@code{@value{DIRPREFIX}packet_prefix} portion of the packet to avoid sending unnecessary data. This is especially useful if the media connecting the nodes is relatively slow. The to_convert field of the MP_packet_prefix portion of the packet indicates -how much of the packet (in unsigned32's) may require conversion in a -heterogeneous system. +how much of the packet (in @code{@value{DIRPREFIX}unsigned32}'s) may require +conversion in a heterogeneous system. @subsection Supporting Heterogeneous Environments diff --git a/doc/user/rtmon.t b/doc/user/rtmon.t index a8c359ea7d..bcfd8a6053 100644 --- a/doc/user/rtmon.t +++ b/doc/user/rtmon.t @@ -1137,11 +1137,12 @@ This directive returns status information associated with the rate monotonic period id in the following data @value{STRUCTURE}: @ifset is-C +@findex rtems_rate_monotonic_period_status @example typedef struct @{ rtems_rate_monotonic_period_states state; - unsigned32 ticks_since_last_period; - unsigned32 ticks_executed_since_last_period; + rtems_unsigned32 ticks_since_last_period; + rtems_unsigned32 ticks_executed_since_last_period; @} rtems_rate_monotonic_period_status; @end example @end ifset diff --git a/doc/user/signal.t b/doc/user/signal.t index 012824fc71..50beb752f9 100644 --- a/doc/user/signal.t +++ b/doc/user/signal.t @@ -37,11 +37,16 @@ signal is sent to a task, that task's execution path will be "interrupted" by the ASR. Sending a signal to a task has no effect on the receiving task's current execution state. +@findex rtems_signal_set + A signal flag is used by a task (or ISR) to inform another task of the occurrence of a significant situation. Thirty-two signal flags are associated with each task. A collection of one or more signals is referred to as a signal -set. A signal set is posted when it is directed (or sent) to a +set. The data type @code{@value{DIRPREFIX}signal_set} +is used to manipulate signal sets. + +A signal set is posted when it is directed (or sent) to a task. A pending signal is a signal that has been sent to a task with a valid ASR, but has not been processed by that task's ASR. @@ -216,6 +221,7 @@ The ASR should have the following calling sequence and adhere to @value{LANGUAGE} calling conventions: @ifset is-C +@findex rtems_asr @example rtems_asr user_routine( rtems_signal_set signals diff --git a/doc/user/task.t b/doc/user/task.t index e399f2ea74..5db64eeca3 100644 --- a/doc/user/task.t +++ b/doc/user/task.t @@ -120,10 +120,15 @@ current state and priority. @cindex task priority @cindex priority, task +@findex rtems_task_priority A task's priority determines its importance in relation to the other tasks executing on the same processor. RTEMS supports 255 -levels of priority ranging from 1 to 255. Tasks of numerically +levels of priority ranging from 1 to 255. The data type +@code{@value{DIRPREFIX}task_priority} is used to store task +priorities. + +Tasks of numerically smaller priority values are more important tasks than tasks of numerically larger priority values. For example, a task at priority level 5 is of higher privilege than a task at priority @@ -143,8 +148,10 @@ processor execution time. @subsection Task Mode @cindex task mode +@findex rtems_task_mode -A task's mode is a combination of the following four components: +A task's execution mode is a combination of the following +four components: @itemize @bullet @item preemption @@ -154,7 +161,9 @@ A task's mode is a combination of the following four components: @end itemize It is used to modify RTEMS' scheduling process and to alter the -execution environment of the task. +execution environment of the task. The data type +@code{@value{DIRPREFIX}task_mode} is used to manage the task +execution mode. @cindex preemption @@ -210,6 +219,7 @@ specifies that the task will execute at interrupt level n. @subsection Accessing Task Arguments @cindex task arguments +@cindex task prototype All RTEMS tasks are invoked with a single argument which is specified when they are started or restarted. The argument is @@ -218,6 +228,8 @@ The simplest manner in which to define a task which accesses it argument is: @ifset is-C +@findex rtems_task + @example rtems_task user_task( rtems_task_argument argument @@ -240,7 +252,8 @@ single argument as an index into an array of parameter blocks. @cindex floating point -Creating a task with the @code{@value{RPREFIX}FLOATING_POINT} flag results +Creating a task with the @code{@value{RPREFIX}FLOATING_POINT} attribute +flag results in additional memory being allocated for the TCB to store the state of the numeric coprocessor during task switches. This additional memory is @b{NOT} allocated for @code{@value{RPREFIX}NO_FLOATING_POINT} tasks. Saving @@ -726,10 +739,6 @@ This directive will not cause the calling task to be preempted. Valid task priorities range from a high of 1 to a low of 255. -RTEMS supports a maximum of 256 interrupt levels which are -mapped onto the interrupt levels actually supported by the -target processor. - The requested stack size should be at least @code{@value{RPREFIX}MINIMUM_STACK_SIZE} bytes. The value of @code{@value{RPREFIX}MINIMUM_STACK_SIZE} @@ -760,6 +769,11 @@ The following task mode constants are defined by RTEMS: @item @code{@value{RPREFIX}INTERRUPT_LEVEL(n)} - execute at interrupt level n @end itemize +The interrupt level portion of the task execution mode +supports a maximum of 256 interrupt levels. These levels are +mapped onto the interrupt levels actually supported by the +target processor in a processor dependent fashion. + Tasks should not be made global unless remote tasks must interact with them. This avoids the system overhead incurred by the creation of a global task. When a global task is created, diff --git a/doc/user/timer.t b/doc/user/timer.t index 250cb4a76c..b82adb5e9c 100644 --- a/doc/user/timer.t +++ b/doc/user/timer.t @@ -58,6 +58,7 @@ The timer service routine should adhere to @value{LANGUAGE} calling conventions and have a prototype similar to the following: @ifset is-C +@findex rtems_timer_service_routine @example rtems_timer_service_routine user_routine( rtems_id timer_id, diff --git a/doc/user/userext.t b/doc/user/userext.t index 1a0a16fca1..f514a08663 100644 --- a/doc/user/userext.t +++ b/doc/user/userext.t @@ -56,6 +56,7 @@ performance monitoring or debugger support. RTEMS is informed of the entry points which constitute an extension set via the following @value{STRUCTURE}: +@findex rtems_extensions_table @ifset is-C @example @group @@ -68,7 +69,7 @@ typedef struct @{ rtems_task_begin_extension thread_begin; rtems_task_exitted_extension thread_exitted; rtems_fatal_extension fatal; -@} User_extensions_Table; +@} rtems_extensions_table; @end group @end example @end ifset @@ -169,7 +170,7 @@ its arguments are all defined by the user. The names used in the examples were arbitrarily chosen and impose no naming conventions on the user. -@subsection TASK_CREATE Extension +@subsubsection TASK_CREATE Extension The TASK_CREATE extension directly corresponds to the task_create directive. If this extension is defined in any @@ -178,6 +179,8 @@ then the extension routine will automatically be invoked by RTEMS. The extension should have a prototype similar to the following: +@findex rtems_task_create_extension +@findex rtems_extension @ifset is-C @example rtems_extension user_task_create( @@ -203,7 +206,7 @@ invoked from the task_create directive after new_task has been completely initialized, but before it is placed on a ready TCB chain. -@subsection TASK_START Extension +@subsubsection TASK_START Extension The TASK_START extension directly corresponds to the task_start directive. If this extension is defined in any @@ -212,6 +215,7 @@ then the extension routine will automatically be invoked by RTEMS. The extension should have a prototype similar to the following: +@findex rtems_task_start_extension @ifset is-C @example rtems_extension user_task_start( @@ -237,7 +241,7 @@ extension is invoked from the task_start directive after started_task has been made ready to start execution, but before it is placed on a ready TCB chain. -@subsection TASK_RESTART Extension +@subsubsection TASK_RESTART Extension The TASK_RESTART extension directly corresponds to the task_restart directive. If this extension is defined in any @@ -245,6 +249,7 @@ static or dynamic extension set and a task is being restarted, then the extension should have a prototype similar to the following: +@findex rtems_task_restart_extension @ifset is-C @example rtems_extension user_task_restart( @@ -270,7 +275,7 @@ invoked from the task_restart directive after restarted_task has been made ready to start execution, but before it is placed on a ready TCB chain. -@subsection TASK_DELETE Extension +@subsubsection TASK_DELETE Extension The TASK_DELETE extension is associated with the task_delete directive. If this extension is defined in any @@ -279,6 +284,7 @@ then the extension routine will automatically be invoked by RTEMS. The extension should have a prototype similar to the following: +@findex rtems_task_delete_extension @ifset is-C @example rtems_extension user_task_delete( @@ -306,7 +312,7 @@ including the TCB have been returned to their respective free pools. This extension should not call any RTEMS directives if a task is deleting itself (current_task is equal to deleted_task). -@subsection TASK_SWITCH Extension +@subsubsection TASK_SWITCH Extension The TASK_SWITCH extension corresponds to a task context switch. If this extension is defined in any static or @@ -315,6 +321,7 @@ then the extension routine will automatically be invoked by RTEMS. The extension should have a prototype similar to the following: +@findex rtems_task_switch_extension @ifset is-C @example rtems_extension user_task_switch( @@ -341,13 +348,14 @@ context has been saved, but before the heir_task context has been restored. This extension should not call any RTEMS directives. -@subsection TASK_BEGIN Extension +@subsubsection TASK_BEGIN Extension The TASK_BEGIN extension is invoked when a task begins execution. It is invoked immediately before the body of the starting procedure and executes in the context in the task. This user extension have a prototype similar to the following: +@findex rtems_task_begin_extension @ifset is-C @example rtems_extension user_task_begin( @@ -372,13 +380,14 @@ task while the TASK_START extension is executed in the context of the task performing the task_start directive. For most extensions, this is not a critical distinction. -@subsection TASK_EXITTED Extension +@subsubsection TASK_EXITTED Extension The TASK_EXITTED extension is invoked when a task exits the body of the starting procedure by either an implicit or explicit return statement. This user extension have a prototype similar to the following: +@findex rtems_task_exitted_extension @ifset is-C @example rtems_extension user_task_exitted( @@ -407,9 +416,7 @@ returns control to RTEMS, then the RTEMS default handler will be used. This default handler invokes the directive fatal_error_occurred with the @code{@value{RPREFIX}TASK_EXITTED} directive status. -@lowersections - -@subsection FATAL Error Extension +@subsubsection FATAL Error Extension The FATAL error extension is associated with the fatal_error_occurred directive. If this extension is defined in @@ -417,6 +424,7 @@ any static or dynamic extension set and the fatal_error_occurred directive has been invoked, then this extension will be called. This extension should have a prototype similar to the following: +@findex rtems_fatal_extension @ifset is-C @example rtems_extension user_fatal_error( @@ -445,8 +453,6 @@ the processor is stopped. For example, this extension could be used to pass control to a debugger when a fatal error occurs. This extension should not call any RTEMS directives. -@raisesections - @subsection Order of Invocation When one of the critical system events occur, the -- cgit v1.2.3