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.
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.
We use it at my company for several products. There is something magical about running a lightweight OS on a Cortex-M4F or Cortex-M7. It is how I imagine the early Linux days.
You get to write device drivers and dig into the OS internals. There is even a port of the uIP TCP/IP stack that can be used with development boards such as the Nucleo-144.
How's your experience with writing device drivers for NuttX? Is it easy to attach manufacture's device libraries? The biggest reason that I stick to FreeRTOS is the fear of writing device drivers from scratch for a big RTOS like NuttX.
I did some contributions to RIOT-OS [1]. Honestly it was nightmare to me because they have strict policies not allowing manufacturer drivers so I should write peripheral registers directly, which leads to a lot of bugs that is hard to debug.
I'm also a FreeRTOS user who periodically peers over the fence at NuttX, but similar fears prevent me from making the jump.
In particular, I get really nervous about scenarios where multiple low level peripherals needs to cooperate to get something to happen— thinking about something like having a DMA drive a timer to piano-play oddball serial protocols like the WS2812 one. That's enough of a nightmare in bare metal where you have total control over all the registers; I have trouble imagining an OS abstraction layer which wouldn't make it considerably worse.
Were these "strict policies" licensing issues? Or coding standard issues? IMO these issues are orthogonal to ease of integration.
Writing a simple driver for say an I2C sensor is quite doable.
However, getting a driver into mainline requires conformity both in terms of licensing and in terms of coding standards for the whole library, including 3rd party code.
I contributed to port a new microcontroller, which includes writing device (peripheral) drivers.
It was pretty much about their coding standards. I had that experience because I was contributing for mainline branch. They think avoiding abstracted manufacturer peripheral libraries (like STM32 HAL) is the best way to keep the binary small. It is pretty much appose to what Zephyr OS is doing.
I think peripheral libraries are adopting BSD license these days so the license shouldn't be an issue these days.
NuttX also has strict licensing and coding standard enforcement. Such things are a necessary component of QA and I would think that all serious RTOS's have similar standards.
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