RTOS & VxWorks Fundamentals

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 VxWorks UNIX (or protecting it with semaphores code reentrant to serialize Virtual MemoryIf time permits, reexamining how an application is execution). structured into tasks can make theNo. application modular and All VxWorksmore tasks share 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 other, and all processes are linked to run in the same address range.

any memory location, and any code that is downloaded will have a unique 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 than the total amount of physical memory. This is achieved by storing less frequently used pieces of memory in disadvantages of this a “swap partition or file” on a disk drive. The in a real-time system are (a) some external mass-storage 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 destroys Difference 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 Yes. When a process is created, it becomes a child of the process that created it

.No. All simultaneously executing code and data must fit into the physical memory of the system. This guarantees determinism. Object modules can still be loaded and unloaded dynamically, but their total size at any moment in time cannot exceed the total physical memory available

No. When a task is created, it becomes 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 u=target"

e=90.0.0.50

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 floppy

Image from the

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 u=target"

e=90.0.0.50

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 Interfaces

:

Including

Support

for

the

various

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