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)
> - 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)
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.
> 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.
Please stop using indentation for quotes. It makes things impossible to read on mobile, and in this case even on desktop I had to side-scroll quite a bit to read everything.
It is a weird quirk of the HN team refusing to make it better even though it takes a few CSS tweaks. It's just one of those internet mysteries at this point.
My favorite flavor, plantuml, available with a cheesy (but very convenient) cli wrapper via npm- https://www.npmjs.com/package/node-plantuml
The --unicode mode is particularly delightful
It would be remiss at this point not to recommend websequencediagrams[0].. been using it for years (and convinced multiple workplaces to shell out for the self hosted version..). It's great :)
