What exactly is meant by real-time?

"A real-time system is one in which the correctness of the

computations not only depends upon the logical correctness of the
computation but also upon the time at which the result is produced. If
the timing constraints of the system are not met, system failure is said
to have occurred."

"Hence, it is essential that the timing constraints of the system are

guaranteed to be met. Guaranteeing timing behavior requires that the
system be predictable. It is also desirable that the system attain a high
degree of utilization while satisfying the timing constraints of the
system."

A good example is a robot that has to pick up something from a

conveyor belt. The piece is moving, and the robot has a small window
to pick up the object. If the robot is late, the piece won't be there
anymore, and thus the job will have been done incorrectly, even
though the robot went to the right place. If the robot is early, the piece
won't be there yet, and the robot may block it.

Another example is the servo loops in an airplane when on auto-pilot.

The sensors of the plane must continuously supply the control
computer with proper measurements. If a measurement is missed, the
performance of the airplane can degrade, sometimes to unacceptable
levels.

In the robot example, it would be hard real time if the robot arriving
late causes completely incorrect operation. It would be soft real time if
the robot arriving late meant a loss of throughput. Much of what is
done in real time programming is actually soft real time system. Good
system design often implies a level of safe/correct behavior even if the
computer system never completes the computation. So if the computer
is only a little late, the system effects may be somewhat mitigated.

1
What makes an OS a RTOS?

1. A RTOS (Real-Time Operating System) has to be multi-threaded and

preemptible.
2. The notion of thread priority has to exist as there is for the moment
no deadline driven OS.
3. The OS has to support predictable thread synchronisation
mechanisms
4. A system of priority inheritance has to exist
5. OS Behaviour should be known

So the following figures should be clearly given by the RTOS

manufacturer:

1. the interrupt latency (i.e. time from interrupt to task run) :

this has to be compatible with application requirements and has to
be predictable. This value depends on the number of simultaneous
pending interrupts.

2. for every system call, the maximum time it takes. It should be

predictable and independent from the number of objects in the
system;

3. the maximum time the OS and drivers mask the interrupts.

The following points should also be known by the developer:

1. System Interrupt Levels.
2. Device driver IRQ Levels, maximum time they take, etc.

2
Difference Between UNIX and VxWorks

1.Differences in scheduling algorithms:

Both UNIX and VxWorks use preemptive, priority-based schedulers.

This means that if a higher priority process than the one that is
currently executing becomes ready to run, then it will immediately
take over from the other process. The main difference between the
OSs is in how the priority gets set.

In UNIX, the scheduling algorithm is designed to be “fair” to all users of

the CPU. The assumption here is that there are multiple people using a
single computer, and each of them deserves a fair share of the CPU. It
is also assumed that these users are competitive rather than
cooperative, and will use as much CPU time as is given to them. The
implementation can get quite complex as the scheduler tries to ensure
that all users get a share of the CPU, and that interactive processes
(editors, for example) get good response time. The mechanism that
the UNIX scheduler uses is to dynamically change the priority of
processes. The longer a task has had to wait to run, the higher its
priority becomes until eventually it is the highest priority runnable
process, and gets to run for a period of time.

VxWorks uses a different set of assumptions about tasks, which leads

to a different scheduler algorithm. VxWorks does not assume that all
tasks “deserve” a share of the CPU. Rather, it assumes that the
implementer of the system understands the relative importance of the
running tasks, and can set their priorities accordingly. In a real-time
system, some tasks will be more time critical than others, and must
run within a certain time-frame regardless of how long a low-priority
task has been waiting. These assumptions lead to a much simpler
scheduling algorithm: In VxWorks, each task has an 8-bit priority (the
lower the number, the higher the priority) that is specified when the
task is created and can be modified at any time thereafter. This priority
is not changed by VxWorks, and is used to determine which task shall
run at any moment. In addition, VxWorks supports “round-robin”
scheduling, which allows the CPU to be shared equally between several
tasks of the same priority. Compared to the uncertainty of the complex
UNIX scheduler, this simple, fixed-priority scheduling algorithm makes
it much easier for the system implementer to understand how multiple

3
tasks will interact. Understanding the interaction between tasks is
important in understanding the behavior of a real-time application.
WindView, which visually displays task interaction while an application
is running, is an invaluable tool in understanding task scheduling.

2.Reentrancy and global variable naming :

Because VxWorks uses a single address space model, all tasks access
a common set of global variables. This means that if taskA uses a
global variable named x, that variable is identical to the global variable
x used by taskB. This is in contrast to UNIX, where each process lives
in its own virtual memory space, and does not need to know what
global variables other processes use. There are two primary
consequences of this:

1. All code that declares global variables must ensure that the variable
names do not conflict with those declared by other pieces of
code. It is easy to spot when conflicts occur because the linker will
complain about multiple declarations of the same variable.
2. If a function is to be called by multiple tasks, then it must
be written to be reentrant (i.e., it should not use global variables
to maintain state), or it must be “single threaded” by protecting
it with mutual exclusion semaphores to ensure that only one task
executes it simultaneously.

When porting code from UNIX to VxWorks , the most common way of
complying with both these issues is to gather all the global variables
used by a program into a structure definition, and then to modify the
code to access these variables through a pointer to a structure. Each
time the code is called, this structure can be created as a stack
variable, or “malloc” so that each instance of the code has its own
copy of the variables it uses.

3.Reclaiming resources :

In UNIX, when a process terminates, all the resources that it was using
(e.g., memory that was malloc’d or files that were opened) are
automatically reclaimed by the kernel. This is possible because a
process’s virtual memory space can simply be deleted, freeing up any
memory that it was using, and because the kernel keeps track of which
process is using which resources. If the count of the number of
processes using a particular file reaches 0, the file is automatically
closed.

In VxWorks, resource reclamation is not performed automatically; the

lack of a virtual memory environment and the overhead of keeping

4
track of users of a resource would result in a performance overhead
that would likely be unacceptable to many users. Because of this, the
responsibility of resource reclamation is given to the application itself.
This means that when a task exits, it is responsible for freeing up any
memory that it allocated, and deleting any other resources that it
created (file descriptors and semaphores, for example). A VxWorks
facility called “task delete hooks” is sometimes useful when
implementing resource reclamation, and is documented in taskHookLib
in the VxWorks Programmers Manual. In practice, this chore is often
not as onerous as might initially appear, because a large number of
real-time applications consist of a number of tasks that are created at
system initialization, and then do not exit until the system is rebooted.
For this type of task, no reclamation is necessary.

4.Implementing a specification :

If you are a UNIX programmer, there may be certain habits and

assumptions that you have about implementing a system. As you will
have discovered from reading this article, the VxWorks operating
system provides most of the libraries you are used to using, in addition
to some new tools that make communicating between tasks easier.
There is one important philosophical difference, though, that may not
have come across in the previous discussion: compared to UNIX,
VxWorks tasks are fast and incur low overhead.

Many UNIX programmers assume that all processes are complex and
hard to manage. If an application can be implemented within one
thread of execution, then that is how it will be done, regardless of how
well it fits the problem. This may be a valid approach when writing for
UNIX, since processes are indeed complex, hard to manage, hard to
communicate between, and slow to switch execution between.

VxWorks tasks are easy to manage:

In VxWorks, however, tasks are easy to manage, use little additional

memory, are easy to communicate between, and fast to switch
execution between. These features can lead to a much more natural
implementation of many event-driven, real-time applications. If a
specification breaks down into many simultaneous tasks, then it can be
implemented as multiple tasks. Doing this also allows flow control and
buffering to be easily implemented by making use of semaphores and
message queues between tasks. Applications implemented this way
tend to be more modular and easier to test and modify, and tools such
as WindView can be used to easily capture and analyze the interaction
between tasks.

5
It is important to note, however, that while tasks may incur low
overhead, they are not completely free. Switching between tasks
takes a few microseconds (Wind River publishes benchmark data
sheets for various processor families), and a small amount of memory
is allocated whenever a task is created, so there may still be some
tradeoffs to make when deciding on the number of tasks to use in
implementing your application.

Conclusion :

VxWorks contains most of the libraries that UNIX programmers expect

to find. The majority of the work required is likely to involve making
UNIX (or protecting it with semaphores VxWorks
code reentrant to serialize
Virtual MemoryIf time permits, reexamining how an application is
execution).
structured into tasks can make theNo. application
All VxWorksmore modular
tasks share and
the same
Yes. Each process lives in its own
easier to maintain and enhance. address space. All processes can write to
memory space. Processes cannot
directly affect the operation of each any memory location, and any code that
other, and all processes are linked to is downloaded will have a unique
run in the same address range. address range associated with it. Note:
An optional product, VxVMI,™ provides
code protection and private, per-task
memory areas.
Paging environment

Yes. The total space taken by each

virtual memory space can be greater .No. All simultaneously executing code
than the total amount of physical and data must fit into the physical
memory. This is achieved by storing memory of the system. This guarantees
less frequently used pieces of determinism. Object modules can still be
memory in disadvantages of this a loaded and unloaded dynamically, but
“swap partition or file” on a disk their total size at any moment in time
drive. The in a real-time system are cannot exceed the total physical memory
(a) some external mass-storage available
media are required in each system,
and (b) there is no guarantee that a
particular section of code exists in
memory when it comes time to
execute it.inThis
Difference destroys
Process Modelany
determinism in the environment, so
some “real-time” UNIX environments
have mechanisms to allow certain
processes to be “locked” into
physical memory.

Parent/child relationship No. When a task is created, it becomes

Yes. When a process is created, it
becomes a child of the process that
created it
an autonomous entity, although it can be
controlled (e.g., changing its priority) by
any task
6

Task creation Single-stage process in which a task calls

VxWorks Tools Capabilities

With the VxWorks tools, you can build applications that satisfy real time requirements.
The VxWorks software consists of development software and run-time software.

The development software runs on a host computer, using the DIGITAL

UNIX operating system. The development software includes:

• System configuration utilities

• VxGDB - a remote, source-code debugger

• VxSim - a prototyping and test-bed environment

• Performance evaluation tools

• Text editors

• C language compiler

• Assemblers

• Linkers

The run-time software runs on a target computer and consists of:

• A real-time operating system kernel

• Synchronization utilities

• IPC (message passing) utilities

• I/O system

• Debugging and profiling facilities

• A remote login tool

• A module loader

• Network utilities (sockets, rlogin, RPC, ARP, BOOTP, SLIP, NFS,

etc.)

• File service utilities

7
• VxWorks shell

Some of the major features of VxWorks

In Version 5.1:

- wind kernel unlimited tasks

- 256 priorities
- binary, counting mutex semaphores
- message q's
- POSIX pipes
- sockets
- shared memory
- profiling utilities
- ethernet support (i596, LANCE, NIC, SONIC)
- SLIP (no PPP yet)
- backplane driver for network
- rlogin (server & client)
- telnet (server only)
- rpc (no rpcgen)
- nfs (client)
- ftp (server & client)
- tftp (client & server)
- rsh
- bootp
- proxyarp
- C-interpreter shell (incomplete but useful)
- symbolic debugging
- disassembly
- performmance monitoring tools
- exception handling
- signal handling (not quite UNIX compatible)
- dynamic object image loader
- system symbol table
- system info utilities
- libraries of 600+ utility routines
- remote source level debugger(VxGDB)
- SCSI support
- DOS & RT11 & Raw filesystems.
- "full ANSI"
- "POSIX I/O"

8
What kind of products have been developed using VxWorks?

- Flight simulators
- Radio and optical telescopes
- Automative ABS & realtime suspension
- Naviation systems
- Deep sea instrumentation
- PBXs
- Traffic control systems
- Modems
- Sonar systems
- Comm/weather satellite test equipment
- X terminals
- PostScript laser printers
- Video Editing, Audio Visual systems
- robotics
- NFS protocol accelerator product
- mass storage tape robot systems

9
Case Studies

The following Case Studies have been carried out in VxWorks

1. Booting the target over the Network
2. Booting the target with the Floppy
3. Initializing the following interfaces
• Network Interface
• Floppy Drive Interface
• HardDrive Interface

4. Task Creation and Scheduling

5. Semaphore Implementation
6. Stream Sockets
7. Datagram Sockets
8. Multicasting
9. Broadcasting
10. FTP
11. Timer
12. Network File System
13. Select Implementation

10
Case Study 1 : Booting over the network

Case Study : Booting and Downloading VxWorks Image from Host :

“157.227.2.45” to target “157.227.2.101” which is a Pentium III
processor and a Ethernet Card of “Intel Ether Express PRO100B PC “

This Case Study includes two steps one for booting and other for
downloading the vxWorks image.

Building the boot image

1.In this first of all make changes in the config.h file of the specific
processor, as in our case study we are using P-III so we have to
make changes in pcPentium’s config file.
• Make changes in the default bootline of Pentium which look like

#elif (CPU_VARIANT == PENTIUM)

#define DEFAULT_BOOT_LINE \
"fd=0,0(0,0)host:/fd0/vxWorks.st h=90.0.0.3 e=90.0.0.50
u=target"

We will change this to

“ fei(0,0) nokia_n7: /vxWorks h=157.227.2.45 e=157.227.2.101
u=anonymous “

Bootline parameters are:

fei(0,0) the interface card which needs to be attached

nokia_n7 is hostname of our system
h stands for host IP
e stands for target IP
u stands for user name required for ftp server running on host. This is
given as “anonymous”
and the ftp password as anything, but should not be left blank.

2. Make sure that the corresponding Ethernet card is defined in the

config.h file, ie Define the corresponding Ethernet card in that
config file, in our case we define FEI card and undef the rest.

define FEI card and undef the rest

#define INCLUDE_FEI

11
Now to build the Boot Floppy :
Select the corresponding BSP (Board Support Package ) PcPentium in
this case and the type of image as Bootrom_uncmp

Now put the bootrom image in the boot sector of the floppy using
mkboot command which would in our case
mkboot a: bootrom_uncmp

After Booting the target will give a prompt like “[vxWorks Boot]: “

Use “help” command to view other command

Use “p” command to print the Default Boot Parameters

[vxWorks boot]: p
boot device : fei
unit no. :0
processor no: 0
host name : nokia_n7
file name : \vxWorks
inet on ethernet(e) : 157.227.2.101
host inet (h) : 157.227.2.45
user : anonymous
ftp password : anything

Now for downloading vxWorks image :

Before downloading vxWorks image FTP server must be running on

your host and set the path of home directory to the one which contains
custom configured VxWorks image .

Type “@” at the prompt to continue the downloading procedure.

For creating bootable VxWorks image :

1. Create a bootable project.

2. Choose the corresponding BSP , pcPentium in this case.
3. Include the components you require like the corresponding
driver (fei in this case) ,built-in symbol table and the shell startup

12
 4. Build the project which will give you custom configured bootable
image.
5. Include this image while booting the target.

-------------------------------------------

Case Study 2 : Booting with the Floppy

Case Study : Booting and Downloading VxWorks Image from the

floppy

For making the Boot image :

1. In this first of all make changes in the config.h file of the specific
processor, as in our case study we are using P-III so we have to
make changes in pcPentium’s config file.
• Make changes in the default bootline of Pentium which look like

#elif (CPU_VARIANT == PENTIUM)

#define DEFAULT_BOOT_LINE \
"fd=0,0(0,0)host:/fd0/vxWorks.st h=90.0.0.3 e=90.0.0.50
u=target"

Bootline parameters are:

fd(0,0) :- the floppy

/fd0/vxWorks :- the path of the downloadable image
The rest of the parameters are not required

• Make sure that the corresponding Ethernet card is defined in the

config file, ie Define the corresponding Ethernet card in that config
file, in our case we define FEI card and undef the rest.

define FEI card and undef the rest

#define INCLUDE_FEI

The Boot Floppy and the VxWorks image can be made in the similar
manner.

13
Case Study 3 : Including Support for the various
Interfaces

How To Include Network Support While Booting From The

Floppy Disc

Initial requirement :- You must boot your target with the floppy disc
with the support for your network card included.

After this you have to run the following commands on the target(our
target has ‘fei’ Intel Fast Express network card):
1. ipAttach(0,”fei”) ------ For including the TCP/IP support

2.ifMaskSet(“fei0”,0xffffff00) -------- For setting the network mask

3.ifAddrSet(“fei0”,”157.227.2.22”) --------- For setting the IP address

With these steps your network card is initialised.

How to include Floppy Drive Support

Initial requirement :- None

Run the following commands at the Shell

1. fdDrv(176 , 6)
Where, second parameter is the Interrupt Level for the Floppy drive
(found from the Resources Tab in Windows NT Diagnostics)
And first parameter is the interrupt Vector, calculated as :- 224-
(8*interrupt level)

2. usrFdConfig(0,0,”/fd0”)

How to include Hard Drive Support

Initial requirement :- None

Run the following commands at the Shell

1. ataDrv(0,0,112,14,1,10,10)
Where, fourth parameter is the Interrupt Level for the hard
drive(found from the Resources Tab in Windows NT Diagnostics)
And third parameter is the interrupt Vector, calculated as :- 224-
(8*interrupt level)

2. usrAtaConfig(0,0,”/devs0”)

14
Case Study 4 to 13 :

Please refer to the Case Study Folder on Bm_34a

15