RTXC

Real Time eXecutive in C

-a real time OS

- By Vamshi Krishna D
 Contents
• What is RTOS
• Scheduling Methods
• Designs of RTOS -Event Driven & Time sharing
• Task & Its states.
• READY LIST
• Inter task communication and sharing
• RTXC Overview
• RTXC Features
• Rules of RTXC
• RTXC Tasks
• Semaphores
• Queues
• Resources
• Timers
• Interrupt service Routine
• Introduction to RTXCGen
• Introduction to RTXCBug
• Glossary of Terms
 What is RTOS
• A real-time operating system (RTOS) is a multitasking
operating system intended for real-time applications.
Such applications include embedded systems and scientific
research equipment .
• An RTOS provides facilities which, if used properly, guarantee

deadlines can be met generally (soft real-time) or

deterministically (hard real-time).
• Scheduling multiple tasks(jobs) to meet deadlines(wrt User)

is caller Real time .

• Key factors in an RTOS are therefore a minimal interrupt

latency and a minimal thread switching latency.

• The real key for designing RTOS is designing the
scheduler
 Scheduling Methods
• Scheduling methods
• An RTOS will typically use specialized scheduling algorithms in
order to provide the real-time developer with the tools necessary
to produce deterministic behavior in the final system.
• Two basic designs exist:

• Event-driven (priority scheduling) designs switch tasks only when

an event of higher priority needs service, called preemptive
priority.
• Time-sharing designs switch tasks on a clock interrupt, and on
events, called round robin.
• Newer RTOSes almost invariably implement time-sharing
scheduling with priority driven pre-emptive scheduling.
 Event-Driven designs
• Priority-based scheduling:
The static priority :A task is given a priority at the time it is
created, and it keeps this priority during the whole lifetime.
The scheduler is very simple, because it looks at all wait queues at
each priority level, and starts the task with the highest priority
to run.
Dynamic priority:The scheduler becomes more complex because
it has to calculate task’s priority on-line, based on dynamically
changing parameters.
Earliest-deadline-first (EDF) --- A task with a closer
deadline gets a higher scheduling priority.
Rate-monotonic scheduling :A task gets a higher priority
if it has to run more frequently.This is a common approach
in case that all tasks are periodic. So, a task that has to run
every n milliseconds gets a higher priority than a task
that runs every m milliseconds when n<m.
 Time sharing designs
• Time sharing Desing employs Round Robin scheduling or time
sliced scheduling . Here all the tasks are of same priority .
• Round Robin Scheduling:
Round robin is essentially a polling protocol
Round-robin is one of the simplest scheduling algorithms for
processes in an operating system, which assigns time slices to each
process in equal portions and in order, handling all processes
without priority.
Once the Round Robin task determines that it can progress no farther due to
the unavailability of some system element, it must yield control of the CPU
or become blocked.
● Time Slicing Scheduling:

• Time-Sliced task may only execute for some predefined quantum of

time. If the task remains in control of the CPU long enough for the
time quantum to expire, the RTOS has to force the task to yield
automatically .
 TASK STATES
A task is a fundamental program(light weight process) which does a
specific job .In typical designs, a task has three states: 1) running,
2) ready, 3) blocked.
In RTXC , Task can be in 5 states.

1) Running state :The task is in execution ,the task has control of all

of the system's resources.(provided the resource is not locked by

another task)
2) Ready state : In ready state,the task will be preempting the


executing task and is next to execute. i.e, ready to run.

• In RTXC ,If a task of higher priority than the Current Task becomes
Ready, it preempts the lower priority task and becomes the Current
Task.

3) Blocked state:prevents the task from executing.the Kernel
Service functions can block a task.A blocked task is removed from the
READY List.
 TASK STATES
• RTXC blockages occur for the following conditions:
• · INACTIVE - Inactive (Idle)
• · QUEUE_WAIT - Waiting on a queue condition (Queue_not_Full or
Queue_not_Empty) to occur
• · SEMAPHORE_WAIT - Waiting for a semaphore to be signaled
• · MSG_WAIT - Waiting to receive mail
• · BLOCK_WAIT - Blocked by RTXCbug
• RESOURCE_WAIT - Waiting for a resource to become available
• · DELAY_WAIT - Waiting for a delay period to expire
• · PARTITION_WAIT - Waiting for a memory partition to have a block
available
• · SUSPFLG – Suspended
• TERMINATION: In this state the task is killed , The proper way to
terminate execution of an RTXC task is through use of the KS_terminate()
Kernel Service.
 READY LIST
READY LIST:Its the key to multitasking .The data structure of the
ready list in the scheduler is designed to minimize the worst-case
length of time spent in the scheduler's critical section, during
which preemption is inhibited, and, in some cases, all interrupts
are disabled.
The Ready List should be sorted by priority, so that finding the

highest priority task to run does not require iterating through the
entire list.
Inserting a task then requires walking the ready list until reaching

either the end of the list, or a task of lower priority than that of the
task being inserted.
 Inter task communication and
sharing
Intertask communication and resource sharing:Multitasking
systems must manage sharing data and hardware resources among
multiple tasks. It is usually "unsafe" for two tasks to access the same
specific data or hardware resource simultaneously.
 There are three common approaches to resolve this problem:

 1) Temporarily masking/disabling interrupts

 2)Binary semaphores

 3)Message passing
 Inter task communication and
•
sharing
1)Masking Interrupts:On single-processor systems, if the
application runs in kernel mode and can mask interrupts, then the
current task has exclusive use of the CPU and thus can prevent
simultaneous access to a shared resource.No other task or interrupt
can take control, so the critical section is effectively protected.
When the task exits its critical section, it must unmask interrupts;
pending interrupts, if any, will then execute.
• disadvantages:interrupts if masked for long periods increases the

system's interrupt latency.

• Critical section:The parts of the code that access the shared

resource are called critical sections.The resources can be

memory ,memory variables, screen, modem etc.
• RTXC does not provide such Interrupt-
disable/enable functions.
•
 Inter task communication and
sharing
• 2)Semaphore:A binary semaphore is either locked or unlocked.
When it is locked, a queue of tasks can wait for the semaphore.
Typically a task can set a timeout on its wait for a semaphore.
• disadvantages:priority inversion and dead lock.

• In priority inversion, a high priority task waits because a low

priority task has a semaphore.

• In a deadlock, two or more tasks lock a number of binary

semaphores and then wait forever (no timeout) for other binary
semaphores, creating a cyclic dependency graph
 Inter task communication and
sharing
• Message passing: The other approach to resource sharing is for
tasks to send messages. In this paradigm, the resource is managed
directly by only one task; when another task wants to interrogate
or manipulate the resource, it sends a message to the managing
task.
• Can be done by FIFO QUEUES , MESSAGES(MailBox)

• disadvantages:priority inversion and dead lock .

•
 MEMORY ALLOCATIONS
• MEMORY ALLOCATION: Memory allocation is even more critical in
an RTOS than in other operating systems.Firstly, speed of
allocation is important. Next there should be minimum
Fragmentation as the RTOS is designed to work for years without
reboot .
• Different techniques are followed such as Memory Partitioning ,
having a Memory Management Unit etc to avoid memory
fragmentation.
 RTXC Overview
• RTXC is a Real-Time Operating System (RTOS).RTXC is designed
to support real-time, multitasking systems.
•
1)Employs a multitasking design in order to achieve
maximum CPU efficiency .
•
2) time-sharing scheduling with priority driven pre-emptive
scheduling
• 3)RTXC multitasking is driven in response to system events,
whether of internal or external origin.
• 4)support an application design composed of a set of separate
but interrelated tasks each having a priority indicative of its
relative scheduling importance.
• 5)Small ram requirement: RTXC requires small RAM
requirement for kernel operations.
•

•
 RTXC Features
• These features include:
• Multitasking with pre-emptive task scheduling
• Round Robin and Time-Sliced scheduling within same priority level
• Support for static and dynamically created tasks
• Fixed or dynamically changeable task priorities
• Intertask communication and synchronization via semaphores, messages,
and queues
• Efficient timer management
•
 RTXC features
• Timeouts on many services
• Management of memory
• Resource management
• Fast context switch
• Small RAM and ROM requirements
• Standard programmer interface on all processors
• Highly flexible configuration to permit custom fit to the application
 Rules of RTXC
• The Current Task (i.e., the task which is currently in control of the
CPU) is the highest priority task in the system which is not
otherwise blocked (yields, becomes blocked by unavailability of a
needed resource, or is preempted.).
• If a task of higher priority than the Current Task becomes
Ready, it preempts the lower priority task and becomes
the Current Task.
• The Null Task is always the lowest priority task and whose priority
must never be changed. It must always be Ready and MUST NEVER
be blocked.The Null Task must terminate the READY List.
• Any event used for task synchronization must be associated with

a semaphore.
• A semaphore can be associated with only one event at a time.

•
 Rules of RTXC
• A set of tasks using a Round Robin scheduling protocol and
Time-Sliced scheduling must have the same priority.
• A queue has a capacity (Depth) of a predefined number of
entries .Within a given queue, an entry has a predefined size
(Width).
• Any task can send mail to any mailbox.A task may own none, one,

or many mailboxes.Only one task should receive mail from a

given mailbox. A message added to a mailbox is inserted into the
mailbox's linked list according to the message's priority.
•
 Scheduling in RTXC
• Scheduling in RTXC :
•Multitasking with preemptive task scheduling :
• Round Robin and Time-Sliced scheduling within same priority
level:
• Preemptive Scheduling:
• Tasks of low priority may have their execution preempted by a
task of higher priority so that the latter can perform some time
critical function.
 Round Robin Scheduling:

 A set of tasks using a Round Robin scheduling protocol must have

the same priority.

 Once the Round Robin task determines that it can progress no farther due to
the unavailability of some system element, it must yield control of the CPU
or become blocked.
 If it becomes blocked, RTXC removes it from the READY List. If it yields, it
can yield control only to another task of the same priority.
 Scheduling in RTXC
 Time Slicing Scheduling:
• Time-Sliced task may only execute for some predefined quantum of time. If
the task remains in control of the CPU long enough for the time quantum to
expire, RTXC automatically forces the task to yield.
 RTXC Task objects
• TASK CONTROL BLOCK: Defines the Task attributes , entry point function for
the task , start address,size required for task execution ,priority etc.
• typedef struct _ktcb
• {
• void (*pc_t0)(void); --------- initial - entry point address
• STK_ALIGNTYPE *stackbase; -------------- initial - stack base */
• size_t stacksize; ------------- initial - stack size
• PRIORITY priority; ------------- initial - priority
• } KTCB;
•

• READY LIST: In RTXC,The READY List is actually a doubly linked list containing
those tasks which are runnable (Ready) in descending order of priority. Thus,
the Current Task is always the first task in the thread.
• This list is constantly being changed by various Kernel Services which insert
runnable tasks or remove those which are blocked and temporarily not able to
run.
 READY LIST
TCB parameters
TCB 1)Function
current entry point
READY task 2)stack base
LIST 3)stack size
4)priority

TCB

priority
of
order
Decreasing
TCB

TCB-task control block

TCB
Null task
• READY LIST is a double linked list , which maintains a list of TCB's in the order of priority and ended
by NULL task .
• typedef struct _tcb {
• struct _tcb *flink; ---------------- forward pointer flink MUST be first element in tcb
• struct _tcb *blink; ----------------------- backward link
• void (*pc_t0)(void); ---------------------initial - entry point address
• STK_ALIGNTYPE *stackbase; -------------- stack base address
• struct _clkblk *pclkblk; ----------------Timer
• struct _frame *sp; ---------------- current stack frame pointer
• TASK task; ---------stores the integer value corresponding to the task
• PRIORITY priority; ----------priority of the task
• TSTATE status; -----------stores the status ---wait , ready ,blocked
• size_t stacksize; ---------stores the stack size task execution
• #ifdef TIME_SLICE
• TICKS tslice; -------------- current time slice remaining
• TICKS newslice; -------------- reset value for time slice, 0 = no time slice
• #endif
• #ifdef HAS_INQTASK_ARG
• void *arg; ------------- argument "passed" to task on KS_inqarg
• #endif
• } TCB;
• the stack frame for a procedure contains all necessary information to save and
restore the state of a procedure
 RTXC tasks
• Before a task may execute, it must be defined to the system along with all of
its attributes. RTXC supports both static and dynamic tasks.
• Static tasks are those whose attributes are known before the system executes
and which remain fixed for the life of the configuration.
• Dynamic tasks are those whose TCBs are allocated and whose attributes are
defined as the result of some situation in the process which requires their
existence.
• STATIC TASKS: For static tasks , TCB allocation and task definition occur
through use of the system generation utility, RTXCgen.
• RTXCgen also permits the user to specify whether or not the task is to be
started automatically and to specify its position in the starting sequence.
• The starting sequence number is not related to the task's identifier number or
its priority.
• DYNAMIC TASKS: are created "on-the-fly"(dynamically) by another task, or
tasks, which also specifies via RTXC Kernel Services the task's attributes and
environment.
• DYNAMIC TASK Creation:
•
• Tasks are created using the
• following RTXC functions:
•
• - KS_alloc_task() --Tocreate a task control block
• Taskname = KS_alloc_task();

• - KS_deftask() to define the task's attributes.

• KS_deftask(taskname,priority,startaddress,stacksize,entry

point function)
• - KS_execute() to launch the task.
• KS_execute(taskname);
 RTXC semaphores
• RTXC semaphores are the primary mechanism of synchronizing a task with an
event.The basic use of semaphores is that of a "handshake" in which one task
waits for a signal and another provides the signal
• Each semaphore contains information about
the state of the associated event
the task trying to synchronize with the event.
• The system designer defines all semaphores via RTXCgen during the system
generation process.
• Semaphores are assigned names which equate to numbers.The semaphore
name or number is its identifier
• An RTXC semaphore contains a value representing one of the three possible
states
A PENDING state indicates that the event associated with the semaphore
has not yet occurred and is therefore pending.
The WAITING state shows that not only has the event not yet occurred,
but a task is waiting for it to happen.
The DONE state tells that the event has occurred.
• RTXC startup code initializes all semaphores to the PENDING state.
 Synchronization with semaphores
• semaphores are always associated with an event.
• For a task to synchronize with an event it must first wait for the event
to occur.
• To do this, the task waits on an RTXC semaphore using one of three Kernel
Services, KS_wait(), KS_waitm(), or KS_waitt().
• If a task attempts to wait on a semaphore in the PENDING state, the state of
the semaphore is changed to WAITING.
• The Current Task will be blocked with SEMAPHORE_WAIT and removed from
the READY List. Additionally, the task's execution is suspended until the event
occurs.
• If the Current Task attempts to wait on a semaphore which is in
the DONE state, the wait does not occur (since the desired event has
already happened), and the task is immediately resumed. RTXC automatically
changes the semaphore state back to PENDING.)
• An attempt to wait on a semaphore which is already in the
WAITING state can cause unpredictable results and should not be
attempted.
 Synchronization with semaphores
• EVENT SIGNALING :signaling a semaphore constitutes the second
action in the handshake. The occurrence of a specific event can
be indicated by signaling the semaphore associated with that
event.
• a signal may originate in either a task or in an interrupt service

routine.
• For tasks performing a signal, RTXC provides the Kernel

Services, KS_signal() and KS_signalm() for that purpose.

• e.g: print3 task Waits till discover is done by STUN before

initializing SIP ,clear channel etc.

• The function KS_ISRsignal() should be called to signal a

semaphore from the ISR while KS_ISRtick() provides RTXC

required processing for a clock tick.
 Synchronization with semaphores
•

• When signaling a semaphore in a PENDING state,the semaphore goes to

the DONE state.RTXC takes no further action.
• if the semaphore is in a WAITING state,the state of the semaphore
does not go to DONE but instead returns to PENDING.
• Next, the RTXC signaling function determines the identity of the
waiting task and unblocks it by removing the SEMAPHORE_WAIT
condition.
• Once the waiting task is unblocked, and found to be runnable, RTXC
inserts it into the READY List. If it is of higher priority than the
signaling task, it becomes the new Current Task. Thus,
synchronization of a task to an event can occur with a simple
semaphore .
• State Forcing: force the state of semaphore to PENDING state.
KS_pend() and KS_pendm() .
• Used when we are uncertain about the state of the semaphore.
•
 QUEUES
• Another technique whereby two tasks can communicate and synchronize is via
FIFO queues. Queues are usually used to handle such operations as character
stream input/output or other data buffering
• .e.g:queue for digits,waiting on a QUEUE of RTP packets queued
by DSP task.
• RTXC queues differ from messages in that the actual data rather than an
address is entered or removed from the queue. By definition, all RTXC queues
use a FIFO model .
• Each RTXC queue may be defined as having a single or multiple bytes per
entry.
• RTXC queues support a model allowing more than one task to put data into a
queue and more than one task to remove data from a queue
• The system designer defines all queues during the system generation process
using RTXCgen.
• An RTXC queue has two parts: the header and the body. Both parts of a queue
must reside in RAM. The queue header contains information needed by the
RTXC Kernel Services to move data into and out of the queues properly. The
queue body is simply an area of RAM which is organized as an array.
 QUEUES
• The size of the queue body is determined from the Width and Depth
definitions which are defined in queue header . Queue header should not be
changed by a task.
• Each queue must always exist in one of three possible states:
• Empty - There are no entries in the queue.
• not_Empty_not_Full - There is at least one but less than the maximum
number of entries in the queue.
• Full - All of the possible entries in the queue are used.
• RTXC initializes all queues to the Empty state during system startup.
• OPERATIONS ON QUEUE:RTXC queue operations fall into two basic categories:
putting data into queues, enqueueing, and getting data out of queues,
enqueueing.
• The basic Kernel Service for putting data into a queue is KS_enqueue() .
(moves data from a source location specified by the producer task, the
Current Task).
• The basic Kernel Service to get data from a queue, KS_dequeue(), and two
possible variants, KS_dequeuew(), and KS_dequeuet().
•
 QUEUE
• When the producer, the , attempts to put data into afull queue while using the
KS_enqueuew() Kernel Service, RTXC will block the task.
• And it removes from READY list,and make it wait until a consumer task
removes data from the queue thereby opening a slot to receive the new data.
• When the slot becomes open, the producer task is automatically returned to
the READY List and allowed to continue its operation.
• Thus, the synchronization between the producer and consumer is performed
without direct program intervention.
•
 QUEUES
• Producer and Consumer Task Synchronization :Whenever a task invokes a
queueing operation or is forced to wait, the task is inserted into a list of
waiter tasks associated with the particular queue.
• The order of insertion is by descending order of their respective priorities.
• There may be more than one task waiting to complete some activity on the
queue.
• As soon as the operation occurs which removes the condition on which the
waiter task is blocked, the highest priority task is taken from the list of
waiters, unblocked, made Ready, and inserted into the READY List
• In this manner,RTXC maintains synchronization between the producer and the
consumer tasks when they use queues .
• DATA MOVEMENT: RTXC supports two primary methods of moving data from
task to task: chronological and with respect to priority
• .For chronological data movement, the interface construct is a FIFO Queue.
For movements with respect to priority, RTXC provides for bi-directional
message transmission(MAIL BOX).
•
 RTXC QUEUE CREATION
• RTXC Queues headers must be created statically using
RTXCgen.exe.
• the RTXC Queues headers attributes are defined using
KS_defqueue():
• the queues width are set to the size of a pointer (to
the message).
• the queues depth are set to the number of messages.
• the queues bodies are allocated dynamically at queue
creation time.
 Mail Box
• A Mailbox is a construct which promotes the orderly accumulation of messages
from various senders.
• more than one task may send messages to a given mailbox, the mailbox should
be considered to be owned by a single receiver task.
• Messages are unlike queues in that the data in the messages is not moved
about. Instead, pointers to the data are passed. This makes for a very efficient
way to move about large volumes of data .
• Each message has a user-defined priority.
• A task may be both a message sender and a message receiver.
• A message may be sent synchronously or asynchronously.
• Once the message is linked into the specified mailbox, RTXC blocks the sender
by changing its state and removes it from the READY List.
• the next task in the READY List becomes the Current Task.The receiver
removes the message from the mailbox and processes it according to the
content of the message body.
• When the receiver no longer needs the data in the body of the message, it
acknowledges the message thereby making the sender task runnable again and
allowing it to continue its operation.
 Mail Box
• A task may need to receive mail from multiple mailboxes or need to
synchronize with other events as well as the arrival of mail.In such cases a
semaphore is required.
• The semaphore has an implicit association with the event occurring when a
message arrives at an empty mailbox.
• RTXC does not make an assignment of a semaphore to the mailbox but does
provide a Kernel Service, KS_defmboxsema(), for doing so.
• Mailbox usage is directly associated with the transmission of messages
between tasks.
•
 Using mail box with a semaphore
• Receiver side
• First we declare the semalist -a list of semaphores to wait upon.
• Then we define the semaphore for mailbox by KS_defmoxsema
• e.g.: KS_defmboxsema(MBOX1,MBX1SEMA); KS_defmboxsema(MBOX2,MBX2SEMA);
• We wait for the event to occur KS_waitm(semalist);
• We receive the message by
• msg = KS_receive(MBOX1, (TASK)0);
• ... process msg ...
• msg = KS_receive(MBOX2, (TASK)0);
• ... process msg ...
• We acknoledge that we received the message by KS_ack(msg)
•

• Sender side we can send message by KS_send()

• e.g: KS_send(MAILBOX3, &mymessage.msghdr,(PRIORITY)4, MSGSEMA);
• And we wait for acknoledgement by KS_wait(MSGSEMA);
•
 RESOURCES
• RTXC permits a task to gain exclusive access to some system component or
element. This is especially useful where it is necessary to guarantee that one
and only one user has control of an entity.
• Whenever a task wants to use a common entity with a guarantee of exclusive
access, it simply locks the resource. Locking the resource prevents other tasks
from gaining access to the entity while another task has access control.
• After locking the resource, the task may use the associated entity to whatever
extent is necessary to perform its functions.
• When the task has completed, its use of the entity, it reverses the process by
unlocking the resource. Unlocking the resource permits another task to gain
access control of the entity.
• RTXC provides a basic Kernel Service for each of these operations, KS_lock()
and KS_unlock() for locking and unlocking the resource.
 Resource Header
• typedef struct _rheader {
• TCB *owner; -------------current task ownership, 0=no owner
• int level; ----------- no. of nested locks
•

• #ifdef RESOURCE_WAITERS
• TCB *waiters; ----------- priority list of waiters, 0=no waiters
• TCB *dummy; ------------- reserved - must follow *waiters
• #ifdef PRIORITY_INVERSION
• PRIORITY priority; ----------- original owner's priority iff inversion
• RESATTR resattr; ----------- priority inversion option switch
• #endif
• #endif
• #ifdef CBUG -----------RTXCbug use
• unsigned int count; ------------- statistics - no. of locks performed
• unsigned int conflict; --------- statistics - no. resource conflicts
• #endif
• } RHEADER;
 MEMORY PARTITIONS
• RTXC supports a RAM memory management concept which features the use of
defined memory partitions to prevent fragmentation
• Memory partitions may be statically or dynamically defined according to the
needs of the application.
• Each memory partition, also called a Map, contains one or more blocks all of
which are the same size.
• Tasks allocate blocks of memory from various Maps as needed to perform their
assigned jobs.
• The attributes include:
· Memory Partition Identifier
· Block Size
Number of Blocks
· RAM Area Address
• When finished with a memory block, they release it by freeing it to the Map
from which it was allocated.
•

•
 MEMORY PARTITIONS
• Static Memory partitions:The system designer defines all static Memory
Partitions during system generation using RTXCgen .
• with RTXCgen, the user specifies the various attributes of each static Map
including its name, the number of blocks it is to contain, and its block size.
RTXCgen computes how much memory to allocate and produces the C
structures and memory arrays to accommodate the specification.
• RTXC does permit attribute redefinition for a static Memory Partition
through the use of the Kernel Service KS_defpart().
• Dynamic Memory partition:The number of dynamic Memory Partitions is
specified via RTXCgen,but the attributes and size are defined at run time.
• The task issues a KS_alloc_part() Kernel Service to allocate an unused
Map control block from the pool of free Map control blocks.
• The task defines the Map's attributes through the KS_defpart() Kernel
Service.
• Allocation of the dynamic Map control block and attribute definition can be
done by single Kernel Service request, KS_create_part().
• If a dynamic Memory Partition no longer has utility to the application, it
may be released by KS_free_part() Kernel Service
 TIMER
• Timer TICKS: The basic time unit used internally by RTXC is a TICK. A TICK
defines the amount of time between interrupts generated by the system clock
• RTXC uses two types of timers--General Timers and Timeout Timers.
• General Timers time system events such as the periodicity of a task's
cyclic operation or the operation of some mechanical device in the
physical process.
• eg: allocating a cyclic timer for processing HTTP connections
• A General timer has to be allocated and started by
• GTimer =KS_alloc_timer()
• KS_start_timer(GTimer, TICKS ,TICKS period, SEMA )
• Timeout Timers are a special type of timer used in limiting the duration
of certain Kernel Services in blocking the requesting task.
•

• General Timers are suitable for general purpose timing, including such uses as
timing events and establishing periodic task activation.
•
 TIMER
•

• typedef struct _clkblk {

• struct _clkblk *flink;
• struct _clkblk *blink;
• TICKS remain;
• TICKS recycle;
• TASK task;
• char state;
• OBJTYPE objtype;
• int objid;
• } CLKBLK;
•
-------------delta time before timer expiration */
------------ cyclic amount if non-zero */
--------------- associated task no.
------------- TIMER_DONE or TIMER_ACTIVE
-------------- object type
--------------- object id
 Interrupt Service Routine
• A program module which deals exclusively with servicing an exception to the
normal flow of processing caused by a particular event.
• In RTXC, there are three basic parts to all ISRs:
• · Prologue
• · Device servicing
• · Epilogue
• Prologue:The prologue begins the processing of the interrupt
• The purpose of the ISR prologue code is to save the processor context

plus any extended context necessary to preserve the

interrupted environment.
• Device Servicing:The device servicing section deals with the

particular device.
• After storing the context, the ISR prologue transfers control to the main function of
the ISR to service the interrupting device. This is usually a C function which performs
some device specific operation in order to clear the source of the interrupt request.
•

•
 Interrupt Service Routine
• RTXC provides two special services to deal with commonly encountered
requirements of interrupt processing. The function KS_ISRsignal() should be
called to signal a semaphore from the ISR while KS_ISRtick() provides RTXC
required processing for a clock tick.
• When its device specific operations are complete, the device servicing
function indicates that fact by calling the fourth special interrupt service
function, KS_ISRexit().
• Epilogue:The epilogue is the end action performed to finish interrupt
processing and continue with the application.
• It sole function is to restore the context of the highest priority Ready task and
grant it control of the CPU.
•
 Introduction to RTXCgen
• used for the generation of RTXC OS related tasks, and other various data
structures.
• Sysgen Utility:
• This utility is present under the multivoip->src->rtxcnet->bin directory and is
named as sysgen.exe. The sysgen utility requires a project file which will
define the tasks and the other datastructure. This project file is named as
'digivoip.rtx'.
•
 Operations on Task with RTXCgen
• There are multiple operations that can be done on the task. The task details
can be invoked by selecting View->tasks
•
●

● Creating a new task – This can be inserting a task in between or apending to

the existing list.
● Editing an existing task
● Deleting an existing task.
•
 Task parameters
• The parameters required for inserting a new task are as follows:
● Name – This signifies the name of the task that needs to be created. This
name will be used to represent a numerical value( using #define), which
will be used as the Task ID.
● Priority – This parameter indicates the priority of the task when executing.
● Entry – This parameter indicates the entry function that needs to be called
which represents the task, and executes as the task.
● Stack Size – This parameter indicates the stack size required by the task for
its execution.
● Starting Order – This parameter is not clear with respect to its functionality.
However, by default all tasks are created with Starting order as 1.
● Description – This parameter gives a brief description about the task, and its
functionality.
•
Snapshot of tasks in Multivoip
 RTXCgen Semaphore operations
• Operating on Semaphores:
• There are multiple operations that can be done on the semaphores. The
semaphore details can be invoked by selecting View->semaphores.
• Creating a new semaphore – This can be inserting a semaphore in between or
apending to the existing list.
● Editing an existing semaphore
●
Deleting an existing semaphore
●

● Inserting a new semaphore-The parameters required for inserting a new

semaphore are:
● Name – This parameter indicates the name of the Semaphore being created.
This name will be used to represent a numerical value( using #define),
which will be used as the Semaphore ID.
●
Description – This parameter gives a brief description about the Semaphore,
and its usage.
Snapshot of semaphores
 RTXCgen Queue operations
• Operating on Queues:
• There are multiple operations that can be done on the Queues. The Queue
details can be invoked by selecting View->Queues.
● Creating a queue – This can be inserting a queue in between or apending to
the existing list.
● Editing an existing queue
●
Deleting an existing queue
●

● INSERTING A NEW QUEUE

• A new queue can be inserted anywhere in between the existing queues or at
the end
 Queue parameters
• The parameters required for inserting a new queue are as follows:
● Name – This parameter indicates the name of the queue being created. This
name will be used to represent a numerical value( using #define), which
will be used as the Queue ID.
● Description – This parameter gives a brief description about the Queue, and
its usage.
● Depth – This parameter indicates the depth of the queue i.e. The maximum
number of elements in the queue.
● Width – This parameter indicates the size of each element in the queue.
 RTXCgen Resource operations
• Operating on Resources:
• There are multiple operations that can be done on the Resources. The
Resource details can be invoked by selecting View->Resources.
● Creating a resource – This can be inserting a resource in between or
apending to the existing list.
● Editing an existing resource
●
Deleting an existing resource
• The parameters required for inserting a new resource are:
● Name – This parameter indicates the name of the Resource being created.
This name will be used to represent a numerical value( using #define),
which will be used as the ResourceID.
● Description – This parameter gives a brief description about the Resource,
and its usage.
Snapshot of resources
 Introduction to RTXCbug
• RTXCBug:is the system level debugging tool for RTXC.
• Its purpose is to provide snapshots of RTXC internal data structures as well as
perform some limited task control.
• RTXCbug operates as a task and is usually set up as the highest priority task.
• This utility is used to get run-time statistics about the tasks, queues,
semaphores, resource, etc
• used for debugging the MultiVoIP firmware. This utility is part of the MultiVoIP
firmware and hence resides in the flash present in the MultiVoIP.
• .The RTXCBug utility can be invoked only after the VoIP has booted up, and is
in the running state. The utility is invoked through the Hyperterminal or any
other program, which interacts with the VoIP via the serial (COM) port. The
invoking key sequence for RTXCBug is ‘!’ (Shift key + ‘1’).
Snap shot of RTXCbug
 Glossary of Terms.
• Task:
The fundamental program element, usually represented as a C
function, in a system operating under RTXC. An application may be
composed of one or more tasks.
Task is equivalent to thread(lightweight process),A sequential program
in execution.It may communicate with other tasks.It may use system
resources.We may have timing constraints for tasks.
• They share global and static variables ,file descriptors,signal
bookkeeping ,code area and heap ,but they have their own program
counter registers & stack .
• Task Control Block(TCB): An RTXC kernel object containing
everything about a task needed to permit any supported multitasking
scheduling discipline.
• Kernel Object :A data structure or object used by the kernel for
purposes of task control, memory management, timer control,
exclusive access, or intertask communication and synchronization.
 Glossary of Terms.
• READY LIST: An RTXC Doubly Linked List which links the TCBs of
each task having no Blockage. The first entry in the list is the TCB of the
Current Task.
• CURRENT TASK :
• The task which is currently in control of the CPU and is, by definition,

the highest priority task in the READY List.

• TASK NUMBER: A number used to identify a Task Control Block
and, by implication, the task associated with that TCB.
• TASK PRIORITY: A number defining the relative importance of the
task with respect to all other tasks in the application. The higher the
priority, the more time-critical the task.
• WAITER: A task which is waiting on the availability of a kernel object,
RTXC data element, or an Event.
•
•
Glossary of Terms.
Inter task communication is done using semaphores,queues and
,messages.
•SEMAPHORE: An RTXC kernel object which is associated with an
Event and whose content yields information about the state of the event.
•QUEUE: An RTXC kernel object which operates as a FIFO buffer
for chronological processing of data.FIFO Queues are circular
buffers which hold data entries of one or more bytes.
•MESSAGE:Messages are unlike queues in that the data in the messages is
not moved about. Instead, pointers to the data are passed. This
makes for a very efficient way to move about large volumes of
data
• MAILBOX: A kernel object which serves as a repository for

messages sent by one or more tasks and intended for another

task or tasks.The interface between a message sender and the
receiver task is a Mailbox. A Mailbox is a construct which
promotes the orderly accumulation of messages from various
senders.
 Glossary of Terms
• CRITICAL REGION: A section of program within which the program
is vulnerable to undesirable interruption or corruption.
• KERNEL SERVICE: A function of the Kernel which performs a
particular operation affecting multitasking.
• SIGNAL: An action applied by a Kernel Service to a Semaphore to
indicate the occurrence of the associated Event.