Usable in all but the tightest micro-controller environments, The focus is on the tiny-to-small, deeply embedded environment.

The goal is to provide implementations of most standard POSIX OS interfaces to support a rich, multi-threaded development environment for deeply embedded processors.

Fully scalable from tiny (8-bit) to moderate embedded (32-bit). Scalability with rich feature set is accomplished with: Many tiny source files, link from static libraries, highly configurable, use of weak symbols when available.

NuttX strives to achieve a high degree of standards compliance. The primary governing standards are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOS's are adopted for functionality not available under these standards or for functionality that is not appropriate for the deeply-embedded RTOS (such as fork()).

Because of this standards conformance, software developed under other standard OSs (such as Linux) should port easily to NuttX.

Fully pre-emptible, fixed priority and round-robin scheduling.

Non-restrictive BSD license.

The philosophy behind that NuttX is that lots of features are great... BUT also that if you don't use those features, then you should not have to pay a penalty for the unused features. And, with NuttX, you don't! If you don't use a feature, it will not be included in the final executable binary. You only have to pay the penalty of increased footprint for the features that you actually use.

Using a variety of technologies, NuttX can scale from the very tiny to the moderate-size system. I have executed NuttX with some simple applications in as little as 32Kb total memory (code and data). On the other hand, typical, richly featured NuttX builds require more like 64Kb (and if all of the features are used, this can push 100Kb).

One may be intimidated by the size NuttX source tree. There are hundreds of source files! How can that be a tiny OS? Actually, the large number of files is one of the tricks to keep NuttX small and as scalable as possible. Most files contain only a single function. Sometimes just one tiny function with only a few lines of code. Why?

• Static Libraries. Because in the NuttX build processed, objects are compiled and saved into static libraries (archives). Then, when the file executable is linked, only the object files that are needed are extracted from the archive and added to the final executable. By having many, many tiny source files, you can assure that no code that you do not execute is ever included in the link. And by having many, tiny source files you have better granularity -- if you don't use that tiny function of even just a few lines of code, it will not be included in the binary.

As mentioned above, the use of many, tiny source files and linking from static libraries keeps the size of NuttX down. Other tricks used in NuttX include:

• Configuration Files. Before you build NuttX, you must provide a configuration file that specifies what features you plan to use and which features you do not. This configuration file contains a long list of settings that control what is built into NuttX and what is not. There are hundreds of such settings (see the NuttX Porting Guide for a partial list that excludes platform specific settings). These many, many configuration options allow NuttX to be highly tuned to meet size requirements. The downside to all of these configuration options is that it greatly complicates the maintenance of NuttX -- but that is my problem, not yours.
• Weak Symbols The GNU toolchain supports weak symbols and these also help to keep the size of NuttX down. Weak symbols prevent object files from being drawn into the link even if they are accessed from source code. Careful use of weak symbols is another trick for keep unused code out of the final binary.

A user-mode port of NuttX to the x86 Linux/Cygwin platform is available. The purpose of this port is primarily to support OS feature development.

STATUS: Does not support interrupts but is otherwise fully functional.

TI TMS320C5471 (also called C5471 or TMS320DA180 or DA180). NuttX operates on the ARM7 of this dual core processor. This port uses the Spectrum Digital evaluation board with a GNU arm-elf toolchain* under Linux or Cygwin.

STATUS: This port is complete, verified, and included in the initial NuttX release.

NXP LPC214x. Support is provided for the NXP LPC214x family of processors. In particular, support is provided for the mcu123.com lpc214x evaluation board (LPC2148). This port also used the GNU arm-elf toolchain* under Linux or Cygwin.

STATUS: This port boots and passes the OS test (examples/ostest). The port is complete and verified. As of NuttX 0.3.17, the port includes: timer interrupts, serial console, USB driver, and SPI-based MMC/SD card support. A verified NuttShell (NSH) configuration is also available.

STMicro STR71x. Support is provided for the STMicro STR71x family of processors. In particular, support is provided for the Olimex STR-P711 evaluation board. This port also used the GNU arm-elf toolchain* under Linux or Cygwin.

STATUS: Coding is complete on the basic port (boot logic, system time, serial console), but no testing has been performed due to some problems I am having with my JTAG wiggler and OpenOCD on Linux.

TI TMS320DM320 (also called DM320). NuttX operates on the ARM9 of this dual core processor. This port uses the Neuros OSD with a GNU arm-elf toolchain* under Linux or Cygwin.

STATUS: The basic port (timer interrupts, serial ports, network, framebuffer, etc.) is complete. All implemented features have been verified with the exception of the USB device-side driver; that implementation is complete but completely untested.

PJRC 87C52 Development Board. This port uses the PJRC 87C52 development system and the SDCC toolchain under Linux or Cygwin.

STATUS: This port is complete but not stable with timer interrupts enabled. There seems to be some issue when the stack pointer enters into the indirect IRAM address space during interrupt handling. This architecture has not been built in some time will likely have some compilation problems because of SDCC compiler differences.

SH-1 SH7032. This port uses the Hitachi SH-1 Low-Cost Evaluation Board (SH1_LCEVB1), US7032EVB, with a GNU arm-elf toolchain* under Linux or Cygwin.

STATUS: This port is available as of release 0.3.18 of NuttX. The port is basically complete and many examples run correctly. However, there are remaining instabilities that make the port un-usable. The nature of these is not understood; the behavior is that certain SH-1 instructions stop working as advertised. This could be a silicon problem, some pipeline issue that is not handled properly by the gcc 3.4.5 toolchain (which has very limit SH-1 support to begin with), or perhaps with the CMON debugger. At any rate, I have exhausted all of the energy that I am willing to put into this cool old processor for the time being.

Renesas M16C/26 Microncontroller. This port uses the Renesas SKP16C26 Starter kit and the GNU M32C toolchain. The development environment is either Linux or Cygwin under WinXP.

STATUS: Initial source files released in nuttx-0.4.2. At this point, the port has not been integrated; the target cannot be built because the GNU m16c-elf-ld link fails with the following message:

m32c-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482

Where the reference line is:

/* If the symbol is out of range for a 16-bit address,
   we must have allocated a plt entry.  */
BFD_ASSERT (*plt_offset != (bfd_vma) -1);

No workaround is known at this time. This is a show stopper for M16C for the time being.

Zilog z16f Microncontroller. This port use the Zilog z16f2800100zcog development kit and the Zilog ZDS-II Windows command line tools. The development environment is Cygwin under WinXP.

STATUS: The initial release of support for the z16f was made available in NuttX version 0.3.7.

Zilog eZ80Acclaim! Microncontroller. There are two eZ80Acclaim! ports:

• One uses the ZiLOG ez80f0910200kitg development kit, and
• The other uses the ZiLOG ez80f0910200zcog-d development kit.

Both boards are based on the eZ80F091 part and both use the Zilog ZDS-II Windows command line tools. The development environment is Cygwin under WinXP.

STATUS: Integration and testing of NuttX on the ZiLOG ez80f0910200zcog-d is complete. The first integrated version was released in NuttX version 0.4.2 (with important early bugfixes in 0.4.3 and 0.4.4). As of this writing, that port provides basic board support with a serial console, SPI, and eZ80F91 EMAC driver.

Zilog Z8Encore! Microncontroller. This port uses the either:

• Zilog z8encore000zco development kit, Z8F6403 part, or
• Zilog z8f64200100kit development kit, Z8F6423 part

and the Zilog ZDS-II Windows command line tools. The development environment is Cygwin under WinXP.

STATUS: This release has been verified only on the ZiLOG ZDS-II Z8Encore! chip simulation as of nuttx-0.3.9.

Z80 Instruction Set Simulator. This port uses the SDCC toolchain under Linux or Cygwin (verified using version 2.6.0). This port has been verified using only a Z80 instruction simulator. That simulator can be found in the NuttX CVS here.

STATUS: This port is complete and stable to the extent that it can be tested using an instruction set simulator.

There are partial ports for the TI TMS320DM270 and for MIPS.

The is the most natural development environment for NuttX. Any version of the GCC/binutils toolchain may be used. There is a highly modified buildroot available for download from the NuttX SourceForge page. This download may be used to build a NuttX-compatible ELF toolchain under Linux or Cygwin. That toolchain will support ARM, m68k, m68hc11, m68hc12, and SuperH ports. The buildroot CVS may be accessed in the NuttX CVS.

Also very usable is the Linux environment using the SDCC compiler. The SDCC compiler provides support for the 8051/2, z80, hc08, and other microcontrollers. The SDCC-based logic is less well exercised and you will likely find some compilation issues if you use parts of NuttX with SDCC that have not been well-tested.

This combination works well too. It works just as well as the native Linux environment except that compilation and build times are a little longer. The custom NuttX buildroot referenced above may be build in the Cygwin environment as well.

I have never tried this combination, but it would probably work just fine.

This is a tougher environment. In this case, the Windows native toolchain is unaware of the the Cygwin sandbox and, instead, operates in the native Windows environment. The primary difficulties with this are:

• Paths. Full paths for the native toolchain must follow Windows standards. For example, the path /home/my\ name/nuttx/include my have to be converted to something like 'C:\cygwin\home\my name\nuttx\include' to be usable by the toolchain.

Fortunately, this conversion is done simply using the cygpath utility.

• Symbolic Links NuttX depends on symbolic links to install platform-specific directories in the build system. On Linux, true symbolic links are used. On Cygwin, emulated symbolic links are used. Unfortunately, for native Windows applications that operate outside of the Cygwin sandbox, these symbolic links cannot be used.

The NuttX make system works around this limitation by copying the platform specific directories in place. These copied directories make work a little more complex, but otherwise work well.

At present, only the Zilog Z16F, z8Encore, and eZ80Acclaim ports use a native Windows toolchain (the Zilog ZDS-II toolchain).

The primary environmental dependency of NuttX are (1) GNU make, (2) bash scripting, and (3) Linux utilities (such as sed). If you have other platforms that support GNU make or make utilities that are compatible with GNU make, then it is very likely that NuttX would work in that environment as well (with some porting effort). If GNU make is not supported, then some significant modification of the Make system would be required.