Zephyr is an open source real-time operating system (RTOS) that appeared on the scene a few years ago with support for a few boards. The new 1.11 release adds a lot of features, a lot of new boards, and also has a Windows development environment. But don’t worry, the environment is portable so it still runs on Linux and Mac, as well.
The OS has support for many ARM and x86 boards. It also supports ESP32, NIOS II, and can also target Linux which is useful for debugging or studying execution using desktop tools.
It’s not short of features, being very configurable and modular, it offers a single address space, and has native networking and Bluetooth Low Energy (BLE) stacks. You can create preemptive or non-preemptive threads with support for a pthread-compatible interface. There’s the usual set of services like memory allocation, semaphores, and message queues. There’s even support for common file systems.
In addition to compiling code for the Linux (well, POSIX) platform for testing, you can also target several flavors of QEMU to simulate a particular target system.
Overall, Zephyr is worth a look if you are using one of the supported boards. Or, do a port to a new board and contribute it back. That’s the beauty of open source, after all.
Another common RTOS is FreeRTOS which has an extra C++ class wrapper. Or, for something smaller have a look at ChibioS.
I think the intel OS for their arduino 101 was zephyr based (whatever intel called it, at the time). there was the regular arduino environ for the curie chip and there was the intel os thing. I remember the blink app would run fine in arduino, on the 101 board, but the same ‘blink’ kind of app was well over 100 lines of C and crashed on that board, when run for more than a few seconds. I left intel very UNimpressed with zephyr (and their whole arduino 101 effort).
maybe its an ok os, but if ‘blink’ takes that many lines and still won’t run reliably, color me unimpressed.
link where intel mentions it: https://software.intel.com/en-us/node/674972
Zephyr RTOS is in fact open sourced Virtuoso nano offspring, very old RTOS from end of the 90’s aquired by multiple company that end up at Intel.
Zephyr in itself is nice when your board is well supported, otherwise it’s quite difficult to integrate vendor SDK/peripheral lib into it. They also had the bad habit of modifying 3rd party code to fit their type naming which is just plain wrong.
At least they are moving from kconf build to cmake, which will allow other OS/IDE support.
When I tried it, I couldn’t even configure the most basic things to compile, and there seems to be hardly any documentation. As I looked at a whole lot of RTOS options, this was on my short list initially, until I tried it. Then it dropped off my list, after still not running on hardware after a full day of trying to get the basics to run. It seems an unwieldy beast that doesn’t know what it wants to be.
Other things I looked at where RIOT-OS, Mbed-OS, FreeRTOS and ChibioS.
* RIOT-OS at least build out of the box without issues. But their peripheral driver for most supported platforms is very incomplete. Also lacks a bit of usage information, and wasn’t very suited for my goals.
* Mbed-OS, a bit flash/ram heavy at times. Uses a heap internally for a few things, but quick to get started with. Their tools around the source can feel a bit “unfinished” at times, online compiler breaks down a lot, and the commandline builder lacks a bunch of features you would expect. Peripheral drivers are not very feature rich, but can serve your goals if you don’t need to do complex things.
* FreeRTOS, at least does not pretend to have peripheral drivers, and has lots and lots and even more documentation and help on the planet.
* ChibioS, I find this an odd duck. It has a strange license model, and a lot of different “running states” you need to properly account for (you can only call this function from state “X”) instead of the usual “normal” and “interrupt” states. The whole development and support also seems to balance on 2 or 3 people. But overall, very complete.
In the end, I went with Mbed-OS. For the simple reason that it made reasonably simple tasks simple. And hard tasks will remain hard no matter what driver layer and OS you have. At least the less important tasks that need to run where quicker to program and test this way. However, if your cost of your controller is important, then this slightly more memory hungry RTOS might not be your best option.
I’d toss NuttX out there if you have a reasonably competent CPU. Reasonably POSIX API, and has a simulator you can run on your local host. The downside was trying to figure out how to implement a new application; the build system could use a bit of love last time I checked (which was around a year ago).
RIOT was my other contender there, but as you point out, it wasn’t very versatile in terms of hardware (and had no IPv4 stack IIRC — though IPv6 was supported).
I put nuttx and zephyr in the same basket, they are a combination of RTOS and framework/application collection. It either work fine or not depending on platform/application.
chibios is close related, albeit to a lesser extend. The biggest issue with chibios is it’s license, as GPL prohibit any serious industrial use.
FreeRTOS is nice as it doesn’t impose any build system or device framework, it’s a bare RTOS. License change after amazon aquisition was welcome as its GPL+exemption was awkward.
On the other hand FreeRTOS has some drawback: behavior between ports is not coherent (especially ARM and other ports) and could lead to platform issues. It’s quite a pain to debug also if you don’t use debugger RTOS integration (mainly due to its everything is a queue paradigm).
In the end there is no “universal” RTOS, freeRTOS is probably the closest, or not, depending on you expectation on what is an RTOS.
Hi daid303,
I suggest you to try NuttX RTOS (www.nuttx.org). It is a POSIX RTOS with Unix/Linux features and it is very complete: USB, Ethernet, WiFi, 6LoWPAN, CANBus, etc and BLE stack is on the way.
The project is very nice and useful (like Linux), but needs more advertising (like Linux in early 90’s).
I’m trying to help more people to discover about NuttX: http://www.youtube.com/c/NuttXChannel
Oh, I did investigate it (I looked at about 40 options, but only tried 5 in more detail), but it provided everything I didn’t need, and nothing I did need ;-)
I don’t need networking, USB and display. But I do need low level GPIO, PWM, I2C, UART, SPI drivers. As I’m controlling custom hardware.
It also suffers the same problem as 80% of the things I looked at. The documentation is shabby and disorganized. If you want more people to look into it, make it accessible. Don’t make us do a week long of tinkering and trying just to get the basics to work.
Where is the quickstart guide? Where is the example section? Most likely it’s somewhere on the Wiki and you will link to it now. But accept the fact that I didn’t find it, and that people don’t want to spend their time plowing trough the mess that is most Wikis.
Finally, on the main page, list what it’s NOT, it has a great list of what it can do. But it’s lacking what it cannot do. What’s the target? Memory/flash requirements?
Everything is as valuable as it’s quality of the documentation.
I work with Nuttx and have plenty of gpio, i2c, spi, uart, pwm, adc lines running. What is lacking in spi or i2c code space?