NuttX vs. Zephyr vs. … - Page 1
Forum section: electronics / general

author: Tation
author_rank: Regular Contributor
timestamp: July 20, 2024, 01:28:18 pm
content: 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-Veasy management or integration of TCP, USB, BLE stacks & TLSuseable 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 approachesgood community supportporting to another target not an impossible task for mere mortalsThanks a lot & regards.

author: brucehoult
author_rank: Super Contributor
timestamp: July 20, 2024, 01:53:15 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 20, 2024, 10:17:02 pm
content: 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.

author: betocool
author_rank: Regular Contributor
timestamp: July 21, 2024, 02:23:36 am
content: Quote from: SiliconWizard on July 20, 2024, 10:17:02 pmI'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

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 21, 2024, 09:46:59 am
content: 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... etcOn 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 optionAnd 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.

author: betocool
author_rank: Regular Contributor
timestamp: July 21, 2024, 11:05:15 am
content: 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

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 21, 2024, 12:04:29 pm
content: 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.

author: newbrain
author_rank: Super Contributor
timestamp: July 21, 2024, 12:19:20 pm
content: 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.

author: KE5FX
author_rank: Super Contributor
timestamp: July 21, 2024, 02:29:43 pm
content: Can we just spare a few minutes' hate for graphing packages that use color palettes like that one to distinguish between different traces?

author: tggzzz
author_rank: Super Contributor
timestamp: July 21, 2024, 05:08:20 pm
content: Quote from: KE5FX on July 21, 2024, 02:29:43 pmAround 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).

author: gpr
author_rank: Contributor
timestamp: July 22, 2024, 12:50:53 pm
content: Quote from: newbrain on July 21, 2024, 12:19:20 pmIf 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".

author: newbrain
author_rank: Super Contributor
timestamp: July 22, 2024, 09:13:28 pm
content: Quote from: gpr on July 22, 2024, 12:50:53 pmI'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 onemustonly 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.

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 22, 2024, 11:33:54 pm
content: Quote from: newbrain on July 21, 2024, 12:19:20 pmNo, 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.

author: gpr
author_rank: Contributor
timestamp: July 22, 2024, 11:48:32 pm
content: Quote from: newbrain on July 22, 2024, 09:13:28 pmYou 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)

author: nimish
author_rank: Regular Contributor
timestamp: July 28, 2024, 12:59:03 am
content: 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.

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 28, 2024, 07:37:47 am
content: Quote from: nimish on July 28, 2024, 12:59:03 amSo THAT is why Zephyr is in the latest Altera FPGA SoC ! (Intel bought Altera ) ....

author: yar
author_rank: Contributor
timestamp: July 30, 2024, 08:44:02 am
content: Quote from: Tation on July 20, 2024, 01:28:18 pmYes. 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.Quote