NuttX Documentation

NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOS’s (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).

Where to start

Getting Started

Install the toolchain, build for a board, get a shell. Start here if you have never built NuttX.

Getting Started
Supported Platforms

Every architecture, chip and board NuttX runs on. Start here if you have hardware in your hand.

Supported Platforms
Guides

How to do a particular thing: port, write a driver, debug. Start here when you know what you want to build.

Guides

Understanding the system

OS Design

How NuttX is built, subsystem by subsystem.

OS Design
API Reference

The POSIX and NuttX calls an application may make.

API Reference
Applications

The programs that ship with NuttX, from NSH onwards.

Applications

Working on NuttX

Developing NuttX

Getting a change accepted, the build system, porting, testing.

Developing NuttX
About

Questions, vocabulary, security reports, release notes.

About

How this documentation is organised

Four ideas decide where anything goes. They are written down here because knowing them turns “where do I look?” into a question with an answer – and, for anyone writing documentation, “where do I put this?” as well.

The sections follow what you are doing, not what NuttX contains. Arriving, finding your hardware, doing a task, understanding a subsystem, looking up a call: those are different activities, and each has a section. Guides comes before OS Design on purpose, because people want something running before they want to know how the scheduler works.

Three different questions, three different sections. It is the same subject seen three ways, and mixing them is what makes documentation hard to search:

Section

Answers

For example

Guides

How do I do X?

How to mount a ROMFS image at /etc

OS Design

How does X work?

How the scheduler picks the next thread

API Reference

What may I call?

What sched_setscheduler() takes and returns

OS Design follows the source tree. Each top level directory of NuttX – sched/, fs/, net/, mm/, drivers/ – is a section, and each subsystem is described once, going from what it is, to how it works, to the interfaces it offers. That is why there is one page about SMP rather than three, and why a contributor knows which page to add to.

What can be derived is derived, and checked. Board pages, the architecture and chip each one is filed under, and the tags that let you search for them all come from the source tree rather than being typed by hand, and the build fails when the two disagree. A page describing a board that no longer exists, or a board with no page, does not survive the next pull request.

Note

Something wrong on a page, or missing? The documentation lives in the same repository as the code, and every page has an Edit on GitHub link at the top right. See Documentation for how to build it locally.