A cellular and mobile phone forum. CellBanter

Go Back   Home » CellBanter forum » General cell phone forums » Cellphone Technology
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Rex OS: Understanding behind performance



 
 
Thread Tools Display Modes
  #1  
Old June 12th 12, 04:29 PM posted to alt.cellular.tech
triste[_2_]
external usenet poster
 
Posts: 1
Default 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

GENERAL DESCRIPTION
This is the ARM Port of REX (Real Time Executive).
It is a simple, efficient real-time executive for the ARM7TDMI
processors.
It supports multi-tasking according to a priority scheduling
algorithm,
and provides a small set of services for task suspension and
reactivation.
All REX services follow the APCS conventions for function call/return
and
parameter passing.

TASKS

REX treats tasks as independently dispatchable entities, each having
its own stack, signal flags and priority which collectively
constitute
the context of the task. Each task has an associated data structure,
called the task context block (TCB), which REX uses for keeping track
of
the task's context. REX maintains a list of tasks in which all task
TCBs
are linked in order of decreasing task priority. The first TCB in
the
task list belongs to the highest priority task, while the last TCB
be-
longs to the lowest priority task (i.e., the kernel task whose
priority
is zero).

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
system.

TASK STACKS

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,
to
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
TCB,
the task's registers are popped off it's stack, and task execution
resumes where it left off. The process of task switching is
virtually
invisible to tasks.

TASK SIGNALS

Each task has associated with it 32 general purpose signal flags
which
are kept as part of the task's context in the task's TCB. These
signals
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
interrupt
handler.

A task can poll the current state of its signals at any time.
Moreover,
a task can also suspend its own execution pending the setting of one
or
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
handler
can wake up Task A by setting signal 1 for A. Once awakened, Task A
is
again eligible for execution, although it will actually run only if
it
is the highest priority task that is ready to run.

Notice that task signals are treated as a 32 bit wide mask. This
means
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
signals
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
setting,
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
interrupt
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.


TASK PRIORITIES AND SCHEDULING

Each task has associated with it a priority that is stored in its
TCB.
Priorities range from 1 to 2^32-1, with 1 being the lowest priority
and
2^32-1 being the highest. REX reserves priority value zero for use
with
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
sig-
nal(s). REX will continue to execute this task until it voluntarily
suspends, or until an interrupt occurs which reactivates a higher
pri-
ority task by setting signals for the task. In the case where all
user
defined tasks suspend, the kernel task, defined by REX, will
execute.

REX also provides a mechanism by which a task can raise or lower its
own priority dynamically.

================================================== =========================

INTERRUPTS

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.

================================================== =========================

TIMERS

Timer-related functions are now in rextime.c.

================================================== =========================

CRITICAL SECTIONS

Critical sections are used to provide mutual exclusion between
tasks,
while allowing other un-involved tasks to still be scheduled as
well
as allowing interrupts to happen. A critical section variable is
declared globally, and must be initialized via a function call
before
it can be used. Tasks can henceforth "enter" and "leave" the
critical
section.

If a task attempts to enter a critical section while it is being
held
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
appear
within the TCBs of the tasks themselves.

When a task releases a critical section, REX will select the
highest
priority waiting task to schedule.

================================================== ===========================

================================================== =========================

ASYNCHRONOUS PROCEDURE CALLS

Asynchronous Procedure Calls provide a means to postpone the
execution
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
time
the task is given CPU. APC's cannot be queued for the currently
running task.

================================================== ===========================

EXTERNALIZED FUNCTIONS
rex_init_crit_sect
Initilalzes a critical section, setting elements to 0, NULL, etc.

rex_enter_crit_sect
Acquires the lock on a critical section, or suspends the calling
task
until the critical section is available.

rex_leave_crit_sect
Releases the lock on a critical section and grants it to a waiting
task
(if there is one waiting).

rex_clr_sigs
Clears a specified mask of signals for a specified task.

rex_set_sigs
Sets a specified mask of signals for a specified task. If the
specified
task is waiting on any of the signals set, it will be again be
eligible
for execution.

rex_get_sigs
Returns the state of the signals for a specified task.

rex_wait
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
is
already set prior to calling rex_wait, an immediate return is made
from the function and the calling task continues to execute.

rex_def_task
Creates a new task using a specified TCB, stack, priority, entry
point
and task parameter. Task will start running only if it is the
highest
priority ready task.

rex_def_task_ext
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
in
"suspended" mode. If that option is chosen, the task will not
actually
run until a rex_resume_task() call is issued.

rex_suspend_task
Suspends a REX task.

rex_resume_task
Allows a suspended task to be scheduled.

rex_kill_task
Kill a task by yanking the TCB from the list of active tasks. If
the
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
from
the previous existence will still be around.

rex_self
Returns a pointer to the TCB of the calling task.
to obtain the address of its own TCB.

rex_set_pri
Changes the priority of the calling task to a specified priority.

rex_task_pri
Sets the priority of the task chosen to a determined value.

rex_get_pri
Returns the current priority of the calling task.

rex_init
Initializes REX and fires up a user startup task using a specified
TCB,
stack, priority, entry point and startup parameter.

rex_set_interrupt_vector
Given the id v of an installable vector and a pointer to the routine
to
be called when the interrupts occurs, this function installs the
routine.

rex_enable_interrupt
Enables the interrupt associated with id v.

TO BE CONTINUED

Contact me at: chochetgatoi at gmail.com




--
triste
Ads
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Understanding unlocking (traveling to England) Ken Cingular 10 August 23rd 11 11:00 AM
best nokia phone for networking rex [email protected] Nokia 0 November 12th 09 11:48 PM
N97 - Any comments from people who have used it? rex n900 [email protected] Nokia 0 November 12th 09 11:46 PM
Help understanding cashback terms [email protected] UK mobile telecoms 2 July 27th 05 09:34 PM
Understanding Debug Screen (AVX 9500) David L Cellular (general) 4 September 30th 03 12:02 AM


All times are GMT +1. The time now is 09:17 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2004-2018 CellBanter.
The comments are property of their posters.