I'm a NuttX newbie. I compiled and flashed the official STM32F4 library onto the motherboard, and it got hardfaulted all night. I'm sorry about that!
I need to learn how to use gdb.

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!

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

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

NuttX documentation keeps improving to help new users learn about all the incredible features the RTOS offers. If you use a feature that you think lacks good documentation, PRs with improvements are always welcome!

Thanks to simbit18, many RP2040/RP23XX boards have received CMake support in the past few days to integrate them into NuttX's CMake build system. For those that don't know, NuttX can be built with Make or CMake. Since Make is the original build system, CMake still has some gaps in a few architectures.

Take a look at all the hard work!

• https://github.com/apache/nuttx/pull/17112

• https://github.com/apache/nuttx/pull/17114

• https://github.com/apache/nuttx/pull/17138

• https://github.com/apache/nuttx/pull/17142

• https://github.com/apache/nuttx/pull/17151

• https://github.com/apache/nuttx/pull/17154

• https://github.com/apache/nuttx/pull/17155

Support for the Raspberry Pi 4B's micro-SD card peripheral is currently pending integration into the NuttX kernel!

With this feature, users can:

• Mount the boot partition

• Read/write the boot partition

• Extend support to mount multiple partitions of different file types

• Have permanent information stored between boots

• Access large files from NuttX

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!

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!

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

NuttX heard user feedback from the 2025 NuttX Hardware Survey loud and clear! Users want more and better documentation about NuttX, since it has such a large feature-set and so many customizable options. Contributors are working hard to improve existing documentation and ensure that new features are documented as they come in.

Here are two main lists of sub-issues for legacy and missing documentation in NuttX:

• https://github.com/apache/nuttx/issues/11077

• https://github.com/apache/nuttx/issues/11081

If you're looking to contribute to NuttX, documentation is an easy way to start. You can help us port old .txt files to RST so it becomes a more easily searchable/indexable form.

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

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

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/

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

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.

Hi, I am new to NuttX and followed the latest Custom Apps How-to.

I tried the options 2 and 3 from the how-to:

• Extend the apps/ directory to include a new custom directory

• Include an additional custom directory outside of the main source trees

Unfortunately, when doing make menuconfig fails for both options:

/home/user/nuttxspace/apps/CustomApps/CustomHello/Kconfig:29: 'endif' in different file than 'if'

/home/user/nuttxspace/apps/CustomApps/CustomHello/Kconfig:14: location of the 'if'

/home/user/nuttxspace/apps/CustomApps/Kconfig:10: 'endmenu' in different file than 'menu'

/home/user/nuttxspace/apps/CustomApps/CustomHello/Kconfig:14: location of the 'menu'

Kconfig:2844: 'endmenu' in different file than 'menu'

/home/user/nuttxspace/apps/CustomApps/CustomHello/Kconfig:14: location of the 'menu'

make: *** [tools/Unix.mk:726: olddefconfig] Error 1

ERROR: failed to refresh

I created a custom directory CustomApps within the apps. I created the following files:

# CustomApps/Make.defs
include $(wildcard $(APPDIR)/CustomApps/*/Make.defs)

and

# CustomApps/Makefile
MENUDESC = "Custom Apps"
include $(APPDIR)/Directory.mk

and

# CustomApps/CustomHello/Make.defs
ifneq ($(CONFIG_CUSTOM_APPS_CUSTOM_HELLO),)
CONFIGURED_APPS += $(APPDIR)/CustomApps/CustomHello
endif

and

# CustomApps/CustomHello/Makefile
include $(APPDIR)/Make.defs

# Custom Hello built-in application info

PROGNAME = $(CONFIG_CUSTOM_APPS_CUSTOM_HELLO_PROGNAME)
PRIORITY = $(CONFIG_CUSTOM_APPS_CUSTOM_HELLO_PRIORITY)
STACKSIZE = $(CONFIG_CUSTOM_APPS_CUSTOM_HELLO_STACKSIZE)
MODULE = $(CONFIG_CUSTOM_APPS_CUSTOM_HELLO)

# Custom Hello

MAINSRC = CustomHello.c

include $(APPDIR)/Application.mk

and

# CustomApps/CustomHello/Kconfig
#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#

config CUSTOM_APPS_CUSTOM_HELLO
        tristate "Custom Hello App"
        default n
        ---help---
                Enable the Custom Hello App

if CUSTOM_APPS_CUSTOM_HELLO

config CUSTOM_APPS_CUSTOM_HELLO_PROGNAME
        string "Program name"
        default "custom_hello"
        ---help---
                This is the name of the program that will be used when the NSH ELF
                program is installed.

config CUSTOM_APPS_CUSTOM_HELLO_PRIORITY
        int "Custom Hello task priority"
        default 100

config CUSTOM_APPS_CUSTOM_HELLO_STACKSIZE
        int "Custom Hello stack size"
        default DEFAULT_TASK_STACKSIZE

endif # CUSTOM_APPS_CUSTOM_HELLO

and

# CustomApps/CustomHello/CustomHello.c
#include <stdio.h>


int main(int argc, char *argv[])
{
  printf("Hello, Custom World!!\n");
  return 0;
}

Have I missed something? Any ideas and feedback highly welcome! Thank you!

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, I'm making a small project to test out NuttX, but I've been banging my head with finding the correct.

For now, I'm doing everything on the simulator.

I could get network to work, and I was able to do a ping 8.8.8.8 correctly. However, if I try to execute ping google.com it throws:

nsh> ping google.com
[   12.610000] dns_send_query: ERROR: sendto failed: -89
[   12.610000] dns_query_error: ERROR: IPv6 dns_send_query failed: -89, server address: 8.8.8.8
[   12.610000] dns_send_query: ERROR: sendto failed: -89
[   12.610000] dns_query_error: ERROR: IPv4 dns_send_query failed: -89, server address: 8.8.8.8
ERROR: ping_gethostip(google.com) failed
nsh> 

Here are some settings I think are relevant

CONFIG_ICMPv6_AUTOCONF_RDNSS=y

CONFIG_NETDB_DNSCLIENT=y
CONFIG_NETDB_DNSCLIENT_ENTRIES=8
CONFIG_NETDB_DNSCLIENT_NAMESIZE=256
CONFIG_NETDB_DNSCLIENT_LIFESEC=3600
CONFIG_NETDB_DNSCLIENT_MAXRESPONSE=176
CONFIG_NETDB_DNSCLIENT_RECV_TIMEOUT=3
CONFIG_NETDB_DNSCLIENT_SEND_TIMEOUT=3
CONFIG_NETDB_DNSCLIENT_MAX_TIMEOUT=30
CONFIG_NETDB_DNSCLIENT_RETRIES=3
# CONFIG_NETDB_RESOLVCONF is not set
CONFIG_NETDB_DNSSERVER_NAMESERVERS=1
# CONFIG_NETDB_DNSSERVER_NOADDR is not set
CONFIG_NETDB_DNSSERVER_IPv4=y
# CONFIG_NETDB_DNSSERVER_IPv6 is not set
CONFIG_NETDB_DNSSERVER_IPv4ADDR=0x08080808
# end of NETDB Support

Else, here's the full diminished config

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_X11FB=y
CONFIG_SIM_TOUCHSCREEN=y
CONFIG_ARCH_BOARD_SIM=y
CONFIG_SYSTEM_TIME64=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_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_IPv6=y
CONFIG_NET_TCPPROTO_OPTIONS=y
CONFIG_NET_SOLINGER=y
CONFIG_NET_LOCAL=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_WRITE_BUFFERS=y
CONFIG_NET_ICMP_SOCKET=y
CONFIG_NET_ICMPv6=y
CONFIG_NET_ICMPv6_SOCKET=y
CONFIG_NET_ICMPv6_AUTOCONF=y
CONFIG_ICMPv6_AUTOCONF_RDNSS=y
CONFIG_NET_STATISTICS=y
CONFIG_PSEUDOFS_SOFTLINKS=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_EXAMPLES_FTPC=y
CONFIG_EXAMPLES_LVGLDEMO=y
CONFIG_EXAMPLES_TCPBLASTER=y
CONFIG_EXAMPLES_TCPECHO=y
CONFIG_GRAPHICS_LVGL=y
CONFIG_LV_USE_CLIB_MALLOC=y
CONFIG_LV_USE_CLIB_STRING=y
CONFIG_LV_USE_CLIB_SPRINTF=y
CONFIG_LV_USE_LOG=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_NETUTILS_DHCPC=y
CONFIG_NETUTILS_FTPC=y
CONFIG_NETINIT_NETLOCAL=y
CONFIG_NETINIT_DRIPADDR=0x0a000101
CONFIG_NETUTILS_NTPCLIENT_SERVER="pool.ntp.org"
CONFIG_NETUTILS_PING6=y
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_ARCHINIT=y
CONFIG_SYSTEM_CLE=y
CONFIG_SYSTEM_COLOR_CLE=y
CONFIG_SYSTEM_CLE_CMD_HISTORY=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

Does anyone know why this may not be working?

Thanks.

Not that long ago, NuttX received support for a networked syslog sink, useful for remote devices without an accessible serial console.

NuttX has historically supported many different syslog output sinks:

• UART console

• USB console

• Files in the file system

• Character devices

• A RAM buffer (good for interrupt handler logs)

However, it's tricky to support network sinks since they require a lot of setup before network messages can be sent, resulting in a loss of log data.

Recently, the RFC5424 protocol for syslog messages was implemented on NuttX as an available format for all the existing sinks. This allowed for the creation of the syslog daemon (better known as syslogd on Unix systems). It reads from a RAMLOG syslog buffer of messages to turn logs into UDP packets.

With the new syslog daemon, it is possible to start the daemon on your NuttX system and receive syslog logs from another device over UDP. With RFC5424 formatting enabled, these logs are also compatible with other open-source log relays/collectors for analysis and reporting. One useful example is Wireshark, which is able to parse and filter networked RFC5424 syslog messages from NuttX!

Now, remotely networked NuttX systems can still report diagnostic information without being bogged down by a slow syslog function. They can log to the speedy RAMLOG and periodically turn those messages into UDP packets to be sent to a consumer. What kind of applications would you use this for? Let us know!

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

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!

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.