RTOS-RTXC

(1)

RTXC

Real Time eXecutive in C

--

a real time OS

(2)

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

(4)

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

(5)

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.

(6)

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

.

(7)

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.

(8)

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.

(9)

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.

(10)

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 passin

g

(11)

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.

(12)

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

(13)

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 .

•

(14)

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.

(15)

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.

• •

(16)

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

•

(17)

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

(18)

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.

•

(19)

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.

(20)

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

(21)

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.

(22)

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.

(23)

READY LIST

TCB TCB TCB Null task TCB current task D ecrea sin g ord er of prio rit y

READY

LIST

TCB parameters 1)Function entry point 2)stack base 3)stack size 4)priority

(24)

• 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

(25)

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.

(26)

•

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);

(27)

RTXC semaphores

• RTXC semaphores are the primary mechanism of synchronizing a task with an primary mechanism of synchronizing a task with an

event

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

(28)

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.

(29)

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.

(30)

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.

•

(31)

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.

(32)

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().

(33)

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.

(34)

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

(35)

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

(36)

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.

(37)

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.

(38)

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);

(39)

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()

(40)

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

(41)

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.

• •

(42)

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

(43)

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.

(44)

TIMER

• • typedef struct _clkblk { • struct _clkblk *flink; • struct _clkblk *blink;

• TICKS remain; ---delta time before timer expiration */ • TICKS recycle; --- cyclic amount if non-zero */

• TASK task; --- associated task no.

• char state; --- TIMER_DONE or TIMER_ACTIVE • OBJTYPE objtype; --- object type

• int objid; --- object id • } CLKBLK;

(45)

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.

• •

(46)

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.

(47)

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

(48)

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.

(49)

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.

(50)

Snapshot of tasks in Multivoip

(51)

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,

(52)

Snapshot of semaphores

(53)

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

(54)

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.

(55)

(56)

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,

(57)

Snapshot of resources

(58)

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’).

RTOS-RTXC

RTXC

RTXC

Real Time eXecutive in C

Real Time eXecutive in C

--

a real time OS

a real time OS

Contents

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

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

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

Event-Driven designs

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