
NuttX – A POSIX-compliant RTOS for embedded platforms - donquichotte
http://nuttx.org/
======
npendleton
A few bits of trivia for anyone considering NuttX:

    
    
      - uses a pure software interrupt and redirects to your ISR's, so you incur additional overhead for all interrupts in your system
      - ships with a homegrown c stdlib, which has several functional/security bugs (ex: vscanf will overflow if you use format specifiers other than [l]i/u), and neglects to provide gcc attributes for arg checking for the printf family functions
      - build system issues $(MAKE) calls in every folder you're building, which makes it terrifically slow (especially noticeable on incremental builds)
      - architecture makes it difficult to write custom drivers without building them into the kernel (eg if you want to use the kernel as a module in your project)

~~~
patacongo
> \- uses a pure software interrupt and redirects to your ISR's, so you incur
> additional overhead for all interrupts in your system

Not true. Like Nucleus OS, NuttX supports two class of interrupts, What
nucleus calls "managed" and and "raw" interrupts. The raw interrupts zero-
latency, no overhead interrupts:
[http://www.nuttx.org/doku.php?id=wiki:nxinternal:highperfint...](http://www.nuttx.org/doku.php?id=wiki:nxinternal:highperfints)

> \- ships with a homegrown c stdlib, which has several functional/security
> bugs (ex: vscanf will overflow if you use format specifiers other than
> [l]i/u), and neglects to provide gcc attributes for arg checking for the
> printf family functions

Yes, it uses a custom, POSIX-compliant C library. I have never heard of any
such bugs, however. All of the NuttX common code is compiler agnostic.

>\- build system issues $(MAKE) calls in every folder you're building, which
makes it terrifically slow (especially noticeable on incremental builds)

Re-build time is around 10 seconds or so on a lower-end to mediocre Linux box.
A full build cycle (clean, reconfigure, build-from-scratch) is more like 30
seconds.

Windows-based builds are a lot longer.

>\- architecture makes it difficult to write custom drivers without building
them into the kernel (eg if you want to use the kernel as a module in your
project)

Kernel modules are fully supported:
[http://www.nuttx.org/doku.php?id=wiki:nxinternal:kmodules-
sh...](http://www.nuttx.org/doku.php?id=wiki:nxinternal:kmodules-sharedlibs)

~~~
brandmeyer
Most RTOSen allow you to access a minimal set of kernel services from
interrupt context, so that you can implement the standard top-half/bottom-half
driver processing model. NuttX's managed interrupts are in this category, and
almost any driver's interrupt handler needs to be as well.

Almost any RTOS on the Cortex-M profile will fully utilize the NVIC, giving
you a hardware-managed preemptive FIFO scheduler even in interrupt context.
NuttX's lack of this feature is a severe weakness, and a major reason to avoid
using it.

Additionally, some RTOSen will provide the ability to install interrupt
handlers that cannot safely access any kernel services. These are usually not
capable of doing much more than provide user-defined error handling prior to
taking a reboot. NuttX's raw interrupts are in this category.

~~~
patacongo
> Almost any RTOS on the Cortex-M profile will fully utilize the NVIC, giving
> you a hardware-managed preemptive FIFO scheduler even in interrupt context.
> NuttX's lack of this feature is a severe weakness, and a major reason to
> avoid using it.

I think this is a miconception about how RTOS's can work. Certainly in a bare-
metal environment (or with a minimum RTOS), prioritized interrrupt-level
processing is critical. But with RTOS's like NuttX, interrupts should be very
brief: You should enter the handler, perform mimimal housekeeping, and signal
a prioritized thread to perform the interrupt-related operations.

This is not a oversight in the design, it is intentional replacement of
prioritized interrupt handling processing with priorotized multi-tasking
processing.

The NuttX interrupt handling is designed so that the context switch after
signaling the prioritized thread is ZERO. The return from interrupt vectors
directly in the prioritized task (assuming it is the highest priority). This
is all intentional design and is very efficent in these regards.

There is no one-size, fits all RTOS. You find that some are too minimal and
primitive to meet your needs (I am thinking FreeRTOS, ChibiOS, Zephyr, ...)
and some may be heavier weight than is necessary for your purposes (perhaps
NuttX, nucleus, RTEMS, ...) or even heavier (VxWorks, QNX, Integrity, and on
up to Linux). If you want the features of one class of RTOS, then you will
find the others flawed in various ways, whichever RTOS is that one that meets
your needs. It is a kind of Goldilocks effect.

------
btashton
I have used it in a few shipped products. FreeRTOS is fine as a kernel, but a
the interfaces for networking or devices always felt just smashed on top of it
with no clean interfaces. This also made moving between hardware revisions
much more difficult. NuttX forces abstraction layers which sometimes makes it
a pain to do something simple, but in the long run prevents you from shooting
yourself in the foot.

Also they are having their first conference this year.

[https://nuttx2019.org](https://nuttx2019.org)

~~~
donquichotte
Would you mind sharing details (or rough descriptions) of the shipped
products? Or a broad category, i.e. "pace makers" or "motor controllers"?

~~~
akax
There are many products in the market running NuttX: many Sony audio recorders
and bluetooth headsets; all drones/quadricopters powered by PX4 are running
NuttX because PX4 is based on NuttX; Xiaomi/Pinecone are using NuttX on their
products and doing great contributions to NuttX mainline; Haltian ThingSee was
the first commercial IoT device powered by NuttX; Daruma DR-800 was the first
thermal printer powered by NuttX; many OptoFidelity products are powered by
NuttX, so if you have a good NuttX skills you can apply for this job:
[https://rekrytointi.com/en/vacancies/optofidelity/embedded-s...](https://rekrytointi.com/en/vacancies/optofidelity/embedded-
software-engineer-tampere/562325/) Our community is growing, even without a
big company like Amazon (FreeRTOS) or Intel (Zephyr) paying our bills. It's
growing because because this is a great and powerful RTOS.

~~~
patacongo
The defunct Google project Ara and it its living decendents TizenRT (tinyara)
and the Motorola MDK.

~~~
patacongo
Fitbit?

------
kbumsik
I personally only used FreeRTOS but NuttX always looks cool to me. There are
few open-source RTOS for microcontrollers that supports the wide range of
POSIX and VFS.

A notable use case is PX4 Drone Autopilot [1], one of the most successful open
source drone firmware project.

[1]: [https://github.com/PX4/Firmware](https://github.com/PX4/Firmware)

~~~
faisalhackshah
ArduPilot has switched from NuttX to ChibiOS. See the video for more
information [1]. If you don't require POSIX compatibility, it's really the way
to go. The kernel is very fast, and the HAL is much better compared to the
typical vendor peripheral libraries. Definitely take a look at it if you've
used FreeRTOS in the past. The community is excellent too with high SNR
content [2], and the main developer is very responsive.

[1]:
[https://www.youtube.com/watch?v=y2KCB0a3xMg](https://www.youtube.com/watch?v=y2KCB0a3xMg)

[2]:
[http://www.chibios.com/forum/index.php](http://www.chibios.com/forum/index.php)

~~~
patacongo
To be clear, they switched from a 3 or 4 year old version of Nuttx (prior to
interrupt optimatizations) to current ChibiOS.

~~~
faisalhackshah
Correct, and upvoted.

------
piotrkubisa
I found that Sony Spresense [1] board is one of example device that implements
NuttX [2].

[1]:
[https://developer.sony.com/develop/spresense/](https://developer.sony.com/develop/spresense/)

[2]: [https://developer.sony.com/develop/spresense/developer-
tools...](https://developer.sony.com/develop/spresense/developer-tools/get-
started-using-nuttx/nuttx-developer-guide)

~~~
kbumsik
Wow, I have never seen 6-Core Cortex-M microcontrollers like this.

~~~
gh02t
Clicking through, the price is more accessible than I expected, too. It's $66
for the base board.

------
scttnlsn
I recall taking a look at NuttX when I was shopping for an RTOS for a project
a while back. Ended up choosing Zephyr
([https://www.zephyrproject.org/](https://www.zephyrproject.org/)) but I'm
curious if anyone here has experience with both and can contrast them a bit.

~~~
SlowRobotAhead
That’s the thing, hard to have experience with multiples. People generally
stick to learning one or two. I know RTX and FreeRTOS differences, but I know
without a doubt I’ll try NuttX.

I starting looking at RTOSes when you were lucky to have 3 or 4 options
anywhere - and it wasn’t that long ago!

Now... with Amazon owning FreeRTOS... Intel and Nordic and Others going heavy
in zephyr for multicore... professional but niche options like RTX, Segger’s
OS, and a hundred others... and if you chip has a MPU/MMU someone is trying to
get Linux on it (whether it makes sense or not!)...

I think the market is getting pretty crowded. Personally the viable options
right now unless you need something large like VxWorks for Java runtime, I
think it’s a choice between Amazon FreeRTOS and Zephyr.

------
zealus
So far I've been having a lot of success with Zephyr OS
[https://github.com/zephyrproject-
rtos/zephyr](https://github.com/zephyrproject-rtos/zephyr)

It's quite easy to set up and writing drivers for it isn't really so much of a
pain. I don't know if one should state it as a pain point or a good point but
they do use CMake for the build system. So it's reasonably quick at least they
are using a newer version of CMake than most projects I've had the joy of
testing out.

Their APIs are quite linux/posix inspired in my opinion but with their own
zephyr flavor on top. But I would say NuttX is probably a more mature project
and Zephyr has been reworked quite heavily lately so a lot has changed but at
least they'll have an LTS release soon.

------
pumanoir
Does anybody know if this will run on the BBC microbit, and if it does, will
it have an advantage over mbed?

~~~
patacongo
The BBC Microbit supports a NXP/Freescale KL26Z. That chip is supported by
NuttX so the answer would be yes, with some additional board level support.

The NXP/Freescale KL26 has very limited resources, however. I would not
recommend using a higher end RTOS with very low end, severely memory
constrained MCUs.

------
proboscis
Cool. First time I've read about real-time operating systems. A pseudo
filesystem that resides in RAM is very interesting. I like how they've strived
for "greater scalability from the very tiny platform to the moderate
platform".

~~~
quake
RTOS are in everything! They make a ton of sense if you have a lot of
resources to manage or calls to external services that may block for some
time, like a modem connection. Lots of IOT products have RTOS's running under
the hood, where running a kernel even as stripped back as Linux can be is too
expensive computationally. And with less kernel/OS overhead, a true hard real
time system can be implemented with a pretty strong guarantee of safety (not
crypto safety, operational safety). There's a reason Amazon bought FreeRTOS a
while back.

------
tyhoff
Professionally, I've used FreeRTOS, ThreadX, and NuttX. I'm neutral on both
FreeRTOS and ThreadX, but had a really tough time with NuttX.

On a surface level, NuttX seems nice. Driver abstraction, POSIX compliant
(mostly), lots of platforms/systems already integrated and working in their
build system, lightweight (?), and includes some nice features out of the box
like a file system. It can be nice for small projects and with people who are
familiar with writing code for a Linux based project or who love to learn the
internals of the system. This is rarely the case.

I had two big issues with NuttX. The first was how huge it is from the get-go.
There are 10-50 files with the same name (for all the platforms) and a massive
amount of build system logic, which makes discoverability and knowing where to
make fixes difficult. Most companies only need 1-2 platforms, and the extra 48
laying around feels like unnecessary bloat, but deleting them feels like a
sin.

My second, but probably larger, issue with NuttX was around trying to develop
unit tests for the 90% of the code we added on top of it in the services
layer.

NuttX is a POSIX compliant operating system, and it likes to use the same
naming convention of many of the functions and files you'd find in your
standard UNIX/Linux system. When you try to write a unit test for your
embedded code to run on your x86 development machine, as soon as a file you
are testing touches a standard header file, it's really difficult to wrangle
things. You have to provide a ton of override headers (eek), stubs, fakes, and
even then, as soon as someone includes a header somewhere in the include tree,
it'll break that unit test that was particularly well crafted so that it would
run on a Mac. If you want to run that test on a Linux machine, it would
require more IFDEF's and more time. The rationale for Linux not having unit
tests is that they have a massive community of nightly alpha testers to
surface and fix issues. That is not a good rationale for a firmware RTOS
because a simple service layer logic bug can result in a bricked device (or
thousands and thousands).

There's something special about reporting a bug to Express Logic about a bug
in ThreadX or (and in my case) FileX and being able to provide a simple 20
line unit test which compiles on any system without any special hackery that
exposes the bug. When we tried to do this with NuttX for the various bugs
found in the SmartFS module, it was actually really hard to report/reproduce
these bugs since there wasn't a simple way to "package" up the environment.
The "easiest" solution was to package the entire OS, a FUSE port of SmartFS,
and some of our code on top, which would run in simulator mode on our machine
which then could exposed the bug.

FreeRTOS and ThreadX have their issues as well, like blurred lines between
upper and lower layers and lack of training wheels from the satrt, but the
projects with these OS's could more easily build a modern firmware environment
with unit tests, faster build times, modern build system, and crafting a full
OS that worked better to solve the problems at hand.

~~~
patacongo
> NuttX is a POSIX compliant operating system, and it likes to use the same
> naming convention of many of the functions and files you'd find in your
> standard UNIX/Linux system. When you try to write a unit test for your
> embedded code to run on your x86 development machine, as soon as a file you
> are testing touches a standard header file, it's really difficult to wrangle
> things. ...

I use a trick to do that based on the objcopy utility with the --redefine
option. This is a not complicated, but still mind-bending at times.

NuttX supports a simulator that runs NuttX as a Linux application. This
requires the full bag of tricks to avoid name collisions:
[https://bitbucket.org/nuttx/nuttx/src/c38b6cb068404827d7c071...](https://bitbucket.org/nuttx/nuttx/src/c38b6cb068404827d7c071ae6f88aa6934d06b72/configs/sim/README.txt#lines-148)

------
snvzz
Nice and nifty. Although it doesn't support 68000 cpu family :/

Too bad it's not usable for high assurance. SeL4 is about the only option
there.

~~~
kbumsik
What is high assurance in the context of RTOS for microcontrollers?

~~~
snvzz
Guaranteeing things like worst case timing, complete with formal proofs.

Without formal proofs, no hard realtime is possible; What you've got is soft
realtime instead, the relaxed version where there's no guarantees.

~~~
nickpsecurity
Hard real-time without formal proofs is not only possible: it's the norm for
almost all hard, real-time systems out there. It's mostly about careful coding
and time analysis. Recent ones have had stronger isolation with formal
verification of a few. It's not necessary to get them working most of the
time, though.

Matter of fact, regulators for safety-critical fields are just starting to
accept formal verification as evidence. CompCert is only tool I know of that's
qualified to just one standard. If in those fields, using formal verification
instead of whatever evaluators are used to can get something rejected. It can
aid the development or be supplementary evidence at best.

~~~
snvzz
You're right in that this insanity is not uncommon.

Without formal verification, there's no guarantee deadlines will not be
missed, hard realtime will not fail and people will not die.

Sometimes failure is cheap; Other times it is not. A lot of systems out there
make outrageous claims of fitness with no formal basis.

What a sad state the industry is in.

~~~
patacongo
Ultimately, an RTOS can only provide you with the tools to create a hard real-
time system. The RTOS cannot guarantee that your application can meet any
deadlines. That requires the proper use of those tools by the application.

If you improperly prioritize tasks or use semaphore locks improperly or keep
interrupts disabled too long, then your application will not be real-time.

NOTE: NuttX does provide tools to measure interrupt latencies, response times,
and critical section times. Those are helps in creating a real-time system.

So, it is not a meaningful to ask if the RTOS has been certified in some way
to always meet deadlines. You should ask rather, does the OS provide the tools
that you need and does your overall application meets its deadlines.

~~~
snvzz
>So, it is not a meaningful to ask if the RTOS has been certified in some way
to always meet deadlines.

It is meaningful. If the system doesn't offer these guarantees, no matter how
good you are and how much effort you put into what's within your scope to
implement, you won't be able to offer any guarantees.

This is ok if you can afford to fail. Just don't use it e.g. where human lives
would be put at risk.

------
iheartpotatoes
As someone who has converted (symmetric) multithreaded apps to embedded,
seeing POSIX pthread support excites me.

------
iheartpotatoes
The name tho...

------
analognoise
What a terrible name.

Edit: Obvious sexual connotation to my ears. If I told a coworker "Just go to
Nuttx's website" I am 100% sure I'd have to explain it was SFW.

~~~
kbumsik
It is just the auther's surname (Nutt) + X. What's the issue?

