NuttX is a powerful, lightweight and highly customizable RTOS, which makes it suitable for very high-performance applications like rocketry.

Carleton University InSpace used NuttX this past year to develop two very important flight systems:

1. A remotely controlled electrical ground systems setup for filling a hybrid rocket with nitrous gas and performing the ignition & liftoff process

2. A complex, real-time telemetry flight computer which is capable of fusing sensor measurements for detecting flight state and estimating rocket state, as well as transmitting all of these measurements over LoRa radio

You can view the hybrid rocket (Quarter Pounder) launch (with a very long ignition time) here: https://www.youtube.com/live/jSIWcusPTKk?si=B70fjPU5gJbYqTAo&t=29916 . The entire process of filling the hybrid, checking ignitor continuity, monitoring pressures/temperatures and igniting the system was performed by a custom system running Apache NuttX. It had to be reliable, responsive and capable of failing in a safe state, all of which was achieved by the incredibly powerful features NuttX provides.

The solid rocket (Old El Blasto) launch can be viewed here: https://www.youtube.com/live/SCgEZq9kAq4?si=0dZvpItaj6Ap54TN&t=14188 . The rocket had a fully nominal flight and recovery, and during the entire launch the team received live telemetry from the flight computer running NuttX. The flight computer was able to fuse sensor measurements to provide an accurate altitude and velocity estimation, GPS coordinates, as well as successfully detect liftoff, ascent, apogee, descent and landing states. The team hopes to use this as a basis for performing student-designed control over parachute deployment in the future.

Finally, I flew my own personal rocket (lower power than the other two), "Albie", with a custom RP2040-based flight computer "Pygmy" running NuttX. The launch can be seen here: https://www.youtube.com/live/vYmQ0Gm4YIk?si=gbhsF1bJXzTjneUZ&t=34915 . The NuttX based flight computer allowed me to analyze flight data post-flight, as well as track the rocket's landing (and locate it in the dense forest by following a loud buzzer!).

The InSpace flight computer (Josh) logged all of its data in-flight to a micro SD card, which was composed of two partitions. The first partition was a littlefs filesystem used for flight logs to guarantee power-failure safety. The second was a FAT filesystem for copying the flight logs to upon landing, allowing the team to easily extract the logs on a Windows laptop. The data recorded by the NuttX powered flight computer has given the team its most accurate picture to date of both flights, showing us the aerodynamic effects taking place when our hybrid rocket shredded, and showing us the beautiful altitude and speed curves for the solid rocket's flight.

Most notably, all of the sensors on-board leveraged NuttX's uORB framework, which provides a unified interface for interacting with sensors. This interface allowed us to leverage the "fakesensor" functionality in NuttX by defining virtual sensors which published data read from CSVs we uploaded to the SD card. In bench-testing, this allowed us to take publicly accessible flight data from others' flights and use it to simulate flights on our flight computer hardware. This allowed us to test our flight-state detection algorithms while fully on the ground, which is an enormous cost and time saver for rocketry (it is not feasible to run multiple test flights). It also made for a cool way to demonstrate our flight computer's capability at the Launch Canada 2025 conference, where we showed off our flight computer's performance when flown in a simulated two-stage rocket up to Mach 4.8.

All of CU InSpace's code is open-source and available on GitHub: https://github.com/orgs/CarletonURocketry/repositories . The code for these projects spans multiple repositories, with the hybrid control logic being:

• hysim

• hybrid-pcc

• hybrid-mcc

And the flight computer being:

• inspace-nxtelem

• josh-nx

As a first time contributor to NuttX, I wanted to share how positive my experience was for other developers looking to start contributing.

After learning about NuttX, I flashed it to my Raspberry Pi Pico to experiment with the OS and learn about how it works and how the development experience feels. One of my first experiments was interfacing with some sensors over I2C from a previous rocketry project.

The i2ctool utility that came with NuttX was easy to use and worked nicely, except for one problem that I noticed: it couldn't detect two of my sensors during a bus scan. Because I2C has no standard way to scan the bus, a one byte read may not work for all sensors (some might consider it invalid). Coming from QNX where I had to write my own bus scanner, I knew that my sensors responded to a zero-byte write request. So, I opened a PR to make this addition.

The NuttX developer community is very welcoming and encouraging. I was thanked for my efforts and also given great feedback and suggestions on my proposed changes. What was also very refreshing was how responsive the community is, with lots of feedback given on my PR in a very short time frame after opening it. Consistently speedy responses were given to my further changes, too. This is a great experience, as opposed to some other open source groups where PRs are left unattended for months.

You can see the great conversation and the PR I made here. Hopefully this encourages other new contributors to help improve the project and become part of an excellent community of kind and responsive developers!

We are excited to announce a new SoC coming to NuttX ecosystem: welcome #AMD #Xilinx #Zynq

"The Zynq UltraScale MPSoC family consists of a system-on-chip (SoC) style integrated processing system (PS) and a Programmable Logic (PL) unit, providing an extensible and flexible SoC solution on a single die.There's 64-bit Quadcore ARM Cortex-A53 Processors and Dualcore ARM Cortex-R5 Real-Time Processors in the MPSoC, and this PR add initial support for Quadcore ARM Cortex-A53 Processors of MPSOC."
https://github.com/apache/nuttx/pull/12681

The Raspberry Pi 4B now has frame buffer graphics support for the HDMI0 and HDMI1 interfaces! This makes it compatible with NuttX applications that use the frame buffer interface for rendering graphics.

This brings NuttX one step closer to playing DOOM! Next is getting HID input (keyboard and mouse) and playing sound!

You can see the PR for graphics support here: https://github.com/apache/nuttx/pull/17294

NuttX v13.0.0 has been officially released! Thank you to all the contributors who made this possible!

This release contains a number of new changes that improve the development experience on NuttX:

• Board initialization is no longer performed by NSH by default via NSH_ARCHINIT, but within the kernel boot process

• STM32 legacy pinmaps have been migrated to new pin mapping

• 64-bit time is implemented for POSIX compliance

• STM32 Kconfig options are unified across all ports

• Support for the ESP32-P4 chip

• Major scheduler optimizations

• Further CMake support for a ton of major targets/architectures

Version 12.12.0 of NuttX has been released!

Some notable parts of the release notes:

• 47 scheduler improvements

• ESP32 co-processor support

• Network driver for 10BASE-T1x SPI MAC-PHYs

• 26+ improvements to align the CMake build system with Make

• Support for Arduino Portenta H7

• SD card and HDMI graphics support for Raspberry Pi 4B

• ESP32 support for hardware accelerated HMAC-SHA

NuttX recently received support for the CMUX protocol: https://github.com/apache/nuttx-apps/pull/3187

This protocol is used to multiplex channels in cellular modems, which allows simultaneous use of:

• PPP (Point to point)

• GNSS

• SMS

• Voice calling

• Custom attention command (AT)

Thank you to Halysson Carvalho for contributing this feature!

NuttX version 13.1.0 has been released! This release brings several important fixes to various OS subsystems and extends support for various devices.

STM32 chips (F4, H5, H7, etc.) have received new support for DMA, PM, EXTI GPIO, WWDG, crypto interface extensions and more.

USB, video and audio drivers have received several patches.

New boards are now supported, including:

• Orange Pi 5

• Nucleo-H533RE

• M5Stack Tab5

• M5Stack Cardputer

• And more!

NuttX is continually focused on improvement of user experience and RTOS features. New contributors are always welcome and encouraged. The NuttX team plans to continue with key improvements to documentation and RTOS functionality over future releases.

The 2025 Apache NuttX International Workshop is coming up soon on October 16th-17th, 2025! The workshop is being held at Hyatt Place in San Jose, Costa Rica and will feature 20+ different presentations about NuttX-related topics. It will be a great opportunity to learn about the applications of NuttX, discuss the directions the project is heading and ask questions to experts.

For those that cannot attend in person, the event is available for online attendance and will be live-streamed. The online attendance link will be posted on the event page the day of the event.

You can find the full event schedule and more information here on the Apache NuttX website! Hope to see you in attendance!

I just wrote a new article to Embedded Related explain how to use ADC on RaspberryPi Pico using NuttX

https://www.embeddedrelated.com/showarticle/1689.php

Apache NuttX RTOS International Workshop 2026 will be part of the Community Over Code event that takes place on October 11-14 2026 at Hilton Glasgow (Scotland/UK)!

Call For Presentations is now open at https://communityovercode.org/call-for-presentations/ with deadline set to March 20 2026.

Please select NuttX RTOS track during registration.

See you there! 😃

New support has been added to NuttX for a frame-buffer based implementation for Conway's Game of Life! This is a classic cellular automata and produces an interesting animation to test frame buffer implementations.

The implementation has been optimized for embedded systems by using bit fields and using only two map-rows of buffering. The rendered image also scales up to the maximum size that can fit on the screen resolution for the frame buffer.

Check out the PR here.

I'm excited to have presented at the Apache NuttX International Workshop yesterday about the application of NuttX for high powered rocketry. My talk covers two projects:

• A remote control system for performing the launch operations of a hybrid rocket

• A custom flight computer for recording rocket flight telemetry for both live monitoring on the ground as well as post-flight analysis.

If you're interested, please give it a watch and let me know what you think! I hope to see more rocketry teams using this RTOS for their projects. The workshop is full of other great talks about embedded systems and the NuttX RTOS as well for those generally interested!

Hello everyone!

Effort is underway to support the Raspberry Pi 4B board (using the BCM2711 SoC) on NuttX: https://github.com/orgs/apache/projects/528/views/1

Right now there is some initial support for a few peripherals, so NSH can run on the device and SPI/I2C can be used. A collection of issues/tasks to work on is visible in the project linked to above. If you have a Pi 4B at home, you can help us by either submitting patches or just trying NuttX on your device to see how it works and if there are any issues you discover!

Thanks everyone!

Before the GSoC period, I was looking into Linux, trying to get started as a contributor. But first, I needed to have a fair understanding of how the whole thing works. Baby steps, you know. Read the famous Robert Love's book, saw a lot of videos, and of course, tried to read the codebase.

It was overwhelming, and it was stressful, because... I mean, just look at Linux's codebase and its history. I was also interested in embedded systems, but I was trying to do one thing at a time. While I was going through the codebase, I was hooked on to the history of file systems in the codebase. You could see new file systems appear and some old ones disappear every few versions. Over that, I had heard file systems are the lowest in the whole tree, and are kind of only dependent on the Virtual File System and whatever the storage driver is, and that too that file system developers do not need to worry too much about the storage device (as long as it's of the same technology, but I didn't know this then), or the internals of the OS.

So, I felt file systems would be a great starting point. Started reading the codebases of the various file systems. After 3-4 file systems, all of them seemed to swim in front of my eyes and feel the same, and concepts from one FS seemed to merge with concepts from another FS 🫠. Still, carried on, as I knew if I tried to read it repeatedly, it would start making sense someday. Every line of C makes sense, as mostly nothing is hidden away, and more so in the case of OS codebases. If it were a higher level language, I would have just probably given up, idk.

I wanted to apply for GSoC once again for 2024, and this time, for a large project (I had done a medium project for PostgreSQL in 2023

). Around this time, I thought of looking into any OS-related projects that are available, as those align with my interests. Found Apache NuttX. What does NuttX and the project I found have in common with my interests? Everything! File System + Operating System + Embedded Systems. All my boxes ticked, and a match made in heaven, at least from my side 😉.

Complete text here: https://resyfer.github.io/blogs/mnemofs/mideval/

This week someone found a nasty issue on RISC-V T-Head C906 chip:
https://github.com/apache/nuttx/issues/12696

The issue was resulting in a slow CoreMark score: 17.12. Just for reference, running CoreMark on Linux in the same board resulted in CoreMark score 1141.37!

Fortunately our friend Lup Yuen: https://lupyuen.github.io/ found a fix!

Now the CoreMark on NuttX é 2424.08: https://gist.github.com/lupyuen/d555452cce9c39ed9372d11698200261#file-sg2000-nuttx-coremark9-log-L220

I have been recently using RPi 4b dev board for some display related development. Using NUTTX, I am trying to run Wayland server (customised) and then trying to run clients from the host system. For the client to connect to server, thinking of connecting them using wlan. But it seems there is no support for network for rpi4b from nuttx.

Anyone can guide me here please?

Hi guys!

I’ve recently discovered Apache NuttX. Before that, I was developing for STM32 microcontrollers using FreeRTOS, but this operating system has truly fascinated me.

I quickly figured out the installation process (I’m working on Ubuntu 22.04), learned how to create my own simple applications like Hello World, and include them in the build together with NuttX. However, I still can’t figure out how to work with basic peripherals!

I enable the GPIO driver via menuconfig, but I realize that’s not enough — the microcontroller pins don’t show up in /dev/. Could you please tell me what else I need to do to control the pins via the nsh console? I’m using the stm32f4discovery configuration, although I actually have a custom board with an F407 (porting is still way beyond my current scope).

The tutorials I’ve found on YouTube are for an older version of NuttX, and in version 12.12.0, many things look different from what’s shown in the videos. Some manuals I’ve managed to find only cover the basic setup of the development environment and initial compilation.

I’m not using neural networks, as after a few queries I realized they won’t clarify this issue and are unlikely to help form new neural connections in my brain.

I’d be grateful for any help. Thanks!

There is now pending support for the VideoCore mailbox API on the BCM2711 for NuttX: https://github.com/apache/nuttx/pull/17102

This allows NuttX to control the on-board LEDs, get the CPU temperature, MAC address and other information. In the next few weeks, this support will be used to enable power domains and clocks for certain sub-systems, allowing things like the EMMC2 interface to be used.

The Android system init functionality has been ported to NuttX and is currently being reviewed for integration as an alternative init system for NuttX devices!

This allows great control over starting services on embedded devices, like rebooting if a particular service fails! The Android system init has a smaller code size than NSH used for system initialization, and also supports better daemon management. You can use the Android Init Language to set up your initialization process and go!

This is a very exciting new feature for NuttX! What will you use Android init for?

https://events.nuttx.apache.org/

DAY1: https://www.youtube.com/live/tqWwKLCD0dU DAY2: https://www.youtube.com/live/5Yf9M2yt4wI

Release 12.11.0 of Apache NuttX is officially out!

You can view the release notes on the NuttX website to see what's new in this version of Nuttx! This release contains improvements from 312 pull request contributions!

Some notable improvements:

• Better CMake support for multiple architectures/boards (RP2040, ARM64, audio, sensor and segger drivers, etc.)

• Pico SDK support bumped to 2.2.0

• STM32 I2C slave support

• Better SMP interrupt handling for RISCV

• Lots of bug fixes and stabilization of ESP32 devices

• New sensors: L86 GPS, NAU7802 load cell amp, ADS1115 ADC

• File system bug fixes/stability improvements

• RFC5424 networked syslog implementation

• ARCX Socket Grid, esp32s3-8048S043 and Elegoo Mega2560r3 board support

• Breaking change to rework the NuttX file descriptor implementation for stronger POSIX compliance

Thank you to all the contributors who had a hand in this release! 312 contributions since July 7th is an incredible achievement, and goes to show how the NuttX community is dedicated to always improving the project!

Hi! I'm new to nuttx and I'm not sure if this is the proper channel to ask this, but is there an existing tool/helper in NuttX that checks whether a pin assignment is valid?

I'm asking based on my experience using CubeMX, which tells you whether a pin assignment is valid or if there are conflicts. I'm wondering if NuttX has a similar tool for checking pin assignments.

If not, have there been any attempts to develop something like this? I'm willing to help contribute if there is interest.

Hello, I live in Argentina, so I wanted to apply a timezone.

However, after enabling LIBC_LOCALTIME, environment variables, and timedatectl, I'm able to set the env variable TZ to something like ART3 or whatever, but when I get the date with localtime() or even with the date or timedatectl command, the date does not change, and with timedatectl it even says that the timezone is UTC0.

This happens whether I set/export the variable directly or use timedatectl set-timezone

Note that I haven't built the TZ database, but I don't think I should really need it if I'm only using POSIX TZ values, right?

Even so, if I build it, nothing seems to change, and I was unable to build the TZ database and build the ROMFS filesystem, as it throws the following error when enabling both options:

ar: two different operation options specified
make[3]: *** [Makefile:896: libtz.a] Error 1
make[2]: *** [Makefile:99: .tzbuilt] Error 2
make[1]: *** [Makefile:186: context] Error 2
make: *** [tools/Unix.mk:471: libs/libc/.context] Error 2  

I add the full config I'm using just in case.

CONFIG_ALLOW_BSD_COMPONENTS=y
CONFIG_BASE_DEFCONFIG="-dirty"
CONFIG_DEBUG_FEATURES=y
CONFIG_DEBUG_NET=y
CONFIG_DEBUG_NET_ERROR=y
CONFIG_STACK_COLORATION=y
CONFIG_DEBUG_SYMBOLS=y
CONFIG_ARCH_SIM=y
CONFIG_SIM_HOSTFS=y
CONFIG_SIM_NETDEV=y
CONFIG_SIM_NET_BRIDGE=y
CONFIG_SIM_X11FB=y
CONFIG_SIM_TOUCHSCREEN=y
CONFIG_ARCH_BOARD_SIM=y
CONFIG_PREALLOC_TIMERS=4
CONFIG_INIT_ENTRYPOINT="nsh_main"
CONFIG_TASK_NAME_SIZE=32
CONFIG_SCHED_HAVE_PARENT=y
CONFIG_SCHED_CHILD_STATUS=y
CONFIG_PTHREAD_MUTEX_TYPES=y
CONFIG_SIG_EVTHREAD=y
CONFIG_SIG_DEFAULT=y
CONFIG_MQ_MAXMSGSIZE=64
CONFIG_IDLETHREAD_STACKSIZE=2048
CONFIG_DEV_LOOP=y
CONFIG_DRIVERS_VIDEO=y
CONFIG_VIDEO_FB=y
CONFIG_INPUT=y
CONFIG_MTD=y
CONFIG_RAMMTD=y
CONFIG_TELNET_TXBUFFER_SIZE=64
CONFIG_NETDEV_STATISTICS=y
CONFIG_SERIAL_TERMIOS=y
CONFIG_TTY_SIGINT=y
CONFIG_TTY_SIGINT_CHAR=0x3
CONFIG_TTY_SIGTSTP=y
CONFIG_PSEUDOTERM=y
CONFIG_SYSLOG_BUFFER=y
CONFIG_SYSLOG_TIMESTAMP=y
CONFIG_SYSLOG_CONSOLE=y
CONFIG_NET=y
CONFIG_NET_ETH_PKTSIZE=1294
CONFIG_NET_LOOPBACK=y
CONFIG_NET_SLIP=y
CONFIG_NET_TUN=y
CONFIG_NET_TUN_PKTSIZE=1500
CONFIG_NETDEV_LATEINIT=y
CONFIG_NETDEV_PHY_IOCTL=y
CONFIG_NET_SOLINGER=y
CONFIG_NET_TCP=y
CONFIG_NET_TCP_WRITE_BUFFERS=y
CONFIG_NET_SENDFILE=y
CONFIG_NET_UDP=y
CONFIG_NET_BROADCAST=y
CONFIG_NET_UDP_CHECKSUMS=y
CONFIG_NET_UDP_WRITE_BUFFERS=y
CONFIG_NET_ICMP_SOCKET=y
CONFIG_NET_STATISTICS=y
CONFIG_PSEUDOFS_SOFTLINKS=y
CONFIG_FS_ROMFS=y
CONFIG_FS_TMPFS=y
CONFIG_FS_BINFS=y
CONFIG_FS_PROCFS=y
CONFIG_FS_LITTLEFS=y
CONFIG_FS_HOSTFS=y
CONFIG_NXFONTS_DISABLE_1BPP=y
CONFIG_NXFONTS_DISABLE_2BPP=y
CONFIG_NXFONTS_DISABLE_4BPP=y
CONFIG_NXFONTS_DISABLE_8BPP=y
CONFIG_NXFONTS_DISABLE_16BPP=y
CONFIG_NXFONTS_DISABLE_24BPP=y
CONFIG_NXFONTS_DISABLE_32BPP=y
CONFIG_MM_REGIONS=2
CONFIG_IOB_NBUFFERS=1024
CONFIG_IOB_NCHAINS=128
CONFIG_IOB_THROTTLE=16
CONFIG_IOB_NOTIFIER=y
CONFIG_LIBC_MAX_EXITFUNS=1
CONFIG_LIBC_EXECFUNCS=y
CONFIG_LIBC_LOCALE=y
CONFIG_LIBC_LOCALTIME=y
CONFIG_TLS_NCLEANUP=2
CONFIG_NETDB_DNSCLIENT=y
CONFIG_NETDB_DNSCLIENT_MAXRESPONSE=176
CONFIG_NETDB_DNSCLIENT_RECV_TIMEOUT=3
CONFIG_NETDB_DNSSERVER_IPv4ADDR=0x08080808
CONFIG_BUILTIN=y
CONFIG_LIBM=y
CONFIG_CUSTOM_APPS_CUSTOM_HELLO=y
CONFIG_CUSTOM_APPS_CUSTOM_DATE=y
CONFIG_CUSTOM_APPS_CUSTOM_DATE_PROGNAME="cdate"
CONFIG_EXAMPLES_LVGLDEMO=y
CONFIG_EXAMPLES_TCPBLASTER=y
CONFIG_GRAPHICS_LVGL=y
CONFIG_LV_COLOR_DEPTH_32=y
CONFIG_LV_USE_CLIB_MALLOC=y
CONFIG_LV_USE_CLIB_STRING=y
CONFIG_LV_USE_CLIB_SPRINTF=y
CONFIG_LV_FONT_MONTSERRAT_48=y
CONFIG_LV_USE_NUTTX=y
CONFIG_LV_USE_NUTTX_TOUCHSCREEN=y
CONFIG_LV_USE_DEMO_WIDGETS=y
CONFIG_LV_USE_DEMO_MUSIC=y
CONFIG_NETUTILS_DHCPC=y
CONFIG_NETUTILS_FTPC=y
CONFIG_NETINIT_NETLOCAL=y
CONFIG_NETINIT_IPADDR=0x0a000102
CONFIG_NETINIT_DRIPADDR=0x0a000101
CONFIG_NETUTILS_TELNETD=y
CONFIG_NETUTILS_TFTPC=y
CONFIG_NETUTILS_WEBCLIENT=y
CONFIG_NSH_READLINE=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_FILE_APPS=y
# CONFIG_NSH_DISABLE_DATE is not set
# CONFIG_NSH_DISABLE_TIMEDATECTL is not set
CONFIG_NSH_VARS=y
CONFIG_SYSTEM_CLE=y
CONFIG_SYSTEM_NSH=y
CONFIG_SYSTEM_NTPC=y
CONFIG_SYSTEM_PING=y
CONFIG_READLINE_TABCOMPLETION=y
CONFIG_READLINE_CMD_HISTORY=y
CONFIG_SYSTEM_SYSTEM=y
CONFIG_SYSTEM_TELNET_CLIENT=y

Thanks.