[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...

> - 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...

[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.

[npendleton]

Thanks Gregory, that's really good info! Appreciate you taking the time to reply (and for all your work on this software, too!).