›
 





|


 O


î What is a Real Time Operating System?
î Difference between RTOS & other common OS?
î Characteristics of a good RTOS?
î Hard RTOS.
î Soft RTOS.
î The Scheduler.
î Task & Task States.
î RTOS existing in market.
î Introduction to RTLinux.
î Writing RTLinux Modules.
î Soft & Hard Interrupts.
î Applications of RTLinux.
î Conclusion.

|


Whaaal 
a
 
î ›
 
Ñ The ability of OS to provide a required level of
service in a bounded response time.
î ›
Ñ Has a well defined, fixed time constraint.
Ñ Processing must be done within the define constraints or the
system will fail.
Ñ Real Time system is considered to function correctly only if it
returns the
correct result within any time constraint.
Ñ Real Time system is one in which correctness of computations not
only
depends on logical correctness of the computation but also upon
the time at
which the result is produced.
Ñ If timing constraints of the system are not met , system failure is
said to have
occurred.

|


Whah



h
 

î Most RTOS are actually different from desktop operating systems such as
windows & Unix.
î Firstly, other operating systems takes control as soon as system is turned on
and lets you start your applications.Also compilation & linking of application is
done separately from operating system.
Whereas in case of RTO, at boot time, your application usually gets control first
and then it starts the RTOS. So here we link the RTOS with our application.
î Secondly, many RTOS do not protect themselves as carefully from application as
do other desktop operating systems.
î Finally, RTOS typically includes just the services that you need for your
embedded system and no more.This feature of RTOS enables it to save memory

|


 Ohaa a 


î

  Ñ One special consideration if you use an RTOS is that each
task needs memory space for its stack. Therefore you should ensure that your
system allocates only as much stack memory as is needed.So the method for
determining how much stack space a task needs is to examine your code.Each
function call , function parameter and local variable takes up certain number of
bytes on the stack.Then you must add space for the worst case I.e nesting of
interrupt routines and some space for RTOS itself.
î   
 Ñ For every system call, the maximum time it takes
should be predictable & independent of number of objects in the system.
î
     Ñ A good RTOS should have a good documentation,
should be delivered with good tools to develop and tune your application.
So a RTOS supporting many devices will have more advantageous than a simple
very good nano - Kernel.

|


 ëa


î Hard RTOS guarantees critical task will complete in a given amount of time.For
this all delays in the system must be bounded.
î If a process completes correctly but takes longer than given amount of time, the
process fails.
î The Scheduler plays an important role in Hard RTOS.
î The Scheduler either admits the process, guaranteeing that the process will
complete on time, or it rejects the request if it is impossible.

|


 

î Soft RTOS are less restrictive than Hard RTOS.
î In Soft RTOS critical tasks are given priority over non critical tasks.
î Here also, like Hard RTOS, delays need to be bounded so that critical task do not wait
for ever, but these are not as severe as in Hard RTOS.
î In this if a process completes correctly, but takes longer than its given amount of
time, the result may still be useful.
î Like in Hard RTOS, Scheduler plays an important role in Soft RTOS also.
î Important aspects of implementing Soft RTOS are Ñ
 The system must have priority scheduling and the real time process must have
highest priority.

 The dispatch latency must be small.The smaller the latency, the faster the real
time process can start executing once it is runnable.

|


hhl

î The Scheduler keeps the track of state of each task and decides which one
should go into running state.
î It looks at the priorities you assign to the tasks and among the tasks that are
not in block state, the one with the highest priority runs and the rest of them
waits in the ready state.The lower priority tasks just have to wait.
î How does the scheduler know when a task has to become Blocked or
Unblocked?
The RTOS provides a collection of functions that tasks can call to tell the
scheduler, what events they want to wait for and to signal those events, which
have happened.
î What happens if all the tasks are blocked ?
If all the tasks are blocked then the Scheduler will spin in some tight loop inside
of the RTOS, waiting for something to happen.
î What if two tasks of same priority are ready?
It depends on the RTOS that you use. Many systems solve this problem by
making it illegal to have same tasks of same priority. Some RTOS have
employed the concept of time slicing between two tasks.

|


aaa
î The basic building blocks of software written under an RTOS is the task.Each task in
an RTOS is always in one of the three states Ñ

. Running Ñ Which means that the microprocessor is executing the instruction that
make up this task. Unless yours is a multiprocessor system, there will be only one
task, which will be in running state at any given time.

. Ready Ñ Which means that this task is ready for execution but since some other
task is undergoing execution presently, this task is waiting for its turn.Any number of
tasks can be in this state.

|. Blocked Ñ Which means that this task hasn¶t got anything to do right now, even if
the microprocessor becomes available. Tasks get into this state because they are
waiting for some external event to happen.Any number of tasks can be in this state
as well.

|


 


a

î Wind River Systems¶ VxWorks.

î Integrated Systems¶ pSOS.
î QNX Systems¶ QNX.
î FSM Labs RTLinux.
î Kodak¶s AMX.
î Microtec¶s VRTX.
î Microware¶s OS .
î Accelerated Technology¶s Nucleus.

|


›
  

î A system is said to be ›
 if it is
required to complete it¶s work & deliver
it¶s services on time.
î Example ± Car Driver
All tasks in that system must execute on time.

|


‰
  
 
î Œ

 Reaching the destination safely.

î O 
  Car.

î  
   Road conditions and other

cars.

î O
 
 

 Sensors - Eyes and Ears of the driver.

|


‰
  
 
î O Accelerator, Steering wheel, Break-pedal.

î £
 Wheels, Engines, and Brakes

î O

 Steering and breaking.

î A

 Turning on radio.

î - 
 is not an absolute one. It measures the

goodness of the outcome relative to the best outcome
possible under a given circumstance.

|


‰
  
 
î O of fulfilling the mission ù Efficient solution.

î › 
 of the driver ù Fault-tolerance is a

must

|


ë

 
›
  

î Hard Real Time System
Failure to meet deadlines is fatal
example Ñ Flight Control System
î Soft Real Time System
Late completion of jobs is undesirable but not fatal.
System performance degrades as more & more jobs
miss deadlines
Online Databases

|


 
 

î A 
   is a system with
performance deadlines on computations and
actions; that is, system correctness depends
on the timeliness of results.
î An     is a system that exists
within a larger system.
î A r is a unit of work that is scheduled and
executed by the system (Ji,k .
î A 
 is a set of related jobs that provide
some system function IJi = { Ji,, Ji,
, ... , Ji,n }.

|


u


î Ô
a
V

 

 j 












j 
j
  
 j


 
j  





j 
j

 


|


 u



 



î 

 j

j  j
j 

j j
 

j  






î 



 j

j 
j



î 
2

2

j 



î 
jj







j   
j




j






|



 
î The  
  (or

  of a job is
the time at which the job becomes available for
execution ( ri or Ri .
î The    of a job is the length of time
between the release time of the job and the time
instant when it   .
î The  
 
 of a job is the maximum
allowable response time of a job ( Di .

|



 
î The
 
 of a job is the
time at which a job must be completed (
di = ri + Di .

|


  
î A    assigns jobs to processors.
î A   is an assignment of all jobs in the
system on available processors (produced by
scheduler.
î The   (or   of a job is
the amount of time required to complete the
execution of a job once it has been scheduled (
ei or Ci .

|


[
   
î A valid schedule is a 
   if
every job meets its timing constraints; e.g.,
completes execution by its deadline.
î A set of jobs is  
 according to a
scheduling algorithm if (when using the
algorithm (the scheduler always produces a
feasible schedule.
î The 
   of a job is the difference
between its completion time and its deadline.
If the job completes early, its lateness will be
negative

|


- 


î A periodic task IJi = { Ji,, Ji,
, ... , Ji,n } is a sequence

of jobs with identical parameters withÑ
a   ( pi or Ti  equal to the minimum length of
time between the release times of consecutive jobs,
an   ( ei or Ci  equal to the
maximum execution time of any job in the task, and
a 
 ( iji  equal to the release time of the first
job in IJi.

|


› 
 ›
  

î Standalone Applications
Micro controller based Embedded Systems
î Some Real Time Applications are huge
& complex
Multiple threads
Complicated Synchronization Requirements
File system Network Windowing support

|


[

 › 
î Scheduling.

î Resource Allocation.

î Interrupt Handling.

î Other issues like kernel size.

|


  ›
î More information about the tasks are known
No of tasks
Resource Requirements
Release Time
Execution time
Deadlines
î Being a more deterministic system better
scheduling algorithms can be devised.

|


   
›
î Clock Driven Scheduling

î Weighted Round Robin Scheduling

î Priority Scheduling

|


   
› x

î Clock Driven
All parameters about jobs (release time
execution time deadline known in advance.
Schedule can be computed offline or at some
regular time instances.
Minimal runtime overhead.
Not suitable for many applications.

|


   
› x
Î
î Weighted Round Robin
Jobs scheduled in FIFO manner
Time quantum given to jobs is proportional to
it¶s weight
Not suitable for precedence constrained jobs.
î Job A can run only after Job B. No point in giving
time quantum to Job B before Job A.

|


   
› x
Î
î Priority Scheduling
Processor never left idle when there are ready
tasks
Processor allocated to processes according to
priorities
Priorities
î static - at design time
î Dynamic - at runtime

|


-  
  
î Earliest Deadline First (EDF
Process with earliest deadline given highest priority
î Least Slack Time First (LSF
slack = relative deadline ± execution left
î Rate Monotonic Scheduling (RMS
For periodic tasks
Tasks priority inversely proportional to it¶s period

|


›   

›
î Resource Allocation
The issues with scheduling applicable here.
Resources can be allocated in
î Weighted Round Robin
î Priority Based
î Some resources are non preemptible
Example Ñ semaphores
î Priority Inversion if priority scheduling is used

|


-  
 -  
Priority inversion is an undesirable situation in
which a higher priority task gets blocked
(waits for CPU for more time than that it is
supposed to, by lower priority tasks.
ExampleÑ
î Let Ô , Ô
, and Ô be the three periodic tasks
with decreasing order of priorities.
î Let Ô and Ô share a resource ³S´.

|


-  
  ‰

î T| obtains a lock on the semaphore i and
enters its critical section to use a shared
resource.

î T becomes ready to run and preempts T|.

Then, T tries to enter its critical section by
first trying to lock i. But, i is already locked
by T| and hence T is blocked.

î T
becomes ready to run. Since only T
and

T| are ready to run, T
preempts T| while T|
is in its critical section.

|


-  
  ‰

Ideally, one would prefer that the highest priority
task (T be blocked no longer than the time for
T| to complete its critical section. However, the
duration of blocking is, in fact, unpredictable
because task T
got executed in between.

|


 

-  
 
î Priority Inheritance
The thread holding a resource inherits the
priority of the thread blocked on that resource

|


-  
 

 - 

- 
    
 

Under this protocol, if a higher priority task Të is blocked by

a lower priority task Ôu, because Ôu is currently executing
critical section needed by Ôë, Ôu temporarily inherits the
priority of Ôë.
When blocking ceases (i.e., Ôu exits the critical section, Ôu
resumes its original priority.
Unfortunately, priority inheritance may lead to deadlock.

|



 ›  
î Interrupt Latency should be very small
Kernel has to respond to real time events
Interrupts should be disabled for minimum possible
time
î For embedded applications Kernel Size should be
small
Should fit in ROM
î Sophisticated features can be removed
No Virtual Memory

|


u  ›
 


î Scheduling
Priority Driven Approach
î Optimize average case response time
Interactive Processes Given Highest Priority
î Aim to reduce response times of processes
Real Time Processes
î Processes with high priority
î No notion of deadlines
î Resource Allocation
No support for handling priority inversion

|



 -   
u
î Processes are non preemptible in Kernel
Mode
System calls like fork take a lot of time
High priority thread might wait for a low
priority thread to complete it¶s system call
î Processes are heavy weight
Context switch takes several hundred
microseconds

|


›u
î Real Time Kernel at the lowest level
î Linux Kernel is a low priority thread
Executed only when no real time tasks
î Interrupts trapped by the Real Time
Kernel and passed onto Linux Kernel
Software emulation to hardware interrupts
î Interrupts are queued by RTLinux

|


›u x
Î
î Real Time Tasks
î Non Real Time Tasks are developed in
Linux
î Communication
Queues
Shared memory

|


 ›u   


î RT Linux uses VM concept limited to

interrupt emulation.
î It slips a small, simple, RT OS
underneath Linux.
î Linux becomes an idle task for this OS

|


|


 ›u [
  

|


›u !  

""Î
î A layer of emulation software between
Linux kernel and interrupt controller
hardware.
î Prevents disabling of interrupts by Linux

|


›u ! 

î Initial Design ± Each RT task executed
in its own address space.
î High overhead of context switching as
TLB had to be invalidated.
î High overhead of system calls.
î Now all RT tasks run in the same
address space (in the kernel space
and at the highest privilege level.

|


›u ! 

"Î
î RT tasks run as kernel modules. Can be
dynamically added.
î Tasks have integer context for faster context
switching (unless FP context is explicitly
requested.
î Hardware context switching provided by x8 is
not used.
î Task resources should be statically allocated
(kmalloc etc. should not be used within an RT
task.

|


›u !  
î RT Linux is module based ± the scheduler
is itself a loadable kernel module.
î Default ± A simple preemptive priority
based scheduler where the tasks are
statically assigned priorities. The highest
priority task ready to run is scheduled.

|


›u !  
"Î
î Alternate scheduling policies
Earliest Deadline First (EDF ± A dynamic
priority scheduler in which the task with the
nearest deadline is scheduled.
Rate Monotonic (RM ± A static priority
scheduler for periodic tasks where the task
with the smallest period is assigned the
highest priority. This is provably the optimal
policy.

|



-  

-Î
î Linux kernel may be preempted by an
RT task even during a system call, so
no Linux routine can be safely called
from real-time tasks.
î RT fifos used for communication
between RT tasks and Linux user
processes.
î RT fifo buffers are allocated in kernel
address space.

|



 › x

î VxWorks
Monolithic Architecture
Real Time Posix compliant
î pSOS
Object Oriented OS

|


 
 
 

î Developed by FSMLabs Inc. in  in New Mexico.
î It is a Hard RTOS that co-exists with Linux OS.
î With RTLinux it is possible to create Real Time POSIX.b Threads that will run
at precisely specified moments of time.
î WARNING Ñ Real Time programs in RTLinux are executed in Kernel space and
have little or no protection against bugs in user¶s code. Special care must be
taken when programming real time tasks because programming errors may
bring the system down.
î For this RTLinux supplies a debugger within its source tree under the directory



. So use of 


is strongly recommended to reduce the risk of to
reduce the risk of system crashes.
î For those who are primarily interested in hard real time control and not
particularly interested in learning how to use RTLinux itself,can take a look at
FSM Labs RTiC-Lab at www.rtic-lab.org . RTiC-Lab is a front end to RTLinux that
greatly simplifies hard real time control implementation, monitoring and tuning.
î For those who are interested in running RTLinux on an industry standard PC-
board or other type of minimal or embedded system,can refer to FSMLabs
MiniRTL project , found www.rtlinux.org minirtl.html. MiniRTL fits on a single
floppy disk and provides full RTLinux capabilities.

|


 

l

|


 

l

|


 W

 l
î D 

›-
 Ñ In RTLinux, programs are modelled as
modules which are loaded into the Linux kernel space. A Linux module is nothing but
an object file, usually created with the -c flag argument to gcc. The module itself is
created by compiling an ordinary C language file in which the main ( function is
replaced by a pair of init cleanup functionsÑ
int init_module(;
void cleanup_module(;
î init_module( function is called when the module is first loaded into the kernel. It
should return  on success and returns negative value on failure.
î cleanup_module( is called when module is unloaded.
î For example ÑIf we assume that a user has created a C file named my mo-dule.
c, the code can be converted into a module by typing the followingÑ

!"£
#$ 
This command creates a module file named my module.o, which can now be
inserted into the kernel. To insert the module into the kernel, we use the
insmod command. To remove it, the rmmod command is used.

|


 h a!"
î A real time application is usually composed of several ³threads´ of execution. Threads
are light-weight processes which share a common address space. Conceptually, Linux
kernel control threads are also RTLinux threads (with one for each CPU in the system.
In RTLinux, all threads share the Linux kernel address space.
î To create a new real time thread, we use the pthread create(| function. This function
must only be called from the Linux kernel thread (i.e., using init module(Ñ
$ %
&

$
 '
$(
)

$
$(
)
('(
$ *'(*)
(
*+
î The thread is created using the attributes specified in the ³attr´ thread attributes object.
If attr is NULL, default attributes are used. The ID of the newly created thread is stored
in the location pointed to by ³thread´. The function pointed to by start routine is taken
to be the thread code. It is passed the ³arg´ argument. To cancel a thread, use the
POSIX functionÑ


 '

*+

|


  #al
î RTLinux provides several clocks that can be used for timing functionality, such as as
referencing for thread scheduling and obtaining timestamps.
î Here is the general timing APIÑ
$ %$ &
$  '$$)  (*+
 $$  '$*+
  

 $$ +,( (,

$ +,(
 (,
#+
î To obtain the current clock reading,we use the clock_gettime(| function where clock_id
is the clock to be read and ts is a structure which stores the value obtained.
î The hrtime_t value is expressed as a single -bit number of nanoseconds. Thus,
clock_gethrtime(| is the same as clock_gettime, but returns the time as an hrtime_t
rather than as a timespec structure.

|


 hl
ha
î RTLinux provides scheduling, which allows thread code to run at specific times.
î RTLinux uses a pure priority-driven scheduler, in which the highest priority (ready
thread is always chosen to run.
î RTLinux uses the following scheduling APIÑ

$  

'
$
)
)
 $

(

*+

$
 $ $'
$
)
  (*+

$-
$'*+
 $ $$
'*+
 $ $$'*+
  

  $ 
+,(  (,

  $
 +,(  
(,
#+

|


 ! l" a 


î This program will execute two times per second, and during each iteration it will print
the messageÑ
.  )
/
î Program for hello.c Ñ
#include <rtl.h>
#include <time.h>
#include <pthread.h>
pthread_t thread;
void * start_routine(void *arg
{
struct sched_param p;
p . sched_priority = ;
pthread_setschedparam (pthread_self(, SCHED_FIFO, &p;
pthread_make_periodic_np (pthread_self(, gethrtime(,
;
while (
{
pthread_wait_np(;
rtl_printf("I¶m here; my arg is %x\n", (unsigned
arg;
}
return ;

|


 ! l" a 

$
%
}
int init_module(void
{
return pthread_create (&thread, NULL, start_routine, ;
}
void cleanup_module(void
{
pthread_cancel (thread;
pthread_join (thread, NULL;
}

|


 O
 
   
î In order to execute our program, we must first do the followingÑ
. Compile the source code and create a module. We can normally accomplish this by
using the Linux GCC compiler directly from the command line. To simplify things,
however, we¶ll create a Makefile. Then we¶ll only need to type ³make´ to compile our
code.

. Locate and copy the rtl.mk file. The rtl.mk file is an include file which contains all the
ags needed to compile our code. For simplicity, we¶ll copy it from the RTLinux source
tree and place it alongside of our hello.c file.
|. Insert the module into the running RTLinux kernel. The resulting object binary must
be ³plugged in´ to the kernel, where it will be executed by RTLinux.
î We begin by creating the Makefile that will be used to compile our hello.c program.
Type the following into a file called Makefile and put it in the same directory as your
hello.c programÑ
  
0'O"£
* 
î Now, type the followingÑ

  
This compiles the hello.c program and produces an object file named hello.o.

|


 O
 
  
 O  
î We now need to load the RTLinux modules.

 
î óou can check the status of your modules by typing the commandÑ

 
î For more information about the usage of the rtlinux commandÑ
 
î óou should now be able to see your hello.o program printing its message twice per
second.
î To stop the program, we need to remove it from the kernel. To do so, typeÑ
 

|


  !
ëa

î There are two types of interrupts in RTLinuxÑ Soft and Hard.
î
 Ñ
. Soft interrupts are normal Linux kernel interrupts.

. They have the advantage that some Linux kernel functions can be called from
them safely.
|. However, for many tasks they do not provide hard real time performance; they
may be delayed for considerable periods of time.
î ë
 Ñ
. Hard interrupts (or real time interrupts, on the other hand, have much lower
latency.

. However, just as with real time threads, only a very limited set of kernel
functions may be called from the hard interrupt handlers.

|


 !la
 

î!
 

Ô







  

 


Ô
 
Ô






 

Ô

 


  !

"#
$ 


 
Ô

 


%

 

|


 £
 
 
££  

& 

Ô


'



()
* 

'


& 

Ô

 





 
)



Ô
"#
+% 
Ô


" 
+
,



-++$* 

Ô

%





|


 £
 
 
 

Ô
 

#





Ô
 

.
/





 


  
+)

Ô
0+ 
Ô


/
0+Ô/
Ô

 


 
#

)

Ô
12!

Ô



0
 0
.13!

Ô




Ô



)
4
)
5%
#

Ô
#
 




 
%'

"6
5 +




|


 £
 
 

 

Ô
( 0
  


Ô
 
 
 %



/% 
#


,  ')#)


Ô


#
% 
#




|


 £
 
 

  

6!
#
Ô
 
) 

#
/ 


 



"#

Ô


/
%
 

#


7 

Ô


 #

#


  

#


|


 £
 
 

 

Ô
Ô)"#


+

"#

4

Ô

%  %



Ô



#
/'






*'+  

*'%

Ô


%
89 
%/05+ 

Ô

 
5Ô%

% 



 


Ô
0 % 
Ô

:%
%
|


 £
 
 

  

"
Ô
;3
!
&Ô) )

 
 

 

 

Ô
! 


% 

"#
,

Ô
 

%


Ô% "%


<
 
Ô
 








|


 £
 
 
£ 

Ô

 


  


%
#%
#

|


 £
 
 
    

4
 

Ô



) %


Ô
  
! 


 '
 

-

Ô
 

Ô

 
/%



 


Ô


  

'
 ( 

Ô

  


|

 

 £
 
 
 

Ô
"
#


0

Ô



.
 
#


Ô

%



 


"#
 
 %

|


 £
 
 
!" 

,Ô
 
Ô

 


#



Ô
"#
& 


Ô

  


% 


|


 O
l

î RT Linux has achieved hard real-time performance by making minimal changes to a

freely available Operating System.
î Provides an alternative to proprietary real-time systems which may be prohibitively
expensive.
î As Linux develops, RT Linux will also ride the wave of its development.
î Unlike other RT systems, no separate support for RT Linux is needed since support for
Linux is already widely available.

|


|


|