So you wanna develop for an overhyped, underpowered, proprietary OperatingSystem
? Then welcome back to the good old dog-days of DOS, baby!
You get keen features such as:
- totally flat memory model
- poor process control
- no support from 3rd party tool vendors so you are left with a binary-only piece of AbandonWare where's the link to the abandonware?
- quick reboots - because you'll need it when your programs accidently stomp on each other
Seriously, cough up the extra 64k of RAM that it'll require to run some flavor of embedded Linux simply to get real memory management and a mature and rich set of debugging and development tools. Your sanity will thank you.
Why not try a better alternative? RTEMS, a RealTimeOperatingSystem
with not only much better performance than VxWorks
, but also OpenSource
Uhh...I don't know what planet you are from, but on Earth VxWorks is
the operating system for embedded applications. Those who build on a VxWorks platform are glad they did. Those that don't wish they had. You can go ahead and bad rap WindRiverSystems products all day long if you want, but take a look at whose OS gets second and third party support and whose doesn't. That line above about "no support from 3rd party tool vendors" is wrong. Furthermore, it is BS.
I've developed on V
xWorks for many years and have never been glad about it.
Okay. That's too bad, but there are quite a few products out there that wouldn't exist at all if it weren't for VxWorks. Never mind WRS support, which is marginal at best. It's the OS that provides the base from which good products are made.
xWorks indeed does have third party support. Trouble is, it's expensive, and rarely any better than what you get in the OpenSource
seems to want to be the MicroSoft
of the embedded systems world; if not for Linux they might well do so.
That said, V
xWorks does what it sets out to do -- it's a fairly lightweight RTOS (compared to some) with the above-indicated architecture. Comparing it to MS-DOS is rather unfair; while it doesn't have multiple processes (with multiple address spaces and symbol tables) it does have true threads. And it does indeed have a flat memory model, which M
essyDos does NOT have. (No such thing as a FarPointer?
A newer version of V
, does have a sophisticated memory protection model, arguably more sophisticated than the kernel/user process model found in Unix and its derivatives. (Whether it is better or not, I dunno; I haven't used V
Depending on your application, Linux or a RealTimeUnix?
might be a better OperatingSystem
xWorks. Or you might be better of with a "picokernel" or nothing at all. However, V
xWorks is a reasonable (though expensive) solution for many embedded systems. It certainly isn't a horrible product.
I've been working on EmbeddedSystem
s using V
xWorks for six+ years now, and were I to specify the OS for a future product V
xWorks would be in the running. (It wouldn't necessarily be the front runner, but it would be a candidate).
I tried C-Executive (a "real time" UNIX cut-down derivative) for a network interface card project I was on a few years ago. Ouch! I'll never hurt myself like that again.
xWorks system interface is sloppy: the folks at WindRiverSystems
seem not to have heard of the ConstQualifier
. Their NickelAndDime BusinessModel
is a BigPain?
(but supposedly fixed with AE).
In fairness to WindRiverSystems, much of the ConstIncorrectness is due to the C standard library being ConstIncorrect.
as cool as it sounds, or am I letting my bigotry cloud my judgment? Oh for a RealTime OpenBsd
Working on the SpaceShuttleMainEngine
controller software gives me room to say RealProgrammersWriteTheirOwnOperatingSystems?
I put down "write OS" in the schedule. My boss didn't like it. So now we're stuck with VxWorks. :)
xWorks is used to drive the Mars Exploration Rovers (no pun intended). It runs on a radiation-hardened version of the PowerPC chip. VxWorks
also was the O/S on Pathfinder, which if you recall was a tremendous success, once they debugged and fixed (very remotely) a timer problem. -- StevenNewton
And a misconfiguration of a FLASH filesystem driver seems to be why the SpiritRover? is having trouble. See MarsSpiritSoftwareProblem
Thanks, but that's simply speculation at this point. Just by the way -- have you ever tried to figure out an Apache install? Oy! So please don't go pointing figures at V
xWorks because somebody mis-configured the FLASH file system.
Anyway, why wasn't this tested sufficiently?