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, N

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.