FAQ/monthly posting
Peaceful Star
This FAQ is also available via anonymous ftp in:
netcom.com:~ftp/pub/hjb/vxfaq
============================================================================
ITEM: table of contents
What is VxWorks?
Brief History of VxWorks
What are some of the major features of VxWorks?
What are the Latest versions of VxWorks?
Where is the archive site for user-contributed code?
What application notes are available from Wind River?
How can I join the VxWorks user's group?
Is comp.os.vxworks also available via a mailing list?
Can I use gcc or g++ with VxWorks?
Other C/C++ Compiler tools for VxWorks?
Which cross-debuggers can I use with VxWorks?
What are differences between UNIX and VxWorks?
What are the performance/benchmark numbers for WIND kernel?
What are the performance/benchmark numbers for VxWorks TCP/IP?
What is the VxSim VxWorks Simulator?
Can I use one boot EPROM for multiple boards on the same net?
What's the deal with 68881 FPU code in interrupt handlers?
X for VxWorks
IEEE-488 (GPIB) driver for VxWorks
How does one disable NFS client caching?
How does one get better network I/O performance?
How does one troubleshoot a backplane driver malfunction?
How do I add select support to my driver?
What third party products are available for VxWorks?
What kind of products have been developed using VxWorks?
A complete list of CPU hardware supported by VxWorks
A complete list of peripheral devices supported by VxWorks
What's with these unbundled "accessories"?
How come my 5.0.2 BSP isn't available in 5.1, damn it?
How much is VxWorks?
What is MicroWorks?
Other Unbundled Products for VxWorks?
How can I find out more about VxWorks?
What other net.resources are available on real-time systems?
Contributions to comp.os.vxworks FAQs.
-------------------------------------------------------------------------
ITEM: What is VxWorks?
VxWorks, from Wind River Systems, is a networked real-time operating
system designed to be used in a distributed environment. It runs on a
wide variety of hardware, including MC680x0, MC683xx, Intel i960, Intel
i386, R3000, SPARC, Fujitsu SPARClite, and TRON Gmicro, based systems.
It requires a host workstation for program development; supported host
platforms include Sun3, Sun4, HP9000, IBM RS-6000, DEC, SGI, and MIPS.
It does not run development systems software such as compiler, linker
and editor on the target machine. The development environment is based
on cross-development or remote-development method. You will need a
UNIX machine of some sort (e.g. SUN's) to run the compilers and
debuggers. The compiled application code can be downloaded to the
target and runs as part of the VxWorks image. During the development
phase or thereafter, individual object code (.o files) can be
downloaded dynamically to running target system. Finished applications
can be ROM'ed or whatever.
----------------------------
ITEM: 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 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. [ 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. And recently went public.
-----------------------------
ITEM: What are 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"
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.
----------------------------
ITEM: What are the Latest versions of VxWorks?
As as of June 1993,
5.0.3.: TRON will be discontinued.
5.0.3 : i386
5.0.5 : r3000
5.1 : 680x0, 683xx, i960, SPARC
i386 and r3000 will be upgraded to 5.1.
------------------------------
ITEM: Where is the archive site for user-contributed code?
The VxWorks archive system is available for FTP as thor.atd.ucar.edu.
It is also accessible via email server at vxworks...@ncar.ucar.edu.
Questions should be directed to its maintainer, Richard Neitzel
<th...@thor.ucar.edu>.
To get more detailed infomation send email to:
The message body must read:
send index
send index from vx
send index from unix
A summary of the archives is periodically posted to comp.os.vxworks.
Some of the usual titles available:
ansi, ansilib, benchmarks, bitcnt, c++builtin, c++headers, camaclib, cbench
cntsem_class, crc, deadman, dhrystones, dirlib, dt1451, fcompress
flags_class, force, gcc+68040, getdate, hkv30extintutil, ivecalloc, joblib2
lclflag, libX11, loadmeter, math, monitor, msgque_class, ntpvx, ping, pipe
poolLib, ring, semCnt, ss1, stevie, string, syslog, task_class, taskmon, tod
tp41, ty335, veclist, vtape, vwcurses, vx_cplusplus, vxrsh, wdog_class, shar
vxtool, vxview, xc
------------------------------
ITEM: What application notes are available from Wind River?
List of Wind Technical Notes
Motorola MV147 Slave Base Control 9-1
System hang during lkup( ) output 10-1
Reserving Memory 11-1
Serial IO Vanishing 13-1
NFS: problems with writing files 14-1
Which interrupts does VxWorks use? 15-1
Debugging ftp problems 18-1
Interrupt handlers, floating point 19-1
Booting From a Memory Board 22-1
Changing Network Interfaces 23-1
Writing Non-buffered Sockets 24-1
RPC and VxWorks 25-1
Using SCSI devices with VxWorks 5.x 26-1
The Select Facility in VxWorks 28-1
Using on-board Serial Ports 29-1
Problems with ls() 30-1
SCSI 31-1
Trouble Shooting Booting Problems 32-1
-----------------------------
ITEM: How can I join the VxWorks user's group?
For User Group info contact WRS.
Or contact Eric Rabinowitz of Panoramic Systems at:
er...@wrs.com or er...@spacelabs.com
phone: 206-860-7836.
------------------------------
ITEM: Is comp.os.vxworks also available via a mailing list?
Lawrence Berkeley Labs maintains an automated mailing list which is
bi-directionally gatewayed to comp.os.vxworks
It is called the 'VxWorks Exploder'.
Mail to vxwe...@lbl.gov is automatically mailed to a number
of sites, including Wind River.
Send subscription request to vxwexplo...@lbl.gov.
------------------------------
ITEM: Can I use gcc or g++ with VxWorks?
WRS's gcc GNU Toolkit distribution can be reshipped in its entirety.
WRS charges are for media and support, so obviously copies thereof
don't matter to them.
Lots of customers use g++ as provided by the "net" --
see the VxWorks Archive information below.
You can get a generic freely distributable GCC/G++ and compile your
code for VxWorks. Or you can just get a copy from someone who has a
working GCC cross-development setup from WRS.
WRS worked with Cygnus to polish up their release of GCC but a generic
GCC distribution works just fine as well.
For MC68K targets:
You can also use native SunOS 4.X cc running on Sun-3's.
You can also use various other free m68k C compilers
such as lcc, sozobon, etc. provided that you're willing
to hack on them.
---------------------------------------
ITEM: Other C/C++ Compiler tools for VxWorks?
WRS re-sells (re-engineered?) CenterLine cfront product and WindC++
Gateway for CenterLine Object Center. They come with browsers, etc.
Not free.
------------------------------
ITEM: Which cross-debuggers can I use with VxWorks?
GDB & other more expensive tools from WRS, MicroTec Research, etc.
WRS sells a lightly modified version of xxgdb which has a lousy GUI
interface. In 5.1 xvxgdb may have been slightly improved -- but the
ObjectCenter C++ with VxWorks solution provides better GUI interface.
With a little bit of hacking, regular GDB works just fine. Personally,
I find GUI to a debugger gets in the way of real work. I use GNU Emacs
GDB interface which works well and can be easily customized.
There might be some old VxWorks customers that also use VxWorks-aware
dbxtool on Sun machines. This used to be maintained and sold by SUN
Consulting.
If you're only interested in debugging your "application" on VxWorks,
the vxgdb approach (using RPC) works just fine.
If you are rather more interested in the guts of the system as well as
your application you might want to spend some time building
cross-debugging tools from generic GDB distribution into VxWorks.
------------------------------------
ITEM: What are differences between UNIX and VxWorks?
They're both a hack. 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 initially planned for.
For one thing, UNIX definitely is not realtime, whatever that means. [
To me personally, what realtime means is this -- when there is a
spinning process or task running like crazy doing some stuff busily, I
still want my system to respond immediately when I type a character on
my console keyboard. VxWorks, and other real realtime OS'es, do this.
UNIX and MS-DOG don't. ]
VxWorks in its original form does not have any memory protection
support. It 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. [
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 SMP 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 implemented as semaphores).
UNIX: ridiculous interrupt latency (e.g. spl's are implemented as interrupt
lock and unlock calls!).
VxWorks: priority preemption, round-robin time-slicing.
Traditional UNIX: prioritized round-robin 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. Most people prefer priority based preemption in
the realtime world. UNIX prefers fair-share time-slicing.
VxWorks networking code, however, is very UNIX compatible. It is
relatively easy to port socket based code to VxWorks. [except the 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 is used most widely to develop applications for
VxWorks (and VxWorks itself). [ Need I say, Realtime UNIX is like
MILITARY INTELLIGENCE. ]
There are a lot more differences! In short, UNIX is a nice system to
run emacs on. VxWorks is much better at controlling pin-ball game
machines.
----------------------------
ITEM: What are the performance/benchmark numbers for WIND kernel?
A WRS VxWorks 5.1 Benchmark Report hot off the press:
Benchmark numbers based on: mv167-25Mhz, 5.1
Cache Cache
Key Measurements Enabled Disabled
Raw Context Switch Time 4 us 14 us
Cyclic Test Time 172 us 638 us
Suspend/Switch/Resume/Switch 23 us 86 us
Kernel Timings
Task Related
taskSpawn 124 us 370 us
taskInit 58 us 181 us
taskActivate 12 us 33 us
taskDelete 101 us 303 us
Task Create / Delete 249 us 684 us
taskLock
CASE 1: no lock 3 us 4 us
CASE 2: lock exists 2 us 5 us
taskUnlock
CASE 1: no lock 2 us 12 us
CASE 2: lock exists 5 us 6 us
taskSuspend
CASE 1: ready task 11 us 30 us
CASE 2: pended task 9 us 19 us
CASE 3: suspended task 8 us 19 us
CASE 4: delayed task 9 us 19 us
taskResume
CASE 1: ready task 6 us 19 us
CASE 2: pended task 10 us 19 us
CASE 3: suspended task 13 us 30 us
CASE 4: delayed task 9 us 18 us
Semaphore Related
semBCreate 66 us 152 us
semCCreate 46 us 150 us
semMCreate 45 us 139 us
semDelete
Binary 49 us 157 us
Counting 49 us 163 us
Mutual Exclusion 48 us 157 us
semGive
CASE 1: tasks in queue
Binary 18 us 44 us
Counting 20 us 46 us
Mutual Exclusion 25 us 59 us
CASE 2: no tasks in queue
Binary 4 us 8 us
Counting 5 us 11 us
Mutual Exclusion 6 us 15 us
Cache Cache
Enabled Disabled
semTake
CASE 1: semaphore available
Binary 4 us 9 us
Counting 5 us 11 us
Mutual Exclusion 5 us 13 us
CASE 2: semaphore unavailable
Binary 10 us 25 us
Counting 11 us 27 us
Mutual Exclusion 4 us 12 us
Semaphore Give / Take
Binary 7 us 15 us
Counting 9 us 21 us
Mutual Exclusion 10 us 26 us
semFlush
Binary 11 us 20 us
Counting 11 us 20 us
Mutual Exclusion 10 us 16 us
Miscellaneous Operating System Timings
Message Queue Related
msgQCreate 93 us 280 us
msgQDelete 71 us 229 us
msgQSend
CASE 1: task pending 39 us 102 us
CASE 2: no tasks pending 23 us 64 us
CASE 3: queue full 14 us 45 us
msgQReceive
CASE 1: message available 20 us 62 us
CASE 2: message unavailable 15 us 41 us
Memory Related
malloc 28 us 81 us
free 32 us 104 us
Watchdog Related
wdCreate 42 us 106 us
wdDelete
CASE 1: timer started 48 us 160 us
CASE 2: timer not started 44 us 150 us
wdStart
CASE 1: timer in queue 20 us 70 us
CASE 2: no timer in queue 18 us 55 us
wdCancel 11 us 34 us
Floating-Point
robot application 18 sec 51 sec
If you're anal enough to count pico-seconds in comparing realtime
kernels, you might want to actually get each of the evaluation copies
from various vendors and test them yourself. But remember benchmarks
are misleading and almost always biased and inaccurate. Given similar
benchmark numbers, give or take a few microseconds, etc., your dollars
are better spent in getting something you'll enjoy using.
-----------------------------
ITEM: What are the performance/benchmark numbers for VxWorks TCP/IP?
According to WRS, using VxWorks 5.1 on mv167-25mhz (i82596 ethernet)
w/ cache w/o cache enabled
TCP/IP Throughput (KB/sec) 859 KB/sec 682 KB/sec
No numbers available on latency.
Using a reasonably fast processor 25Mhz MC68040 and a reasonably well
made ethernet chip like SONIC or LANCE put together on a reasonable board
design will achieve TCP throughput close to full bandwidth of ethernet.
This, of course, is not saying much these days, since a 16Mhz MC68020
with onboard LANCE or a PeeCee with an ethernet board can do the same.
I know at least one implementation based on el-cheapo i486-50mhz/EISA/SONIC
that does: 1170KB/sec.
---------------------------------
ITEM: What is the VxSim VxWorks Simulator?
Propaganda from WRS:
It really is VxWorks running under UNIX! So sure it
is not realtime, although all tasks and resources interact
in the same way -- great for prototyping "high-level" code.
Using the simulator saves wear and tear on h/w. It (only)
allows sytem level debugging with native GDB.
Portably written object code compiled for VxSim (for SunOS SPARC)
will usually load without recompilation on a SPARC target. And,
BTW under 5.1 switching from one architecture to anthoer really is
pretty painless.
------------------------------
ITEM: Can I use one boot EPROM for multiple boards on the same net?
WRS provides EPROMs with a default bogus bootline, virtually all
boards come with non-valiatile RAM which is set as soon as the user
fills in his parameters (which include CPU #). Therefore 1 EPROM may
be duplicated and used in all boards at a site. If the board does not
contain nvram then ROMs have to be specially blown, unless a custom
scheme for reading some switches or something is coded to index into a
bootline table. In 5.1 BOOTP is supported -- no more repeated EPROM
burning is necessary.
------------------------------
ITEM: What's the deal with 68881 FPU code in interrupt handlers?
In general, FP context is optimally saved only when the scheduler
notices that the new task coming in also uses the fpu (VX_FP_TASK).
ISRs don't. If no tasks are using the FPU then ISRs may go ahead,
unless different levels of ISRs could interrupt each other and again
cause a protocol violation.
------------------------------
ITEM: X for VxWorks
WRS has a product called windX which supports Motif. There is also
libX11 contribution in the VxWorks Archive. This package is perhaps
fairly old and out of date. Essentially, to port X stuff to VxWorks
you'll need to do make sure code is re-entrant everywhere. There is a
"multi-thread" safe version of Xlib available somewhere on the net, one
might try porting that. There are also vendors that have built X servers
using VxWorks. Jupiter Systems, in Alameda, makes high-end X server
machines based on VxWorks.
-----------------------------
ITEM: IEEE-488 (GPIB) driver for VxWorks
- National Instruments has lots of GPIB stuff
- THEMIS computers has TSVME-409 whic hincludes a GPIB interface.
- APLABS probably has some GPIB stuff too.
-----------------------------
ITEM: How does one disable NFS client caching?
VxWorks caches read and write requests in NFS client code.
To completely disable read and write cache, set nfsCacheSize to 0.
To just flush the write cache as needed, use nfsCacheFlush() or
FIOSYNC ioctl().
------------------------------
ITEM: How does one get better network I/O performance?
Most of the overhead is due to socket to network core interface overhead.
The copy that happens between the socket layer and network core code
can be avoided by using the routines in uipc_socket.c (as in BSD tahoe
release code available on various archive sites) and using mbufs directly.
You can also try using raw etherLib routines. However, etherLib also
does copying between user application and network driver.
If you must use the socket interface (sockLib), make sure you tune the
socket level buffers sizes to optimal values using setsockopt() calls
SO_SNDBUF and SO_RCVBUF. You might also just try changing the globals
that control the following default parameters to larger numbers (all
the way upto 48K):
tcp_sendspace (default 4K)
tcp_recvspace (default 4K)
udp_sendspace (default 2K)
udp_recvspace (default 4K)
To get around extra latency in some cases, you might turn on TCP_NODELAY
option on TCP sockets.
------------------------------
ITEM: How does one troubleshoot a backplane driver malfunction?
There are a few rules of thumb:
1. try the simplest case first -- use polling instead of
bus or mailbox interrupts and software test-and-set
instead of hardware test-and-set. See if this
works first. And then try hardware test-and-set
and then the desired mailbox or bus interrupt.
2. use bpShow() to see what's up. Also look for magic code
0x1234 in share mem area being used for messages,
and verify heartbeat is being incremented.
At the "anchor" you should see the magic code (4 bytes)
followed by a long word which should be incrementing (the
heartbeat) every second.
3. verify all memory mapping and make sure there's no
address conflicts on the bus
4. make sure bus controller is functioning properly.
Some combinations of boards might not work well
especially if your system controller board
arbitrates the bus in one way and other boards
expect to be arbitrated in a different way.
Sometimes you might need to use a separate
system controller. Of course, also make sure
you only have one bus master. And that your VME
bus strappings (BREQ, IACK daisychains) are right.
------------------------------
ITEM: How do I add select support to my driver?
#include "selectLib.h"
...
xxx_init(...)
{
...
selWakeupListInit(&xxxdev->selwakeupList);
...
}
xxx_ioctl(...)
{
...
switch(request_type) {
...
case FIOSELECT:
selNodeAdd(&xxxdev->selwakeupList,
(SEL_WAKEUP_NODE *)request_arg);
if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELREAD)
&& readable_condition_is_met)
selWakeup((SEL_WAKEUP_NODE*)request_arg);
if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELWRITE)
&& writable_condition_is_met)
selWakeup((SEL_WAKEUP_NODE*)request_arg);
break;
...
case FIOUNSELECT:
selNodeDelete(&xxxdev->selWakeupList,
(SEL_WAKEUP_NODE*)request_arg);
break;
...
}
}
And, add calls to selWakeup() as appropriate in your interrupt handlers
and read/write routines as selective conditions are toggled or satisfied.
------------------------------
ITEM: What third party products are available for VxWorks?
I tried to include the third party products, list of consultants,
services, goodies, etc. available for VxWorks from various sources but...
there are too many to list here. Instead,
the file:
netcom.com:~ftp/pub/hjb/vxworkers
is updated in realtime to contain a list of individuals and companies
that offer help, services (paid or unpaid), and goods for VxWorks.
To get a copy (if you don't have ftp access) or to be listed in this file,
please contact or send info in ASCII to:
------------------------------
ITEM: 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 lights
- modems
- sonar systems
[ And, regrettably, in: ]
- Patriot Missile guidance system and other military stuff
---------------------------------
ITEM: A complete list of CPU hardware supported by VxWorks
Complete list of WRS supported BSP's are available in:
netcom.com:~ftp/pub/hjb/vxbsp
VxWorks runs on a lot of different hardware. Majority of hardware
supported is based on VME bus. Porting VxWorks to a new VME board
based on MC68K takes only a few days, give or take a week, depending
on your karmic condition at the time. A lot of the ports are
initially done by the customers and later "approved" by WRS, for
which they charge, in order to keep them on "supported" list.
Porting to a new "architecture" (new processor) takes longer.
This varies more widely -- from a few months to a few years.
---------------------------------
ITEM: A complete list of peripheral devices supported by VxWorks
Complete list of WRS supported BSP's are available in:
netcom.com:~ftp/pub/hjb/vxbsp
VxWorks supports a wide variety of devices. A lot of device drivers
are written both by customers and WRS staff. There are device drivers
for almost popular available ethernet chips (except perhaps SEEQ and
Fujitzu, etc.), various serial chips (MC68681 DUART, Zilog 8350 Sync/Async
COMM chip, etc.), little I/O thingies in micro-controllers (MC68302
serial I/O, etc.), SCSI, etc.
Customers of VxWorks, hackers and other hardware vendors (especially
VME) usually have a VxWorks driver for their board. There are drivers
for FDDI boards, GPIB boards, A/D D/A boards, Graphics controllers,
frame grabbers, stepper motors, pin-ball machines, and etch-a-sketch
toy games.
Some evil VxWorkers have drivers for missile guidance systems.
----------------------------------
ITEM: What's with these unbundled "accessories"?
Propaganda from WRS:
The new product/feature doesn't need to wait for the
next OS release. Only the users who want/need it pay for it
lengthens price list which keeps individual items lower
but still enhances WRS revenue growth.
Please Note:
WRS still always adds features to the core product, and
has never taken items out of core product to make them
unbundled. Unlike UNIX vendors and others.
-----------------------------------------
ITEM: How come my 5.0.2 BSP isn't available in 5.1, damn it?
Propaganda from WRS:
WRS tries to give customers 1 year warning when any product
may be discontinued. Unfortunately, all the bugs in
the notification system are still to be worked out.
Complain vehemently to your sales rep. if he didn't
keep you informed. WRS BSP obsoletion policy is primarily
based on BSP volume and h/w avalability.
The 5.1 Guide and Release Notes provide a step by step recipe to
upgrade from 5.0.2 -- minimal changes, start by ANISifying. The BSP
Port Kit 1.1 provides extensive info for the masochist.
----------------------------------------
ITEM: How much is VxWorks?
In general: Not free, in fact, quite the opposite.
- Development License $23.5K (per project?)
- Source $120K.
- Target Licenses from $1000 for single quantity to $10 for 100,000+.
------------------------------
ITEM: What is MicroWorks?
VxWorks is also available as a kernel-only product (MicroWorks 1.0) for
the following processors:
i960, 680x0, 683xx
MicroWorks is -- half the product at a half the price.
It has no network, native debug, shell, or profiling. Comes with
VxMon a very portable ROM monitor to talk with an enhanced vxGDB 2.0
also included -- this is the debug agent which allows true system
level debugging in ISR or wherever. In future, VxWorks may also be
able to work with VxMon.
Development License $12,500.
------------------------------------
ITEM: Other Unbundled Products for VxWorks?
Other unbundled "accessory" products are: VxMP ($4K) which is an
extended shared memory capabilities for the kernel allowing semaphores
and other objects to be manipulated over the backplane transparently
(really!).
VxVMI ($3K) is a library of virtual memory interface routines allowing
text & kernel data protection. complementary products: BSP Port Kit
1.1 ($2K), VxSim 1.0 ($5K), WindX ($3.5K), WindC++ ($2.5K), WindC++
Gateway for ObjectCenter ($?K's).
-----------------------------
ITEM: How can I find out more about VxWorks?
Read: comp.os.vxworks
Email: inqu...@wrs.com
Call: 1-800-KIL-WIND
------------------------------
ITEM: What other net.resources are available on real-time systems?
There is at least one other newsgroup devoted exclusively to a particular
vendor's real-time operating system:
comp.os.os9 Discussions about the OS/9 operating system.
Here are some other related newsgroups:
comp.arch Computer architecture.
comp.arch.bus.vmebus Hardware and software for VMEbus Systems.
comp.os.misc General OS-oriented discussion not carried elsewhere.
comp.realtime Issues related to real-time computing.
comp.os.os9 Issues related to OS9 and OS9000 realtime OS.
There are too many other newsgroups devoted to computer operating systems
to list here. The interested reader is advised to check the "newsgroups"
file on a local news service machine.
The automatic server for users of pSOS RTOS is now in place.
PSOSUSER - A list intended for the discussion of topics relating to
pSOSystem and other products of Integrated Systems Inc.,
Software Components Group.
Send articles to psos...@isi.com and administrative requests to
lists...@isi.com.
If you aren't already subscribed and would like to, please send a mail
message to list...@isi.com containing the following in the body of
the message
SUBSCRIBE PSOSUSER <substitute your full name here>
------------------------------
ITEM: Contributions to comp.os.vxworks FAQs.
The following net.folks, among others, have contributed to this posting:
Mark Linimon: lin...@nominil.lonestar.org
Geoff Espin: ge...@wrs.com
Rev. Bob "Bob" Crispen: cri...@foxy.boeing.com
Stan Schneider: st...@rti.com
Fred J Roeber: f...@ssd.ray.com
Marc Friedman: m...@verdix.com
Joe Van Andel: vana...@ncar.ucar.edu
I welcome flames, insults, accusations, reactions, additions, and
corrections to this posting via email:
===============================================================================