Rex OS: Understanding behind performance
I will discuss here step by step about rex os via rex source code.
Part 1: Overview
R E X A R M P O R T
This is the ARM Port of REX (Real Time Executive).
It is a simple, efficient real-time executive for the ARM7TDMI
It supports multi-tasking according to a priority scheduling
and provides a small set of services for task suspension and
All REX services follow the APCS conventions for function call/return
REX treats tasks as independently dispatchable entities, each having
its own stack, signal flags and priority which collectively
the context of the task. Each task has an associated data structure,
called the task context block (TCB), which REX uses for keeping track
the task's context. REX maintains a list of tasks in which all task
are linked in order of decreasing task priority. The first TCB in
task list belongs to the highest priority task, while the last TCB
longs to the lowest priority task (i.e., the kernel task whose
REX allows an arbitrary number of tasks to be created dynamically at
any time during execution. Realistically, however, REX's performance
deteriorates slightly with each added task, so care is called for in
keeping the number of tasks to a minimum. Ultimately, the task load
which REX can support depends on the processor chosen, the processor
clock speed and the interrupt characteristics of the particular
As mentioned above, each task has its own stack which is used when-
ever the task is running. When the task is suspended (for example,
run another task or to service an interrupt), the task's registers
are pushed onto the task's stack, and then the top of stack pointer
is saved in the task's TCB. Later, when the task is selected for
running again, the top of stack pointer is restored from the task's
the task's registers are popped off it's stack, and task execution
resumes where it left off. The process of task switching is
invisible to tasks.
Each task has associated with it 32 general purpose signal flags
are kept as part of the task's context in the task's TCB. These
are used to notify the task that some kind of event has occurred. A
task's signals may be set or cleared by any task, and by any
A task can poll the current state of its signals at any time.
a task can also suspend its own execution pending the setting of one
more of its signals. So, for example, Task A may suspend waiting for
signal 1 to be set. At some later time, Task B or an interrupt
can wake up Task A by setting signal 1 for A. Once awakened, Task A
again eligible for execution, although it will actually run only if
is the highest priority task that is ready to run.
Notice that task signals are treated as a 32 bit wide mask. This
that all 32 signals for a task may be set or cleared in a single op-
eration and, similarly, a task may suspend on up to 32 different
at the same time, waking up when any one of them is set.
The important points to keep in mind about signals a
1. 32 signals are defined on a per task basis. For purposes of
clearing and waiting, signals are treated as 32 bit masks.
2. Signals are general purpose flags whose meanings may be defined
any way the user sees fit.
3. A task may optionally suspend execution pending the setting of
particular signal(s), presumably by another task or an
handler. The emphasis here should be on the word 'optionally'
since setting a signal for a task that is not suspended on the
signal does not directly affect the execution state of that
TASK PRIORITIES AND SCHEDULING
Each task has associated with it a priority that is stored in its
Priorities range from 1 to 2^32-1, with 1 being the lowest priority
2^32-1 being the highest. REX reserves priority value zero for use
the kernel task.
When scheduling, REX ALWAYS chooses the highest priority ready task,
i.e., the highest priority task that is not suspended waiting on
nal(s). REX will continue to execute this task until it voluntarily
suspends, or until an interrupt occurs which reactivates a higher
ority task by setting signals for the task. In the case where all
defined tasks suspend, the kernel task, defined by REX, will
REX also provides a mechanism by which a task can raise or lower its
own priority dynamically.
When an interrupt occurs, the corresponding interrupt handler must
immediately save the register context of the interrupted entity,
which may be a task or a lower priority interrupt.
Timer-related functions are now in rextime.c.
Critical sections are used to provide mutual exclusion between
while allowing other un-involved tasks to still be scheduled as
as allowing interrupts to happen. A critical section variable is
declared globally, and must be initialized via a function call
it can be used. Tasks can henceforth "enter" and "leave" the
If a task attempts to enter a critical section while it is being
by a different task, the attempting task will be blocked until the
critical section becomes available.
REX keep a list of waiting tasks attached to the critical section
variable. The list itself is constructed by linking pointers that
within the TCBs of the tasks themselves.
When a task releases a critical section, REX will select the
priority waiting task to schedule.
ASYNCHRONOUS PROCEDURE CALLS
Asynchronous Procedure Calls provide a means to postpone the
of a function until the REX is executing in the designated context.
Queueing an APC for a task causes the APC to be executed the next
the task is given CPU. APC's cannot be queued for the currently
Initilalzes a critical section, setting elements to 0, NULL, etc.
Acquires the lock on a critical section, or suspends the calling
until the critical section is available.
Releases the lock on a critical section and grants it to a waiting
(if there is one waiting).
Clears a specified mask of signals for a specified task.
Sets a specified mask of signals for a specified task. If the
task is waiting on any of the signals set, it will be again be
Returns the state of the signals for a specified task.
Suspends the calling task until at least one signal of a specified
signal mask is set for the task. If any signal of the signal mask
already set prior to calling rex_wait, an immediate return is made
from the function and the calling task continues to execute.
Creates a new task using a specified TCB, stack, priority, entry
and task parameter. Task will start running only if it is the
priority ready task.
An extended version of rex_def_task that adds two parameters to the
argument list. The first is a string for the task name, the second
is a boolean variable that indicates if the task should be started
"suspended" mode. If that option is chosen, the task will not
run until a rex_resume_task() call is issued.
Suspends a REX task.
Allows a suspended task to be scheduled.
Kill a task by yanking the TCB from the list of active tasks. If
same TCB is used in a future call to rex_def_task, the task will be
started from the beginning, in other words, no state information
the previous existence will still be around.
Returns a pointer to the TCB of the calling task.
to obtain the address of its own TCB.
Changes the priority of the calling task to a specified priority.
Sets the priority of the task chosen to a determined value.
Returns the current priority of the calling task.
Initializes REX and fires up a user startup task using a specified
stack, priority, entry point and startup parameter.
Given the id v of an installable vector and a pointer to the routine
be called when the interrupts occurs, this function installs the
Enables the interrupt associated with id v.
TO BE CONTINUED
Contact me at: chochetgatoi at gmail.com
|Thread||Thread Starter||Forum||Replies||Last Post|
|Understanding unlocking (traveling to England)||Ken||Cingular||10||August 23rd 11 12:00 PM|
|best nokia phone for networking rex||[email protected]||Nokia||0||November 13th 09 12:48 AM|
|N97 - Any comments from people who have used it? rex n900||[email protected]||Nokia||0||November 13th 09 12:46 AM|
|Help understanding cashback terms||[email protected]||UK mobile telecoms||2||July 27th 05 10:34 PM|
|Understanding Debug Screen (AVX 9500)||David L||Cellular (general)||4||September 30th 03 01:02 AM|