Electronics > Microcontrollers
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:
--- Quote from: SiliconWizard on July 20, 2024, 10:17:02 pm ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version