I think the best way to compare is trying NuttX and others RTOSes on some supported board (raspberry pi pico, esp32-devkit, stm32f4discovery etc). As rzr said NuttX is easier for people with Linux background, because it is Linux-like. So the way you mount a MMC/SDCard is the same, the way you search for devices using i2ctool is the same, etc.
I'm not sure I follow. Why would I want to "use" an mcu board the same way I use my linux desktop? It's not like I'm going to dynamically mount an SD card from a CLI for such an embedded device. Or that I would want to have a CLI at all. It is designed for early prototyping?
You don't have to mount it dynamically if you don't want. You can use it in a very static way, like your baremetal way to do things. But you can also have option to do it dynamically, case you have different SDCards with different binaries to load (yes, NuttX support dynamic ELF loading as well).
This is what I'm focusing on. I would say nuttX looks great if one is coming from the BSDs. I really want a development platform that is this documented.
All replacement start with the first entity using a new technology. Soon ESA, NASA, ISRO will start using it. China already uses it, the SPARC V8 port was done by them! ;-)
It is also quite odd how SiFive announced a new development board using a non-Intel chip and a year later than expected, when we were previously told it'd be an Intel chip.
NuttX worth considering if you're coming from Linux background, I liked it and related community, BTW they have a workshop later this year.
Back to the subject implementing drivers can be a good warmup exercise, you can get inspiration from hints I have shared:
https://rzr.github.io/rzr-presentations/docs/nuttx/
How does it compare to e.g. Zephyr or other RTOSes?
I think the best way to compare is trying NuttX and others RTOSes on some supported board (raspberry pi pico, esp32-devkit, stm32f4discovery etc). As rzr said NuttX is easier for people with Linux background, because it is Linux-like. So the way you mount a MMC/SDCard is the same, the way you search for devices using i2ctool is the same, etc.
I'm not sure I follow. Why would I want to "use" an mcu board the same way I use my linux desktop? It's not like I'm going to dynamically mount an SD card from a CLI for such an embedded device. Or that I would want to have a CLI at all. It is designed for early prototyping?
You don't have to mount it dynamically if you don't want. You can use it in a very static way, like your baremetal way to do things. But you can also have option to do it dynamically, case you have different SDCards with different binaries to load (yes, NuttX support dynamic ELF loading as well).
Exactly. You can prototype heavily and make sure peripherals, firmware programming, etc is working/to your advantage before doing any pcb work
That said bigger mcu,mpu +fpga type devboards will still absolutely price out hobbyists
The best description is UNIX like, because NuttX is POSIX based, while many RTOS aren't.
NuttX works great with RISC-V[0].
0. https://nuttx.apache.org/docs/latest/platforms/risc-v/index....
This is what I'm focusing on. I would say nuttX looks great if one is coming from the BSDs. I really want a development platform that is this documented.
Yes! People coming from Unix and Linux feel at home on NuttX! ;-)
This is what the ubiquitous (for commercial uses) PX4 flight control firmware uses.
I would really like to have RTEMS on a RPI, however it's most focused board's are "space stuff" like LEON Spark's
True, and NuttX is replacing RTEMS for space exploration as well: https://developer.sony.com/posts/apache-nuttx-powers-worlds-...
>True, and NuttX is replacing RTEMS for space exploration as well
Not really....one use-case = replacing? ;(
https://www.rtems.org/node/139
https://rtems-qual.io.esa.int/
All replacement start with the first entity using a new technology. Soon ESA, NASA, ISRO will start using it. China already uses it, the SPARC V8 port was done by them! ;-)
>Soon ESA, NASA, ISRO will start using it.
I really hope your in stock trading, you must be successful like hell with your crystal-ball ;)
Isn't LEON Spark deprecated in favor of RISC-V based LEON-V / NOEL?
Looks like Intel didn't get the memo yet
https://chipsandcheese.com/2024/04/22/intel-meteor-lakes-npu...
Intel and RISC-V at odds lately.
It is also quite odd how SiFive announced a new development board using a non-Intel chip and a year later than expected, when we were previously told it'd be an Intel chip.
Yeah your right, but i think for the next 15 years LEON 3 and 4 would still be the norm ;)
I just found the dev fpga board of Noel
https://www.gaisler.com/index.php/products/processors/noel-v...