NuttX vs. Zephyr vs. …

[Tation]

Hi all,

Long time user of mbedOS (recently EOLed), Keil RTX, FreeRTOS… but I think it is time to embark on other RTOSes for use in more connected embedded and also in targets different from ARM (FreeRTOS covers this)

Tried Zephyr… found it hard to learn, and the device tree stuff excessively complex/confusing. But graphs like this:



kept me trying. But in fact I was using it with the feeling that I was not knowing what I was doing. So thinking now in entering NuttX.

Does anybody have experience with NuttX? Can report on any successful (or not) use cases?

My main goals are, in any order:

• useable within ARM, ESP32 and RISC-V
• easy management or integration of TCP, USB, BLE stacks & TLS
• useable with the dev tools of my taste (prefer clang/cmake over gcc/make)
• call me old school, but I do prefer readable, complete and easily accessible documentation over other more modern approaches
• good community support
• porting to another target not an impossible task for mere mortals

Thanks a lot & regards.

[brucehoult]

I've never tried any RTOS myself (it's been either bare metal or Arduino library for me lol) but Lup Yuen Lee has done vast amounts of tutorial stuff on using NuttX.

[SiliconWizard]

Zephyr is good but quite a bit more complex to master than most others listed, so not surprised it gets you confused.

NuttX looks like a good alternative. FreeRTOS is obviously fine and widely used, but not as well architectured IMHO.

[betocool]

Zephyr is good but quite a bit more complex to master than most others listed, so not surprised it gets you confused.

NuttX looks like a good alternative. FreeRTOS is obviously fine and widely used, but not as well architectured IMHO.

I'm genuinely curious why you say that? I personally prefer FreeRTOS over Zephyr (both I've tried) and so far FreeRTOS has covered all my needs and worked without issues. Then again, I'm not much into the internals, I'm only a user.

I moved into Zephyr because I had to, using nRF52 and BLE. The whole IDE is based on Zephyr and West and CMAKE which I didn't like very much. But on the other hand, the integration of a bootloader and some SD Card libraries made it easy to work with. Documentation on Device Tree Sources and all possible options (or not!) is very lacking. Seems like you either were a Linux / Software guy and already knew about that from years ago or you are screwed and just copy examples over. I took the second path. All other OS kernel resources (data pipes, mutexes, etc) work very well and getting into that from FreeRTOS world is not difficult if you understand the concept.

Maybe Nuttx is worth a try, but if it's not an integral part of the IDE's or the STM32 ports are not well supported then maybe I'll skip it for the time being.

Cheers,

Alberto

[glenenglish]

I could not find in the Zephyr doco  a useful function that   freeRTOS has  portYIELD_FROM_ISR( xHigherPriorityTaskWoken ), but I am sure it is in there.

The system can go directly from servicing an interrupt then back to normal context with a desired task awoken -   which is excellent for servicing heavy post-interrupt jobs pronto....  I've found when push comes to shove, approaching hard real time, freeRTOS is the goods. I use FreeRTOS on AVR, STM32, Microblaze,  A53-MPSoC... etc

On those graphs, free-rtos  only shows nothing happening because it is solid and it works. and also I guess Zephyr is fairly new, so naturally there are lots of contributions.

FreeRTOS is written lean and mean, it is fast. Zephyr seems like some half-way to linux option

And the heavier option may be just what people want/need, which is fine.

There is a big diff with zephyr in that it knows about MMUs / MPUs. it also appears much more tightly tied to the platform, where freertos tries to be generic.

I recently carefully considered Zephyr on a new project ,  but I went to linux with the real time patch on one, and another project going with FreeRTOS on 1 core, and full linux on the other core.

I guess there is a bunch of people that dont like ucLinux and have between 4MB and 16MB available.

[betocool]

I don't think Zephyr has the "fromISR" option, I don't think it needs it at all. You can just signal or pipe or mutex directly.

In fact, I almost did not use ISR's with nRF and Zephyr, so I have no idea how that goes... or can't remember.

Cheers,

Alberto

[Doctorandus_P]

We of Zephyr recommend Zephyr.

And what does it mean? Maybe it just has too many bugs that still need to be fixed. Maybe some of those other projects are mature enough to "just work" and not need serious updates anymore.

[newbrain]

The need of FreeRTOS for portYIELD_FROM_ISR is more a limitation/design choice than a real user service.
When one uses a xxxFromISR API call, a higher priority task than the interrupted one might now be ready run, but the scheduler does not know unless portYIELD_FROM_ISR is used.
Remember that the yield will only take effect when the ISR (including possible nestings) returns.

Other RTOSes do not need this 'reminder' and do not need a special 'fromISR' API call set, e.g., threadX/Azure RTOS, and, apparently, Zephyr.

[KE5FX]

Can we just spare a few minutes' hate for graphing packages that use color palettes like that one to distinguish between different traces? 

[tggzzz]

Can we just spare a few minutes' hate for graphing packages that use color palettes like that one to distinguish between different traces? 

Around 8% of men are colour blind in one way or another, and they will have extra problems.

Personally my hate is thin 70% grey characters on a white background, or anything on a black background (very 70s retro; everybody breathed a sigh of relief when white backgrounds became the norm).

[gpr]

The need of FreeRTOS for portYIELD_FROM_ISR is more a limitation/design choice than a real user service.
When one uses a xxxFromISR API call, a higher priority task than the interrupted one might now be ready run, but the scheduler does not know unless portYIELD_FROM_ISR is used.
Remember that the yield will only take effect when the ISR (including possible nestings) returns.

Other RTOSes do not need this 'reminder' and do not need a special 'fromISR' API call set, e.g., threadX/Azure RTOS, and, apparently, Zephyr.

If you have googled a bit about portYIELD_FROM_ISR, reasoning behind it and why it is not the default behaviour, you could have saved yourself from posting such a nonsense about "reminder to scheduler".

[newbrain]

If you have googled a bit about portYIELD_FROM_ISR, reasoning behind it and why it is not the default behaviour, you could have saved yourself from posting such a nonsense about "reminder to scheduler".

I'd be glad to be enlightened, though.
portYIELD_FROM_ISR will pend a PENDSV interrupt if a task switch is needed, and perform no actions otherwise.
As the PENDSV interrupt is always set to the lowest priority in FreeRTOS, the switch will only happen at the end of the ISR.
The handler for PENDSV is the scheduler.

Yes, I omitted that in some port on more limited processors one must only use portYIELD_FROM_ISR at the end of the ISR.
Yes, it's a design decision that provides a bit more flexibility and possibly optimization, but imposes a higher burden on the user.

What am I missing?
Instead of being rude, be helpful.

[glenenglish]

The need of FreeRTOS for portYIELD_FROM_ISR is more a limitation/design choice than a real user service.
When one uses a xxxFromISR API call, a higher priority task than the interrupted one might now be ready run, but the scheduler does not know unless portYIELD_FROM_ISR is used.
Remember that the yield will only take effect when the ISR (including possible nestings) returns.

Other RTOSes do not need this 'reminder' and do not need a special 'fromISR' API call set, e.g., threadX/Azure RTOS, and, apparently, Zephyr.

No, no no.  this is not the case. ....  The OS cannot possibly know you want to dump the running task that was interrupted.

The OS has no idea if you absolutely must run a task next, as the IRQ service is not a scheduler context switch , and thus the scheduler will otherwise just go back to task it was running, and then continue according to the next-to-run list.

With portYIELD_FROM_ISR , you tell the OS- "do this next". Like, you must empty a hardware buffer NOW in the irq handler , and the portYIELD_FROM_ISR  enables the system to  "work on that new data - right now".

Now, what happens in a FreeRTOS SMP system in this case, I dont know. I have no experience with FreeRTOS does in this case  in an SMP environment and a portYIELD_FROM_ISR  call.

[gpr]

If you have googled a bit about portYIELD_FROM_ISR, reasoning behind it and why it is not the default behaviour, you could have saved yourself from posting such a nonsense about "reminder to scheduler".

I'd be glad to be enlightened, though.
portYIELD_FROM_ISR will pend a PENDSV interrupt if a task switch is needed, and perform no actions otherwise.
As the PENDSV interrupt is always set to the lowest priority in FreeRTOS, the switch will only happen at the end of the ISR.
The handler for PENDSV is the scheduler.

Yes, I omitted that in some port on more limited processors one must only use portYIELD_FROM_ISR at the end of the ISR.
Yes, it's a design decision that provides a bit more flexibility and possibly optimization, but imposes a higher burden on the user.

What am I missing?
Instead of being rude, be helpful.

You rephrased it from "portYIELD_FROM_ISR is more a limitation/design choice" to "provides a bit more flexibility and possibly optimization" which I fully agree with.
"imposes a higher burden on the user" is the price you pay for it (if you use it)

[nimish]

Zephyr has a ton of vendor support mostly because it's open to companies shoving their HALs into it, which Linux and NuttX actively discourage since vendor code usually sucks.

NuttX is much nicer from a software perspective as it tries to be very POSIX compliant. You can sometimes port apps 1:1 from the linux equivalent to the RTOS which gives you a very quick dev cycle. But it doesn't have as much vendor support despite its corporate use by Sony, Samsung and Xiaomi.

Weirdly, zephyr is from the linux foundation via intel but NuttX is apache.

[glenenglish]

Weirdly, zephyr is from the linux foundation via intel but NuttX is apache.

So THAT is why Zephyr is in the latest Altera FPGA SoC  ! (Intel bought Altera ) ....

[yar]

Does anybody have experience with NuttX? Can report on any successful (or not) use cases?

Yes. The kernel is very UNIX-like with little nonsense. It's not like FreeRTOS with dependencies on a lot of externals and is really just, what, six files that are "ported" via cp.

• useable within ARM, ESP32 and RISC-V All three are very well supported with dozens of chips/boards each.
• easy management or integration of TCP, USB, BLE stacks & TLS same
• useable with the dev tools of my taste (prefer clang/cmake over gcc/make) I haven't checked in for some time, but there was a near-mutiny over cmake.
• call me old school, but I do prefer readable, complete and easily accessible documentation over other more modern approaches cmake has been too modern. It's not a group that deals well with change and the discomfort of problems they're not even certain they have. Read their  dev list archives https://nuttx.incubator.apache.org/community/ for a few months. I'd recommend doing that for any group you're auditing, in fact
• good community support I have yet to see that in any OS dev world. :-)
• porting to another target not an impossible task for mere mortals To expand Bruce's point, Lup has successfully added several targets, mostly RISC-V and ranging from small to moderate size and from virtual to physical., He's made many improvements to the core and interesting infrastructure, that have been quite well documented. Read his https://lupyuen.github.io/#publications . The further your target is from something existing, of course, will reflect upon your experience as a mortal.