Table of Contents
Previous Chapter
Table of Contents
Previous Chapter
The Back End Processor software uses a Commercial Off-The-Shelf Real-Time Executive for its underlying implementation. This executive is known as Nucleus RTX, from Accelerated Technology Inc. This executive provides the key functions for preemptive multi-tasking, semaphore management, inter-task queue management and memory partition management. Access to this executive is provided using an in-house developed Executive Interface Layer.
Nucleus RTX recommends a certain layout for the linker memory map. Table 57, "RTX Memory Map," on page 88 illustrates this layout. The key requirement imposed by Nucleus is that a section of data memory be reserved for RTX data structures, task stacks, and for use by the variable memory allocation features. This region of memory is bounded by the address of the RTX marker variable "IN_Last_Address_Used" and the contents of the pointer "IN_Last_Memory_Address" (a pointer to the last address in the region). The delivered software places the "IN_Last_Address_Used" variable as the last element of the configuration data file, "in_data.c." Hence, the vendor's documentation recommends that it be located by the linker as the last object file in the initialized and uninitialized data sections of memory. If necessary, the location of this region of memory can be customized by controlling where "IN_Last_Address_Used" is located by the linker, and by loading "IN_Last_Memory_Address" with the desired last address of the region.
Nucleus RTX provides the capability to establish a fixed set of tasks at compile time by use of an array of task initialization data structures, "IN_System_Tasks." Each entry corresponds to a single task, where the array index defines the Task Id. Each task entry specifies the following information:
Table 14 lists the service calls Nucleus RTX provides to control task and interrupt execution:
TABLE 14. RTX Task and Interrupt Service Calls
----------------------------------------------------------------------------------- Function Description Expect to Use----------------------------------------------------------------------------------- NU_Change_Priority() Change the task priority No NU_Change_Time_Slice() Change the task's time-slice No NU_Control_Interrupts() Enable/Disable Interrupts Yes NU_Current_Task_Id() Return Id of current task Yes NU_Disable_Preemption() Disable Context Switching Yes NU_Enable_Preemption() Enable Context Switching Yes NU_Relinquish() Allow other tasks of same priority to run Yes NU_Reset() Reset task to initial state No NU_Retrieve_Task_Status() Retrieve status for a specified task Yes NU_Sleep() Relinquish control for a period of time Yes NU_Start() Start a suspended task Yes NU_Stop() Suspend a running task No -----------------------------------------------------------------------------------
Nucleus RTX provides sets of discrete event flags, which can be used by application code to control task scheduling. Event flags are organized around event groups. Each event group consists of a number of discrete event flags, where the number is determined by the number of bits in an unsigned C-language integer value. In the case of ACIS, this is 32-bits.
A task waits on one or more event flags in a single event group. If the requested flags are not set, the task suspends execution. Another task, or interrupt handler, can then set one or more of the events in the group. The waiting task is then scheduled and continues execution. A given event group is not task specific, so if more than one task is waiting on an event in a group, all of the waiting tasks are scheduled when the event is asserted.
(Application Note: If task-specific event notification is needed, the application layer could allocate one event group per task. Broadcasts would then have to iterate through each task, setting the broadcasted event(s) in the task's event group.)
The number of event groups are defined at compile time by the variable "IN_System_Event_Groups." This variable is defined in the Nucleus configuration file, "in_data.c." The event group id's range from 0 to "IN_System_Event_Groups" minus 1.
Table 15 lists the Nucleus RTX service calls involved with event management.
TABLE 15. RTX Event Management Service Calls
---------------------------------------------------------------------------------- Function Description Expect to Use---------------------------------------------------------------------------------- NU_Set_Events() Set or clear events within an event group Yes NU_Wait_For_Events() Suspend task until the desired events are set Yes ----------------------------------------------------------------------------------
Nucleus RTX provides a set of semaphores (or "resource locks"), which can be used by the application code to arbitrate for common resources. The number of semaphores is defined at compile time by the contents of the variable "IN_System_Resources," defined in "in_data.c." The semaphore id's range from 0 to "IN_System_Resources" minus 1.
The application defines a semaphore for each device or memory item which must be shared between two or more tasks. When a task needs to access the resource, it first attempts to obtain the semaphore associated with the resource. If another task has already obtained the semaphore, the requesting task may wait for the other task to release it. Once the other task releases the semaphore, the requesting task wakes up and may proceed to use the resource. Once the task is done with the resource, it must release the semaphore, allowing other tasks to use it. Nucleus RTX allows several tasks to wait on a semaphore.
Table 16 lists the semaphore service calls provided by Nucleus RTX.
TABLE 16. RTX Semaphore Service Calls
------------------------------------------------------------------------------------- Function Description Expect to Use------------------------------------------------------------------------------------- NU_Release_Resource() Release an already obtained semaphore Yes NU_Request_Resource() Attempt to obtain a semaphore Yes NU_Retrieve_Resource_Status() Get the # of tasks waiting on semaphore Yes -------------------------------------------------------------------------------------
Nucleus RTX provides a fixed number of fixed length Inter-process communication Queues. The number and size of the queues are determined at compile time by an array of queue definition data structures, "IN_System_Queues." The queue id is determined by the entry index into this array. Each entry in the array defines the following:
A task may read or write items to and from the queue. If a queue is empty, a task may wait on the queue until an item is written. A task may also suspend when attempting to write to a full queue. Nucleus also provides the functions which can wait for data from up to three queues at once.
Table 17 lists the queue service calls provided by Nucleus RTX.
TABLE 17. RTX Queue Service Calls
----------------------------------------------------------------------------------- Function Description Expect to Use----------------------------------------------------------------------------------- NU_Force_Item_In_Front() Force item to the head of the queue No NU_Retrieve_Item() Wait for and read item from a queue Yes NU_Retrieve_Item_Multi() Wait/Read an item from up to 3 queues No NU_Retrieve_Queue_Status() Get number of items currently in a queue Yes NU_Send_Item() Write an item to the tail of a queue Yes -----------------------------------------------------------------------------------
Nucleus RTX provides two types of memory management facilities, fixed length partitions, and a general purpose heap. ACIS currently only expects to use the fixed length partition facilities.
The fixed length memory partitions are defined at compile time by an array of partition definition data structures, "IN_Fixed_Partitions." Each entry in the array corresponds to a particular pool of memory partitions, where the entry's array index defines the Partition Id. Each entry specifies the following:
A task may allocate or release a partition block from a given pool. If no partitions are available, a task may suspend until one is released by another task. More than one task may block on a pool.
Nucleus RTX also provides functions which manage buffers of arbitrary sizes from a general purpose memory heap. A task may allocate and release any size block from the heap. A task may also suspend until enough memory has been released by another task to satisfy the suspended tasks request. ACIS does not expect to use these facilities of Nucleus RTX.
Table 18 lists the memory management service calls provided by Nucleus RTX.
TABLE 18. RTX Memory Management Service Calls
--------------------------------------------------------------------------- Function Description Expect to Use--------------------------------------------------------------------------- NU_Alloc_Memory() Allocate memory from heap No NU_Alloc_Partition() Allocate a memory partition Yes NU_Available_Memory() Get the amount of free heap space No NU_Available_Partitions() Get the number of free partitions Yes NU_Dealloc_Memory() Release memory to the heap No NU_Dealloc_Partition() Release a partition to its pool Yes ---------------------------------------------------------------------------
Nucleus RTX provides service calls to set and read the system clock. This clock is maintained by the one of the ACIS timing interrupt handlers (i.e. the General Purpose Timer interrupt, or the Telemetry Frame interrupt).
TABLE 19. RTX System Clock Service Calls
------------------------------------------------------------------- Function Description Expect to Use------------------------------------------------------------------- NU_Read_Time() Read the current system clock value Yes NU_Set_Time() Set a new current system clock value Yes -------------------------------------------------------------------
Next Chapter