From the obtuse press release:
• First and only real-time operating system to support C++17, Boost, Python, and Rust collection of technologies, along with continued support for languages like Ada and SPARK
• New LLVM-based infrastructure that enables support for a broad set of modern and productive tools and frameworks
• New open source board support packages (BSPs) such as Raspberry Pi and TI Sitara AM65x for quick prototyping and flexibility of choice
• OpenSSL 1.1.1 for the most up-to-date cryptography libraries
Very informative headline, I know, but VxWorks isn’t exactly a very approachable topic, so I had to make do.
We used VxWorks about 20 years ago on single board computers plugged into VME crates. It was required for critical, but not particularly demanding, realtime performance. I never programmed for it, but all our source code had lines like “#ifdef VXWORKS …” As far as I remember it worked fine, no better or worse than our other operating systems. A product that filled a niche. How big that niche is today I don’t know.
Personally, I wouldn’t be very interested in VxWorks due to it being proprietary, and I’ve decided long ago that proprietary platforms do more harm than good.
But I am interested in realtime capabilities. I’ve used embeded linux SBCs for realtime applications (like directly controlling GPIO pins attached to servos and motor controllers). The results can be very disappointing at first. Some people even say it’s not possible, and so the solution is often to offload realtime functionality to a microcontroller, but it’s still disappointing that an application running on linux isn’t able to do it better.
Obviously linux isn’t designed as a realtime OS, however after trial and error and applying some tricks, I was able to overcome some of the lousy realtime characteristics on my linux SBC. Initially I found no matter what I did with process priorities, I could not get linux to execute realtime code in a timely manor (as needed by the external hardware). The jitter caused by linux’s loose scheduling became apparent through the vibration and jumpiness of physical servos.
I found that if I were willing to dedicate a single CPU core to IO processing with a realtime process and never relinquish the processor (ie using busy wait loop), then the GPIO signals output under linux became perfectly smooth. My SBC had six cores, and this worked, although the busy looping really wasted power. So I went back to the timer based code, however this time I scheduled the timer to trigger earlier than the necessary pulse time and then busy looped over the jitter uncertainty period. This ended up working very well without the need to peg the CPU at 100%!
This is not as good as a true realtime OS, which I’d still like to try. But in any case I found that using this technique ended up being perfectly usable for my purposes of realtime motor control under linux. While I didn’t have any problems after this, it would probably be safer to use a dedicated microcontroller if there were consequences for the linux control process crashing for some reason.
“Personally, I wouldn’t be very interested in VxWorks due to it being proprietary, and I’ve decided long ago that proprietary platforms do more harm than good.”
Should we all guess that the hardware you use is not a closed platform without closed firmware etc???
You should understand that tools are developed by others in order for us to pay for them to save us time. It is called financial transaction. You paid for the SBC and you bought a closed system (most SBCs used blobs loaded in the kernel, so yes, the linux you use is somehow proprietary) because you did not want to buy sand, build a machine for “cooking” chips and so on. Exactly in the same way, some we pay for some pieces of software so we don’t need to solve AGAIN the same problem.
You tried to solve the problem of real time process management and failed…. You could invest TIME in order to learn how to do it OR you can invest MONEY in order to get the solution ready for use. It has nothing to do with closed platforms. It is pure capitalism. Stop being a software communist.
CavemanGR,
I concede that open hardware isn’t always available, but I’ve been bitten by proprietary hardware enough times to know that open hardware is almost always a better choice for me when it is available since it means I can fix problems even when the vendor isn’t interested. Granted, not everyone has the technical skills to support themselves, but if you do, the benefits of openness are very apparent.
I for one would be happy to pay a premium for hardware with well supported open source drivers. It’s really not just about philosophy but pragmatism and solving the real problems that usually stem from closed/proprietary hardware. I don’t know if you realize it, but many SBCs suffer today due to proprietary hardware that’s not documented nor fully supported. The ARM chip manufacturers are primarily targeting mobile platforms, which isn’t necessarily a problem in and of itself, however in practice this translates to bad linux SBC support and running obsolete linux releases that cannot be easily updated/fixed. As a developer, it can be extremely annoying to be stuck on older releases when you need newer features! We’re seeing a lot of these SBCs lack hardware features/acceleration under linux for the same reason: proprietary hardware. These features are present on the chip and work in android, but we can’t use the chips to their full extent specifically because we lack the source and specs. So, these are some of the reasons that open tech is better.
Were did you get the impression that I failed? It worked for me, I succeeded!
If you are content with proprietary solutions, then more power to you, but the way I see it:
proprietary = fixed purpose & limited
open = limited only by one’s imagination and skill.
My aversion to proprietary platforms is NOT because they may cost more, but because time and time again I find them to be more limiting! Openness may not be as important for someone with little imagination or skill, but that doesn’t describe me 🙂
I wish the voting system was back, because this is one of the many times where I don’t have anything to add, but would like to register my 100% agreement with you.
We used VxWorks in 1991 (on VME bus cards) for a space robotics project for ESA.
It was really fun to work with, cross development from a Sun, VxWorks accessing the binaries via NFS.
One day we had representatives from VxWorks in house, for a Q&A session. One of our people, many of whom were completely occupied with sw. engineering methodologies (Yourdon was popular at the time) asked what VxWorks did to design their software. The answer was that “we don’t believe in circles and arrows” but in code instead. Some colleagues very dissapointed and recommended against using VxWorks, but it worked out well anyways.
I always think about that when people start arguing for the latest “methodology”, and smile without telling why.