Table of Contents Previous Chapter ACIS

6.0 Real-Time Executive Interfaces

6.1 Overview

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.

6.2 Executive Memory Map Requirements

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.

6.3 Task and Interrupt Control

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             

6.4 Event Management

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            

6.5 Semaphore Management

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            

6.6 Queue Management

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            

6.7 Memory Management

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            

6.8 System Clock Management

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            

Table of Contents Next Chapter