VxWorks / Tornado II FAQ

0. Introduction and Getting Started

0.1 Introduction

0.2 Books

0.3 Links

Index

From the original FAQ by Hwa Jin Bae:

VxWorks, made and sold by Wind River Systems of Alameda, CA, USA, is a real-time operating system. Similar real-time operating systems are available from other vendors: QNX, LynxOS, VRTX, pSOS, Windows-CE, Nucleus RTX, etc.

VxWorks requires a host workstation for program development. Unlike systems such as UNIX and QNX, VxWorks development is done on a "host" machine running UNIX or Windows, cross-compiling target software to run on various target CPU architectures.

It is a good idea to get a copy of VxWorks manuals before purchasing the system. WRS can provide you with such documentation. As far as I know there is no "VxBook" in the bookstores.

Brief History of VxWorks

Based on what I have heard from David Wilner and others, WRS was started by Jerry Fiddler and David Wilner in Jerry's garage as a contract/consultant shop for realtime, embedded systems and other fun things. Francis Coppola was one of the earlier customers.
They wrote a bunch of neat programs for their work and found that they liked them a great deal themselves, and added more excellent features to the system, eventually adding some things unheard of in embedded/realtime market in those days such TCP/IP networking. And continued to pioneer in this area by adding NFS, etc.
VxWorks was the name given the collection of software which ran on top of various realtime kernels including VRTX and pSOS as well an earlier slower version of WIND kernel. [ editorial: VxWorks no longer runs on other kernels; it now runs exclusively on its own WIND kernel since the 5.0 release, for which the WIND was rewritten by John Fogelin. ]
They got more people interested in the system and became successful. And moved from a little building in Emeryville to a larger one. And eventually to the present site in Alameda. And hired a lot of people.
WRS sold many many more copies of this system and continues to grow like a real successful company.
(From the original FAQ)

Q: What are differences between traditional UNIX and VxWorks?

They're both hacks. UNIX has a larger installed base. :-)
Seriously though, similarities end there, IMHO. VxWorks does have a lot of UNIX "compatible" routines in the user libraries. So porting a UNIX application is not that hard. But there are enough differences to make such a port take longer than normally expected.
VxWorks runs in one mode. No protected vs. user mode switching is done. Running in supervisor mode on most processors, and not using traps for system calls, VxWorks can achieve minimal overhead on a given piece of hardware than UNIX. Programming on VxWorks can be more tricky than UNIX for the same reason.
UNIX provides resource reclamation; by default, VxWorks does not. [ editorial: using deleteHooks or whatever, you could implement this on your own.] Instead programmers write what they need as needed. As a result, the context switch time in VxWorks is on the order of a few micro-seconds (since there is a lot smaller context to save and restore). VxWorks does not have full "process"; it only has tasks, or "threads", or light weight processes as some people like to call them.
Like any other multi-threaded environments (or MP environments), care should be taken when writing multi-tasking code. Each routine should be written carefully to be re-entrant (if it is going to be called from multiple contexts), semaphores are used a lot for this. And static variables are frowned upon. Sometimes, when porting a UNIX application, you may need to add "task variables" for this reason (as done for rpcLib in VxWorks).
VxWorks: minimal interrupt latency (e.g. spl's are quasi-implemented as semaphores). Traditional UNIX: high interrupt latency (e.g. spl's are implemented as interrupt lock and unlock calls).
VxWorks: priority interrupt-driven preemption, optional round-robin time-slicing. Traditional UNIX: prioritized round-robin preemptive time-slicing. Since VxWorks is just a glorified "program" it can be changed and customized pretty easily. Task scheduling can be customized as desired, for example.
VxWorks networking code, however, is very UNIX compatible [editorial: it is essentially "ported" version of BSD UNIX TCP/IP code -- tahoe release ]. It is relatively easy to port socket based code to VxWorks. [ editorial: except the not-so-compatible hostLib routines, etc.]
VxWorks most definitely is not a "realtime UNIX", or a varient of UNIX as often misunderstood by some people. The confusion perhaps is due to the fact that UNIX hosts are used most widely to develop applications for VxWorks (and VxWorks itself).
There are a lot more differences! In short, UNIX is a nice system to run emacs on. VxWorks is much better at playing pin-ball game machines.
Having said all this, I should also note that there are Realtime capable UNIX systems out there. Most of these systems do not come close to the capabilities and performance of VxWorks in realtime processing. An exception to this might be QNX, which is a very well designed Realtime POSIX operating system.
(From the original FAQ)

I know of one book about VxWorks and Tornado, next to the manual from WindRiver: "Tornado and VxWorks. What's not in the manual" by Christof Wehner. It is available through Amazon.de, Amazon.co.uk or Amazon.com Note: if you know of any other book about VxWorks, please let me know and I will add it to this page.

The best way to find out what books are available is to go to Amazon.com Books Home Page and search on Embedded (or search on Amazon.co.uk). This will give you al long list of books. Or use this link to the Barnes & Noble.com Home Page or Book Home Page and search for embedded.

Below is a selection of books from Amazon.com on embedded and real-time:

This is a selection of books from Amazon.co.uk on embedded and real-time:

Some links with information about VxWorks (see also part 9 of the FAQ for more links):

• The VxWorks Cookbook
• Embry-Riddle VxWorks 5.3(Tornado) Real-Time Laboratory Experiments
• Introduction into realtime systems
• Embedded Systems links
• RTOS information page

© J.A. Borkhuis, 2000 - 2005