2c1b9f54e9
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@1814 42af7a65-404d-4744-a932-0658087f49c3
2531 lines
91 KiB
HTML
2531 lines
91 KiB
HTML
<html>
|
|
<head>
|
|
<title>NuttX Porting Guide</title>
|
|
<meta name="author" content="Gregory Nutt">
|
|
</head>
|
|
|
|
<body background="backgd.gif">
|
|
<hr><hr>
|
|
<table width ="100%">
|
|
<tr align="center" bgcolor="#e4e4e4">
|
|
<td>
|
|
<h1><big><font color="#3c34ec">
|
|
<i>NuttX RTOS Porting Guide</i>
|
|
</font></big></h1>
|
|
<p>Last Updated: May 22, 2009</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<hr><hr>
|
|
|
|
<table width ="100%">
|
|
<tr bgcolor="#e4e4e4">
|
|
<td>
|
|
<h1>Table of Contents</h1>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<ul>
|
|
<a href="#Introduction">1.0 Introduction</a><br>
|
|
<a href="#DirectoryStructure">2.0 Directory Structure</a>
|
|
<ul>
|
|
<a href="#DirStructDocumentation">2.1 Documentation</a></br>
|
|
<a href="#DirStructArch">2.2 arch/</a>
|
|
<ul>
|
|
<a href="#archdirectorystructure">2.2.1 Subdirectory Structure</a><br>
|
|
<a href="#summaryofarchfiles">2.2.2 Summary of Files</a><br>
|
|
<a href="#supportedarchitectures">2.2.3 Supported Architectures</a>
|
|
</ul>
|
|
<a href="#DirStructConfigs">2.3 configs/</a>
|
|
<ul>
|
|
<a href="#configsdirectorystructure">2.3.1 Subdirectory Structure</a><br>
|
|
<a href="#summaryofconfigfiles">2.3.2 Summary of Files</a>
|
|
<ul>
|
|
<a href="#boardlogic">2.3.2.1 Board Specific Logic</a><br>
|
|
<a href="#boardconfigsubdirs">2.3.2.2 Board Specific Configuration Sub-Directories</a>
|
|
</ul>
|
|
<a href="#supportedboards">2.3.3 Supported Boards</a>
|
|
</ul>
|
|
<a href="#DirStructDrivers">2.4 drivers/</a><br>
|
|
<a href="#DirStructExamples">2.5 examples/</a><br>
|
|
<a href="#DirStructFs">2.6 fs/</a><br>
|
|
<a href="#DirStructGraphics">2.7 graphics/</a><br>
|
|
<a href="#DirStructInclude">2.8 include/</a><br>
|
|
<a href="#DirStructLib">2.9 lib/</a><br>
|
|
<a href="#DirStructMm">2.10 mm/</a><br>
|
|
<a href="#DirStructNet">2.11 net</a><br>
|
|
<a href="#DirStructNetUtils">2.12 netutils</a><br>
|
|
<a href="#DirStructSched">2.13 sched/</a><br>
|
|
<a href="#DirStructTools">2.14 tools/</a><br>
|
|
<a href="#topmakefile">2.15 Makefile</a>
|
|
</ul>
|
|
<a href="#configandbuild">3.0 Configuring and Building</a>
|
|
<ul>
|
|
<a href="#configuringnuttx">3.1 Configuring NuttX</a><br>
|
|
<a href="#buildingnuttx">3.2 Building NuttX</a>
|
|
</ul>
|
|
<a href="#ArchAPIs">4.0 Architecture APIs</a>
|
|
<ul>
|
|
<a href="#imports">4.1 APIs Exported by Architecture-Specific Logic to NuttX</a>
|
|
<ul>
|
|
<a href="#upinitialize">4.1.1 <code>up_initialize()</code></a><br>
|
|
<a href="#upidle">4.1.2 <code>up_idle()</code></a><br>
|
|
<a href="#upinitialstate">4.1.3 <code>up_initial_state()</code></a><br>
|
|
<a href="#upcreatestack">4.1.4 <code>up_create_stack()</code></a><br>
|
|
<a href="#upusestack">4.1.5 <code>up_use_stack()</code></a><br>
|
|
<a href="#upreleasestack">4.1.6 <code>up_release_stack()</code></a><br>
|
|
<a href="#upunblocktask">4.1.7 <code>up_unblock_task()</code></a><br>
|
|
<a href="#upblocktask">4.1.8 <code>up_block_task()</code></a><br>
|
|
<a href="#upreleasepending">4.1.9 <code>up_release_pending()</code></a><br>
|
|
<a href="#upreprioritizertr">4.1.10 <code>up_reprioritize_rtr()</code></a><br>
|
|
<a href="#_exit">4.1.11 <code>_exit()</code></a><br>
|
|
<a href="#upassert">4.1.12 <code>up_assert()</code></a><br>
|
|
<a href="#upschedulesigaction">4.1.13 <code>up_schedule_sigaction()</code></a><br>
|
|
<a href="#upallocateheap">4.1.14 <code>up_allocate_heap()</code></a><br>
|
|
<a href="#upinterruptcontext">4.1.15 <code>up_interrupt_context()</code></a><br>
|
|
<a href="#updisableirq">4.1.16 <code>up_disable_irq()</code></a><br>
|
|
<a href="#upenableirq">4.1.17 <code>up_enable_irq()</code></a><br>
|
|
<a href="#upprioritizeirq">4.1.18 <code>up_prioritize_irq()</code></a></br>
|
|
<a href="#upputc">4.1.19 <code>up_putc()</code></a>
|
|
</ul>
|
|
<a href="#exports">4.2 APIs Exported by NuttX to Architecture-Specific Logic</a>
|
|
<ul>
|
|
<a href="#osstart">4.2.1 <code>os_start()</code></a><br>
|
|
<a href="#listmgmt">4.2.2 OS List Management APIs</a><br>
|
|
<a href="#schedprocesstimer">4.2.3 <code>sched_process_timer()</code></a><br>
|
|
<a href="#irqdispatch">4.2.4 <code>irq_dispatch()</code></a>
|
|
</ul>
|
|
<a href="#ledsupport">4.3 LED Support</a>
|
|
<ul>
|
|
<a href="#ledheaders">4.3.1 Header Files</a><br>
|
|
<a href="#leddefinitions">4.3.2 LED Definitions</a><br>
|
|
<a href="#ledapis">4.3.3 Common LED interfaces</a>
|
|
</ul>
|
|
</ul>
|
|
<a href="#NxFileSystem">5.0 NuttX File System</a><br>
|
|
<a href="#DeviceDrivers">6.0 NuttX Device Drivers</a><br>
|
|
<ul>
|
|
<a href="#chardrivers">6.1 Character Device Drivers</a><br>
|
|
<a href="#blockdrivers">6.2 Block Device Drivers</a><br>
|
|
<a href="#blockdrivers">6.3 Specialized Device Drivers</a>
|
|
<ul>
|
|
<a href="#ethdrivers">6.3.1 Ethernet Device Drivers</a><br>
|
|
<a href="#spidrivers">6.3.2 SPI Device Drivers</a><br>
|
|
<a href="#i2cdrivers">6.3.3 I2C Device Drivers</a><br>
|
|
<a href="#serialdrivers">6.3.4 Serial Device Drivers</a>
|
|
</ul>
|
|
</ul>
|
|
<a href="#apndxconfigs">Appendix A: NuttX Configuration Settings</a><br>
|
|
<a href="#apndxtrademarks">Appendix B: Trademarks</a>
|
|
</ul>
|
|
|
|
<table width ="100%">
|
|
<tr bgcolor="#e4e4e4">
|
|
<td>
|
|
<h1>1.0 <a name="Introduction">Introduction</a></h1>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p><b>Overview</b>
|
|
This document provides and overview of the NuttX build and configuration
|
|
logic and provides hints for the incorporation of new processor/board architectures
|
|
into the build.
|
|
</p>
|
|
<p>
|
|
See also <code>arch/README.txt</code> and <code>configs/README.txt</code>.
|
|
</p>
|
|
|
|
<table width ="100%">
|
|
<tr bgcolor="#e4e4e4">
|
|
<td>
|
|
<h1>2.0 <a name="DirectoryStructure">Directory Structure</a></h1>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>
|
|
<b>Directory Structure</b>.
|
|
The general directly layout for NuttX is very similar to the directory structure
|
|
of the Linux kernel -- at least at the most superficial layers.
|
|
At the top level is the main makefile and a series of sub-directories identified
|
|
below and discussed in the following paragraphs:
|
|
</p>
|
|
<ul><pre>
|
|
.
|
|
|-- <a href="#topmakefile">Makefile</a>
|
|
|-- <a href="#DirStructDocumentation">Documentation</a>
|
|
| `-- <i>(documentation files)</i>/
|
|
|-- <a href="#DirStructArch">arch</a>/
|
|
| |-- <i><arch-name></i>/
|
|
| | |-- include/
|
|
| | | |--<i><chip-name></i>/
|
|
| | | | `-- <i>(chip-specific header files)</i>
|
|
| | | |--<i><other-chips></i>/
|
|
| | | `-- <i>(architecture-specific header files)</i>
|
|
| | `-- src/
|
|
| | |--<i><chip-name></i>/
|
|
| | | `-- <i>(chip-specific source files)</i>
|
|
| | |--<i><other-chips></i>/
|
|
| | `-- <i>(architecture-specific source files)</i>
|
|
| `-- <i><other-architecture directories></i>/
|
|
|-- <a href="#DirStructConfigs">configs</a>/
|
|
| |-- <i><board-name></i>/
|
|
| | |-- include/
|
|
| | | `-- <i>(other board-specific header files)</i>
|
|
| | |-- src/
|
|
| | | `-- <i>(board-specific source files)</i>
|
|
| | |---<i><config-name></i>/
|
|
| | | `-- <i>(board configuration-specific source files)</i>
|
|
| | `---<i>(other configuration sub-directories for this board)</i>/
|
|
| `-- <i><(other board directories)></i>/
|
|
|-- <a href="#DirStructDrivers">drivers</a>/
|
|
| |-- Makefile
|
|
| |-- <i>(driver-specific sub-directories)/</i>
|
|
| | `-- <i>(driver-specific source files)</i>
|
|
| `-- <i>(common driver source files)</i>
|
|
|-- <a href="#DirStructExamples">examples</a>/
|
|
| `-- <i>(example)</i>/
|
|
| |-- Makefile
|
|
| `-- <i>(example source files)</i>
|
|
|-- <a href="#DirStructFs">fs</a>/
|
|
| |-- Makefile
|
|
| |-- <i>(file system-specific sub-directories)</i>/
|
|
| | `-- <i>(file system-specific source files)</i>
|
|
| `-- <i>(common file system source files)</i>
|
|
|-- <a href="#DirStructGraphics">graphics</a>/
|
|
| |-- Makefile
|
|
| |-- <i>(feature-specific sub-directories)</i>/
|
|
| | `-- <i>(feature-specific source files library source files)</i>
|
|
| `-- <i>(common graphics-related source files)</i>
|
|
|-- <a href="#DirStructInclude">include</a>/
|
|
| |-- <i>(standard header files)</i>
|
|
| |-- <i>(standard include sub-directories)</i>
|
|
| | `-- <i>(more standard header files)</i>
|
|
| |-- <i>(non-standard include sub-directories)</i>
|
|
| `-- <i>(non-standard header files)</i>
|
|
|-- <a href="#DirStructLib">lib</a>/
|
|
| |-- Makefile
|
|
| `-- <i>(lib source files)</i>
|
|
|-- <a href="#DirStructMm">mm</a>/
|
|
| |-- Makefile
|
|
| `-- <i>(memory management source files)</i>
|
|
|-- <a href="#DirStructNet">net</a>/
|
|
| |-- Makefile
|
|
| |-- uip/
|
|
| | `-- <i>(uip source files)</i>
|
|
| `-- <i>(BSD socket source files)</i>
|
|
|-- <a href="#DirStructNetUtils">netutils</a>/
|
|
| |-- Makefile
|
|
| |-- <i>(network feature sub-directories)</i>/
|
|
| | `-- <i>(network feature source files)</i>
|
|
| `-- <i>(netutils common files)</i>
|
|
|-- <a href="#DirStructSched">sched</a>/
|
|
| |-- Makefile
|
|
| `-- <i>(sched source files)</i>
|
|
`-- <a href="#DirStructTools">tools</a>/
|
|
`-- <i>(miscellaneous scripts and programs)</i>
|
|
</pre></ul>
|
|
|
|
<p>
|
|
<b>Configuration Files</b>.
|
|
The NuttX configuration consists of:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<i>Processor architecture specific files</i>.
|
|
These are the files contained in the <code>arch/</code><i><arch-name></i><code>/</code> directory
|
|
and are discussed in a paragraph <a href="#archdirectorystructure">below</a>.
|
|
</li>
|
|
<li>
|
|
<i>Chip/SoC specific files</i>.
|
|
Each processor processor architecture is embedded in chip or <i>System-on-a-Chip</i> (SoC) architecture.
|
|
The full chip architecture includes the processor architecture plus chip-specific interrupt logic,
|
|
clocking logic, general purpose I/O (GIO) logic, and specialized, internal peripherals (such as UARTs, USB, etc.).
|
|
<p>
|
|
These chip-specific files are contained within chip-specific sub-directories in the
|
|
<code>arch/</code><i><arch-name></i><code>/</code> directory and are selected via
|
|
the <code>CONFIG_ARCH_name</code> selection.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<i>Board specific configurations</i>.
|
|
In order to be usable, the chip must be contained in a board environment.
|
|
The board configuration defines additional properties of the board including such things as
|
|
peripheral LEDs, external peripherals (such as network, USB, etc.).
|
|
<p>
|
|
These board-specific configuration files can be found in the
|
|
<code>configs/</code><i><board-name></i><code>/</code> sub-directories and are discussed
|
|
in a paragraph <a href="#configsdirectorystructure">below</a>.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>2.1 <a name="DirStructDocumentation">Documentation</a></h2>
|
|
|
|
<p>
|
|
General documentation for the NuttX OS resides in this directory.
|
|
</p>
|
|
|
|
<h2>2.2 <a name="DirStructArch">arch</a></h2>
|
|
|
|
<h3><a name="archdirectorystructure">2.2.1 Subdirectory Structure</a></h3>
|
|
<p>
|
|
This directory contains several sub-directories, each containing
|
|
architecture-specific logic.
|
|
The task of porting NuttX to a new processor consists of
|
|
add a new subdirectory under <code>arch/</code> containing logic specific
|
|
to the new architecture.
|
|
The complete board port in is defined by the architecture-specific code in this
|
|
directory (plus the board-specific configurations in the <code>config/</code>
|
|
subdirectory).
|
|
Each architecture must provide a subdirectory, <i><arch-name></i>
|
|
under <code>arch/</code> with the following characteristics:
|
|
</p>
|
|
<ul><pre>
|
|
<i><arch-name></i>/
|
|
|-- include/
|
|
| |--<i><chip-name></i>/
|
|
| | `-- <i>(chip-specific header files)</i>
|
|
| |--<i><other-chips></i>/
|
|
| |-- arch.h
|
|
| |-- irq.h
|
|
| |-- types.h
|
|
| `-- limits.h
|
|
`-- src/
|
|
|--<i><chip-name></i>/
|
|
| `-- <i>(chip-specific source files)</i>
|
|
|--<i><other-chips></i>/
|
|
|-- Makefile
|
|
`-- <i>(architecture-specific source files)</i>
|
|
</pre></ul>
|
|
|
|
<h3><a name="summaryofarchfiles">2.2.2 Summary of Files</a></h3>
|
|
<ul>
|
|
<li>
|
|
<code>include/</code><i><chip-name></i><code>/</code>
|
|
This sub-directory contains chip-specific header files.
|
|
</li>
|
|
<li>
|
|
<code>include/arch.h</code>:
|
|
This is a hook for any architecture specific definitions that may
|
|
be needed by the system. It is included by <code>include/nuttx/arch.h</code>.
|
|
</li>
|
|
<li>
|
|
<code>include/types.h</code>:
|
|
This provides architecture/toolchain-specific definitions for
|
|
standard types. This file should <code>typedef</code>:
|
|
<ul><code>
|
|
sbyte, ubyte, uint8, boolean, sint16, uint16, sint32, uint32
|
|
</code></ul>
|
|
<p>and if the architecture supports 64-bit integers</p>
|
|
<ul><code>
|
|
sint64, uint64
|
|
</code></ul>
|
|
<p>
|
|
and finally
|
|
</p>
|
|
<ul><code>
|
|
irqstate_t
|
|
</code></ul>
|
|
<p>
|
|
Must be defined to the be the size required to hold the interrupt
|
|
enable/disable state.
|
|
</p>
|
|
<p>
|
|
This file will be included by include/sys/types.h and be made
|
|
available to all files.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code>include/irq.h</code>:
|
|
This file needs to define some architecture specific functions (usually
|
|
inline if the compiler supports inlining) and structure. These include:
|
|
<ul>
|
|
<li>
|
|
<code>struct xcptcontext</code>:
|
|
This structures represents the saved context of a thread.
|
|
</li>
|
|
<li>
|
|
<code>irqstate_t irqsave(void)</code>:
|
|
Used to disable all interrupts.
|
|
</li>
|
|
<li>
|
|
<code>void irqrestore(irqstate_t flags)<code>:
|
|
Used to restore interrupt enables to the same state as before <code>irqsave()</code> was called.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
This file must also define <code>NR_IRQS</code>, the total number of IRQs supported
|
|
by the board.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code>src/</code><i><chip-name></i><code>/</code>
|
|
This sub-directory contains chip-specific source files.
|
|
</li>
|
|
<li>
|
|
<code>src/Makefile</code>:
|
|
This makefile will be executed to build the targets <code>src/libup.a</code> and
|
|
<code>src/up_head.o</code>. The <code>up_head.o</code> file holds the entry point into the system
|
|
(power-on reset entry point, for example). It will be used in
|
|
the final link with <code>libup.a</code> and other system archives to generate the
|
|
final executable.
|
|
</li>
|
|
<li>
|
|
<i>(architecture-specific source files)</i>.
|
|
The file <code>include/nuttx/arch.h</code> identifies all of the APIs that must
|
|
be provided by the architecture specific logic. (It also includes
|
|
<code>arch/</code><i><arch-name></i><code>/arch.h</code> as described above).
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="supportedarchitectures">2.2.3 Supported Architectures</a></h3>
|
|
<p>
|
|
<b>Archictecture- and Chip-Specific Directories</b>.
|
|
All processor architecture-specific directories are maintained in sub-directories of
|
|
the <code>arch/</code> directory.
|
|
Different chips or SoC's may implement the same processor core.
|
|
Chip-specific logic can be found in sub-directories under the architecture
|
|
directory.
|
|
Current architecture/chip directories are summarized below:
|
|
</p>
|
|
<ul>
|
|
<li><code>arch/sim</code>:
|
|
A user-mode port of NuttX to the x86 Linux platform is available.
|
|
The purpose of this port is primarily to support OS feature developement.
|
|
This port does not support interrupts or a real timer (and hence no
|
|
round robin scheduler) Otherwise, it is complete.
|
|
</li>
|
|
<p>NOTE: This target will not run on Cygwin probably for many reasons but
|
|
first off because it uses some of the same symbols as does cygwind.dll.
|
|
</p>
|
|
|
|
<li><code>arch/arm</code>:
|
|
This directory holds common ARM architectures. At present, this includes
|
|
the following subdirectories:
|
|
<ul>
|
|
<li><code>arch/arm/include</code> and <code>arch/arm/src/common</code>:
|
|
Common ARM logic.
|
|
</li>
|
|
|
|
<li><code>arch/arm/include/c5471</code> and <code>arch/arm/src/c5471</code>:
|
|
TI TMS320C5471 (also called TMS320DM180 or just C5471).
|
|
NuttX operates on the ARM7 of this dual core processor.
|
|
This port is complete, verified, and included in the NuttX release 0.1.1.
|
|
</li>
|
|
|
|
<li><code>arch/arm/include/dm320</code> and <code>arch/arm/src/dm320</code>:
|
|
TI TMS320DM320 (also called just DM320).
|
|
NuttX operates on the ARM9EJS of this dual core processor.
|
|
This port complete, verified, and included in the NuttX release 0.2.1.
|
|
</li>
|
|
|
|
<li><code>arch/arm/include/lpc214x</code> and <code>arch/arm/src/lpc214x</code>:
|
|
These directories provide support for NXP LPC214x family of
|
|
processors.
|
|
STATUS: This port is in progress and should be available in the
|
|
nuttx-0.2.5 release.
|
|
</li>
|
|
|
|
</ul>
|
|
</li>
|
|
|
|
<li><code>configs/mcu123-lpc214x</code>:
|
|
The mcu123.com lpc214x development board.
|
|
This is a work in progress.
|
|
</li>
|
|
|
|
<li><code>arch/m68322</code>
|
|
A work in progress.
|
|
</li>
|
|
|
|
<li><code>arch/pjrc-8051</code>:
|
|
8051 Microcontroller. This port is not quite ready for prime time.
|
|
</li>
|
|
|
|
<li><code>arch/z16f</code>:
|
|
Zilog z16f Microcontroller.
|
|
This port uses the Zilog z16f2800100zcog Development Kit.
|
|
This port was released with nuttx-0.3.7.
|
|
</li>
|
|
|
|
<li><code>arch/z80</code>:
|
|
This directory holds 8-bit ZiLOG architectures. At present, this includes the
|
|
Zilog z80, ez80Acclaim! and z8Encore! Microcontrollers.
|
|
<ul>
|
|
<li><code>arch/z80/include</code> and <code>arch/z80/src/common</code>:
|
|
Common logic.
|
|
</li>
|
|
|
|
<li><code>arch/z80/include/z80</code> and <code>arch/z80/src/z80</code>:
|
|
The Z80 port was released in nuttx-0.3.6 has been verified using only a
|
|
z80 instruction simulator.
|
|
The set simulator can be found in the NuttX CVS at
|
|
http://nuttx.cvs.sourceforge.net/nuttx/misc/sims/z80sim.
|
|
This port also uses the SDCC toolchain (http://sdcc.sourceforge.net/")
|
|
(verified with version 2.6.0 and 2.7.0).
|
|
</li>
|
|
|
|
<li><code>arch/z80/include/ez80</code> and <code>arch/z80/src/ez80</code>:
|
|
The ez80Acclaim! port uses the ZiLOG ez80f0910200kitg development kit, eZ80F091 part,
|
|
with the Zilog ZDS-II Windows command line tools.
|
|
The development environment is Cygwin under WinXP.
|
|
This is a work in progress. Verified ez80 support will be announced in a future NuttX release.
|
|
</li>
|
|
|
|
<li><code>arch/z80/include/z8</code> and <code>arch/z80/src/z8</code>:
|
|
The Z8Encore! port uses either the ZiLOG z8encore000zco development kit, Z8F6403 part,
|
|
or the z8f64200100kit development kit, Z8F6423 part with the Zilog ZDS-II Windows command line
|
|
tools. The development environment is Cygwin under WinXP.
|
|
The initial release, verified only on the ZDS-II ez8 simulator, was released in nuttx-0.3.9.
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
<b>Deprecated Architecture Directories</b>.
|
|
The following architecture directories are deprecated. They have been
|
|
replaced by the logic in <code>arm/arm</code> and will deleted when
|
|
<code>arch/arm</code> is fully verified.
|
|
</p>
|
|
<ul>
|
|
<li><code>arch/c5471</code>:
|
|
Replaced with <code>arch/arm/include/c5471</code> and
|
|
<code>arch/arm/src/c5471<code>.
|
|
</li>
|
|
|
|
<li><code>arch/dm320</code>:
|
|
Replaced with <code>arch/arm/include/dm320</code> and
|
|
<code>arch/arm/src/dm320<code>.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
Other ports for the for the TI TMS320DM270 and for MIPS are in various states
|
|
of progress
|
|
</p>
|
|
|
|
<h2>2.3 <a name="DirStructConfigs">configs</a></h2>
|
|
<p>
|
|
The <code>configs/</code> subdirectory contains configuration data for each board.
|
|
These board-specific configurations plus the architecture-specific configurations in
|
|
the <code>arch/</code> subdirectory complete define a customized port of NuttX.
|
|
</p>
|
|
|
|
<h3><a name="configsdirectorystructure">2.3.1 Subdirectory Structure</a></h3>
|
|
<p>
|
|
The configs directory contains board specific configuration files. Each board must
|
|
provide a subdirectory <board-name> under <code>configs/</code> with the following characteristics:
|
|
</p>
|
|
<ul><pre>
|
|
<i><board-name></i>
|
|
|-- include/
|
|
| |-- board.h
|
|
| `-- <i>(board-specific header files)</i>
|
|
|-- src/
|
|
| |-- Makefile
|
|
| `-- <i>(board-specific source files)</i>
|
|
|-- <i><config1-dir></i>
|
|
| |-- Make.defs
|
|
| |-- defconfig
|
|
| `-- setenv.sh
|
|
|-- <i><config2-dir></i>
|
|
| |-- Make.defs
|
|
| |-- defconfig
|
|
| `-- setenv.sh
|
|
| ...
|
|
`-- <i>(other board-specific configuration sub-directories)</i>/
|
|
</pre></ul>
|
|
|
|
<h3><a name="summaryofconfigfiles">2.3.2 Summary of Files</a></h3>
|
|
<h4><a name="boardlogic">2.3.2.1 Board Specific Logic</a></h4>
|
|
<ul>
|
|
<li>
|
|
<code>include/</code>:
|
|
This directory contains board specific header files.
|
|
This directory will be linked as <code>include/arch/board</code> at configuration time
|
|
and can be included via <code>#include <arch/board/header.h></code>.
|
|
These header file can only be included by files in <code>arch/</code><i><arch-name></i><code>/include/</code>
|
|
and <code>arch/</code><i><arch-name></i><code>/src/</code>.
|
|
</li>
|
|
<li>
|
|
<code>src/</code>:
|
|
This directory contains board specific drivers.
|
|
This directory will be linked as <config>arch/</code><i><arch-name></i><code>/src/board</config> at configuration
|
|
time and will be integrated into the build system.
|
|
</li>
|
|
<li>
|
|
<code>src/Makefile</code>:
|
|
This makefile will be invoked to build the board specific drivers.
|
|
It must support the following targets: <code>libext$(LIBEXT)</code>, <code>clean</code>, and <code>distclean</code>.
|
|
</li>
|
|
</ul>
|
|
<h4><a name="boardconfigsubdirs">2.3.2.2 Board Specific Configuration Sub-Directories</a></h4>
|
|
<p>
|
|
The <code>configs/</code><i><board-name></i><code>/</code> sub-directory holds all of the
|
|
files that are necessary to configure Nuttx for the particular board.
|
|
A board may have various different configurations using the common source files.
|
|
Each board configuration is described by three files: <code>Make.defs</code>, <code>defconfig</code>, and <code>setenv.sh</code>.
|
|
Typically, each set of configuration files is retained in a separate configuration sub-directory
|
|
(<i><config1-dir></i>, <i><config2-dir></i>, .. in the above diagram).
|
|
|
|
The procedure for configuring NuttX is described <a href="#configuringnuttx">below</a>,
|
|
This paragraph will describe the contents of these configuration files.
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>Make.defs</code>: This makefile fragment provides architecture and
|
|
tool-specific build options. It will be included by all other
|
|
makefiles in the build (once it is installed). This make fragment
|
|
should define:
|
|
<ul>
|
|
<li>Tools: CC, LD, AR, NM, OBJCOPY, OBJDUMP</li>
|
|
<li>Tool options: CFLAGS, LDFLAGS</li>
|
|
<li>COMPILE, ASSEMBLE, ARCHIVE, CLEAN, and MKDEP macros</li>
|
|
</ul>
|
|
<p>
|
|
When this makefile fragment runs, it will be passed TOPDIR which
|
|
is the path to the root directory of the build. This makefile
|
|
fragment may include ${TOPDIR}/.config to perform configuration
|
|
specific settings. For example, the CFLAGS will most likely be
|
|
different if CONFIG_DEBUG=y.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code>defconfig</code>: This is a configuration file similar to the Linux
|
|
configuration file. In contains variable/value pairs like:
|
|
<ul>
|
|
<li><code>CONFIG_VARIABLE</code>=value</li>
|
|
</ul>
|
|
<p>
|
|
This configuration file will be used at build time:
|
|
</p>
|
|
<ol>
|
|
<li>As a makefile fragment included in other makefiles, and</li>
|
|
<li>to generate <code>include/nuttx/config.h</code> which is included by
|
|
most C files in the system.</li>
|
|
</ol>
|
|
</li>
|
|
<li>
|
|
<code>setenv.sh</code>: This is a script that you can include that will be installed at
|
|
the toplevel of the directory structure and can be sourced to set any
|
|
necessary environment variables.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="supportedboards">2.3.3 Supported Boards</a></h3>
|
|
<p>
|
|
All of the specific boards supported by NuttX are identified below.
|
|
These are the specific <i><board-name></i>'s that may be used to configure NuttX
|
|
as described <a href="#configuringnuttx">below</a>.
|
|
</p>
|
|
<ul>
|
|
<li><code>configs/c5471evm</code>:
|
|
This is a port to the Spectrum Digital C5471 evaluation board. The
|
|
C5471 is a dual core processor from TI with an ARM7TDMI general purpose
|
|
processor and a c54 SDP. NuttX runs on the ARM core and is built with
|
|
with a GNU arm-elf toolchain* under Linux or Cygwin.
|
|
This port is complete, verified, and included in the NuttX release.
|
|
</li>
|
|
|
|
<li><code>configs/ez80f0910200kitg</code>
|
|
ez80Acclaim! Microcontroller. This port use the Zilog ez80f0910200kitg
|
|
development kit, eZ80F091 part, and the Zilog ZDS-II Windows command line
|
|
tools. The development environment is Cygwin under WinXP.
|
|
</li>
|
|
|
|
<li><code>configs/m68322evb</code>:
|
|
This is a work in progress for the venerable m68322evb board from
|
|
Motorola.
|
|
</li>
|
|
|
|
<li><code>configs/mcu123-lpc214x</code>:
|
|
This port is for the NXP LPC2148 as provided on the mcu123.com
|
|
lpc214x development board.
|
|
This OS is also built with the arm-elf toolchain* under Linux or Cygwin.
|
|
The port supports serial, timer0, spi, and usb.
|
|
</li>
|
|
|
|
<li><code>configs/ntosd-dm320</code>:
|
|
This port uses the Neuros OSD with a GNU arm-elf toolchain* under Linux or Cygwin.
|
|
See <a href="http://wiki.neurostechnology.com/index.php/Developer_Welcome">Neuros Wiki</a>
|
|
for futher information.
|
|
NuttX operates on the ARM9EJS of this dual core processor.
|
|
STATUS: This port is code complete, verified, and included in the
|
|
NuttX 0.2.1 release.
|
|
</li>
|
|
|
|
<li><code>configs/olimex-strp711</code>:
|
|
This port uses the Olimex STR-P711 board arm-elf toolchain* under Linux or Cygwin.
|
|
See the <a href="http://www.olimex.com/dev/str-p711.html">Olimex</a> web site
|
|
for futher information.
|
|
STATUS: Coding for the basic port -- serial console and system timer -- is complete
|
|
but untested to problems I am having using OpenOCD with a wiggler clone JTAG.
|
|
</li>
|
|
|
|
<li><code>configs/pjrc-8051</code>:
|
|
8051 Microcontroller. This port uses the PJRC 87C52 development system
|
|
and the <a href="http://sdcc.sourceforge.net/">SDCC</a> toolchain under Linux or Cygwin.
|
|
This port is not quite ready for prime time.
|
|
</li>
|
|
|
|
<li><code>configs/sim</code>:
|
|
A user-mode port of NuttX to the x86 Linux platform is available.
|
|
The purpose of this port is primarily to support OS feature developement.
|
|
This port does not support interrupts or a real timer (and hence no
|
|
round robin scheduler) Otherwise, it is complete.
|
|
</li>
|
|
|
|
<li><code>configs/us7032evb1</code>:
|
|
This is a port of the Hitachi SH-1 on the Hitachi SH-1/US7032EVB1 board.
|
|
STATUS: Work has just began on this port.
|
|
</li>
|
|
|
|
<li><code>configs/xtrs</code>:
|
|
TRS80 Model 3. This port uses a vintage computer based on the Z80.
|
|
An emulator for this computer is available to run TRS80 programs on a
|
|
linux platform (http://www.tim-mann.org/xtrs.html).
|
|
</li>
|
|
|
|
<li><code>configs/z16f2800100zcog</code>
|
|
z16f Microcontroller.
|
|
This port use the Zilog z16f2800100zcog development kit and the
|
|
Zilog ZDS-II Windows command line tools.
|
|
The development environment is Cygwin under WinXP.
|
|
</li>
|
|
|
|
<li><code>configs/z80sim</code>:
|
|
z80 Microcontroller. This port uses a Z80 instruction set simulator.
|
|
That simulator can be found in the NuttX CVS
|
|
<a href="http://nuttx.cvs.sourceforge.net/nuttx/misc/sims/z80sim/">here</a>.
|
|
This port also the <a href="http://sdcc.sourceforge.net/">SDCC</a> toolchain
|
|
under Linux or Cygwin(verfied with version 2.6.0).
|
|
</li>
|
|
|
|
<li><code>configs/z8encore000zco</code>
|
|
z8Encore! Microcontroller. This port use the Zilog z8encore000zco
|
|
development kit, Z8F6403 part, and the Zilog ZDS-II Windows command line
|
|
tools. The development environment is Cygwin under WinXP.
|
|
</li>
|
|
|
|
<li><code>configs/z8encore000zco</code>
|
|
z8Encore! Microcontroller. This port use the Zilog z8f64200100kit
|
|
development kit, Z8F6423 part, and the Zilog ZDS-II Windows command line
|
|
tools. The development environment is Cygwin under WinXP.
|
|
</li>
|
|
</ul>
|
|
|
|
<p><small><blockquote>
|
|
* A customized version of the <a href="http://www.buildroot.org">buildroot</a>
|
|
is available to build these toolchains under Linux or Cygwin.
|
|
</blockquote></small></p>
|
|
|
|
<h2>2.4 <a name="DirStructDrivers">drivers</a></h2>
|
|
|
|
<p>
|
|
This directory holds architecture-independent device drivers.
|
|
</p>
|
|
<ul><pre>
|
|
drivers/
|
|
|-- Makefile
|
|
|-- bch/
|
|
| |-- Make.defs
|
|
| `-- <i>(bch driver source files)</i>
|
|
|-- mmcsd/
|
|
| |-- Make.defs
|
|
| `-- <i>(mmcsd driver source files)</i>
|
|
|-- net/
|
|
| |-- Make.defs
|
|
| `-- <i>(net driver source files)</i>
|
|
|-- usbdev/
|
|
| |-- Make.defs
|
|
| `-- <i>(usbdev driver source files)</i>
|
|
`-- <i>(common driver source files)</i>
|
|
</pre></ul>
|
|
|
|
<h2>2.5 <a name="DirStructExamples">examples</a></h2>
|
|
|
|
<p>
|
|
Example and test programs to build against.
|
|
</p>
|
|
|
|
<h2>2.6 <a name="DirStructFs">fs</a></h2>
|
|
|
|
<p>
|
|
This directory contains the NuttX file system.
|
|
This file system is described <a href="#NxFileSystem">below</a>.
|
|
</p>
|
|
<ul><pre>
|
|
fs/
|
|
|-- Makefile
|
|
|-- fat/
|
|
| |-- Make.defs
|
|
| `-- <i>(fat file system source files)</i>
|
|
|-- romfs/
|
|
| |-- Make.defs
|
|
| `-- <i>(romfs file system source files)</i>
|
|
`-- <i>(common file system source files)</i>
|
|
</pre></ul>
|
|
|
|
<h2>2.7 <a name="DirStructGraphics">graphics</a></h2>
|
|
|
|
<p>
|
|
This directory contains files for graphics/video support under NuttX.
|
|
</p>
|
|
<ul><pre>
|
|
graphics/
|
|
|-- Makefile
|
|
|-- nxglib/
|
|
| |-- Make.defs
|
|
| `-- <i>(NuttX graphics library source files)</i>
|
|
|-- nx/
|
|
| |-- Make.defs
|
|
| `-- <i>(Nuttx X-server source files)</i>
|
|
`-- <i>(common file system source files)</i>
|
|
</pre></ul>
|
|
|
|
<h2>2.8 <a name="DirStructInclude">include</a></h2>
|
|
<p>
|
|
This directory holds NuttX header files.
|
|
Standard header files file retained in can be included in the <i>normal</i> fashion:
|
|
</p>
|
|
<ul>
|
|
<code>include <stdio.h></code><br>
|
|
<code>include <sys/types.h></code><br>
|
|
etc.
|
|
</ul>
|
|
<p>
|
|
Directory structure:
|
|
</p>
|
|
<ul><pre>
|
|
include/
|
|
|-- <i>(standard header files)</i>
|
|
|-- arpa/
|
|
| `-- <i>(standard header files)</i>
|
|
|-- net/
|
|
| `-- uip/
|
|
| `-- <i>(uIP specific header files)</i>
|
|
|-- netinet/
|
|
| `-- <i>(standard header files)</i>
|
|
|-- nuttx/
|
|
| `-- <i>(nuttx specific header files)</i>
|
|
`- sys/
|
|
`-- <i>(more standard header files)</i>
|
|
</per></ul>
|
|
|
|
<h2>2.9 <a name="DirStructLib">lib</a></h2>
|
|
<p>
|
|
This directory holds a collection of standard libc-like functions with custom
|
|
interfaces into Nuttx.
|
|
</p>
|
|
|
|
<h2>2.10 <a name="DirStructMm">mm</a></h2>
|
|
<p>
|
|
This is the NuttX memory manager.
|
|
</p>
|
|
|
|
<h2>2.11 <a name="DirStructNet">net</a></h2>
|
|
<p>
|
|
This directory contains the implementation of the socket APIs.
|
|
The subdirectory, <code>uip</code> contians the uIP port.
|
|
</P>
|
|
|
|
<h2>2.12 <a name="DirStructNetUtils">netutils</a></h2>
|
|
<p>
|
|
This directory contains most of the network applications.
|
|
Some of these are original with NuttX (like tftpc and dhcpd) and others were leveraged from the uIP-1.0 apps directory.
|
|
As the uIP apps/README says, these applications "are not all heavily tested."
|
|
</p>
|
|
<ul><pre>
|
|
netutils/
|
|
|-- Makefile
|
|
|-- dhcp/
|
|
| |-- Make.defs
|
|
| `-- <i>(dhcp source files)</i>
|
|
|-- dhcpd/
|
|
| |-- Make.defs
|
|
| `-- <i>(dhcpd source files)</i>
|
|
|-- resolv/
|
|
| |-- Make.defs
|
|
| `-- <i>(resolv source files)</i>
|
|
|-- smtp/
|
|
| |-- Make.defs
|
|
| `-- <i>(smtp source files)</i>
|
|
|-- telnetd/
|
|
| |-- Make.defs
|
|
| `-- <i>(telnetd source files)</i>
|
|
|-- tftpc/
|
|
| |-- Make.defs
|
|
| `-- <i>(tftpc source files)</i>
|
|
|-- uiplib/
|
|
| |-- Make.defs
|
|
| `-- <i>(uiplib source files)</i>
|
|
|-- weblclient/
|
|
| |-- Make.defs
|
|
| `-- <i>(webclient source files)</i>
|
|
|-- webserver/
|
|
| |-- Make.defs
|
|
| `-- <i>(webserver source files)</i>
|
|
`-- <i>(netutils common files)</i>
|
|
</pre></ul>
|
|
|
|
<h2>2.13 <a name="DirStructSched">sched</a></h2>
|
|
<p>
|
|
The files forming core of the NuttX RTOS reside here.
|
|
</p>
|
|
|
|
<h2>2.14 <a name="DirStructTools">tools</a></h2>
|
|
<p>
|
|
This directory holds a collection of tools and scripts to simplify
|
|
configuring, building and maintaining NuttX.
|
|
</p>
|
|
<ul><pre>
|
|
tools/
|
|
|-- Makefile.mkconfig
|
|
|-- configure.sh
|
|
|-- incdir.sh
|
|
|-- indent.sh
|
|
|-- link.sh
|
|
|-- mkconfig.c
|
|
|-- mkdeps.sh
|
|
|-- mkimage.sh
|
|
|-- mknulldeps.sh
|
|
|-- unlink.sh
|
|
|-- winlink.sh
|
|
`-- zipme
|
|
</pre></ul>
|
|
|
|
<h2>2.15 <a name="topmakefile">Makefile</a></h2>
|
|
<p>
|
|
The top-level <code>Makefile</code> in the <code>${TOPDIR}</code> directory contains all of the top-level control
|
|
logic to build NuttX.
|
|
Use of this <code>Makefile</code> to build NuttX is described <a href="#buildingnuttx">below</a>.
|
|
</p>
|
|
|
|
<table width ="100%">
|
|
<tr bgcolor="#e4e4e4">
|
|
<td>
|
|
<h1>3.0 <a name="configandbuild">Configuring and Building</a></h1>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2><a name="configuringnuttx">3.1 Configuring NuttX</a></h2>
|
|
<p>
|
|
<b>Manual Configuration</b>.
|
|
Configuring NuttX requires only copying the
|
|
<a href="#boardconfigsubdirs">board-specific configuration files</a> into the top level directory which appears in the make files as the make variable, <code>${TOPDIR}</code>.
|
|
This could be done manually as follows:
|
|
</p>
|
|
<ul>
|
|
<li>Copy <code>configs/</code><i><board-name></i><code>/[</code><i><config-dir></i><code>/]Make.def</code> to <code>${TOPDIR}/Make.defs</code>,<li>
|
|
<li>Copy <code>configs/</code><i><board-name></i><code>/[</code><i><config-dir></i><code>/]setenv.sh</code> to <code>${TOPDIR}/setenv.sh</code>, and</li>
|
|
<li>Copy <code>configs/</code><i><board-name></i><code>/[</code><i><config-dir></i><code>/]defconfig</code> to <code>${TOPDIR}/.config</code></li>
|
|
</ul>
|
|
<p>
|
|
Where <i><board-name></i> is the name of one of the sub-directories of the
|
|
NuttX <a href="#DirStructConfigs"><code>configs/</code></a> directory.
|
|
This sub-directory name corresponds to one of the supported boards
|
|
identified <a href="#supportedboards">above</a>.
|
|
And <config-dir> is the optional, specific configuration directory for the board.
|
|
</p>
|
|
<p>
|
|
<b>Automated Configuration</b>.
|
|
There is a script that automates these steps. The following steps will
|
|
accomplish the same configuration:
|
|
</p>
|
|
<ul><pre>
|
|
cd tools
|
|
./configure.sh <i><board-name></i></i><code>[/</code><i><config-dir></i><code>]</code>
|
|
</pre></ul>
|
|
|
|
<p>
|
|
<b>Additional Configuration Steps</b>.
|
|
The remainder of configuration steps will be performed by <a href="#topmakefile"><code>${TOPDIR}/Makefile</code></a>
|
|
the first time the system is built as described below.
|
|
</p>
|
|
|
|
<h2><a name="buildingnuttx">3.2 Building NuttX</a></h2>
|
|
<p>
|
|
<b>Building NuttX</b>.
|
|
Once NuttX has been configured as described <a href="#configuringnuttx">above</a>, it may be built as follows:
|
|
</p>
|
|
<ul><pre>
|
|
cd ${TOPDIR}
|
|
source ./setenv.sh
|
|
make
|
|
</pre></ul>
|
|
<p>
|
|
The <code>${TOPDIR}</code> directory holds:
|
|
</p>
|
|
<ul>
|
|
<li>The top level <a href="#topmakefile"><code>Makefile</code></a> that controls the NuttX build.
|
|
</ul>
|
|
<p>
|
|
That directory also holds:
|
|
</p>
|
|
<ul>
|
|
<li>The makefile fragment <a href="#boardconfigsubdirs"><code>.config</code></a> that describes the current configuration.</li>
|
|
<li>The makefile fragment <a href="#boardconfigsubdirs"><code>Make.defs</code></a> that provides customized build targers, and</li>
|
|
<li>The shell script <a href="#boardconfigsubdirs"><code>setenv.sh</code></a> that sets up the configuration environment for the build.</li>
|
|
</ul>
|
|
<p>
|
|
The <a href="#boardconfigsubdirs"><code>setenv.sh</code></a> contains Linux/Cygwin environmental settings that are needed for the build.
|
|
The specific environmental definitions are unique for each board but should include, as a minimum, updates to the <code>PATH</code> variable to include the full path to the architecture-specific toolchain identified in <a href="#boardconfigsubdirs"><code>Make.defs</code></a>.
|
|
The <a href="#boardconfigsubdirs"><code>setenv.sh</code></a> only needs to be source'ed at the beginning of a session.
|
|
The system can be re-made subsequently by just typing <code>make</code>.
|
|
</p>
|
|
<p>
|
|
<b>First Time Make.</b>
|
|
Additional configuration actions will be taken the first time that system is built.
|
|
These additional steps include:
|
|
</p>
|
|
<ul>
|
|
<li>Auto-generating the file <code>include/nuttx/config.</code> using the <code>${TOPDIR}/.config</code> file.
|
|
<li>Creating a link to <code>${TOPDIR}/arch/</code><i><arch-name></i><code>/include</code> at <code>${TOPDIR}/include/arch</code>.
|
|
<li>Creating a link to <code>${TOPDIR}/configs/</code><i><board-name></i><code>/include</code> at <code>${TOPDIR}/include/arch/board</code>.
|
|
<li>Creating a link to <code>${TOPDIR}/configs/</code><i><board-name></i><code>/src</code> at <code>${TOPDIR}/arch/</code><i><arch-name></i><code>/src/board</code>
|
|
<li>Creating make dependencies.
|
|
</ul>
|
|
|
|
<table width ="100%">
|
|
<tr bgcolor="#e4e4e4">
|
|
<td>
|
|
<h1>4.0 <a name="ArchAPIs">Architecture APIs</a></h1>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>
|
|
The file <code>include/nuttx/arch.h</code> identifies by prototype all of the APIs that must
|
|
be provided by the architecture specific logic.
|
|
The internal OS APIs that architecture-specific logic must
|
|
interface with also also identified in <code>include/nuttx/arch.h</code> or in
|
|
other header files.
|
|
</p>
|
|
|
|
<h2><a name="imports">4.1 APIs Exported by Architecture-Specific Logic to NuttX</a></h2>
|
|
<h3><a name="upinitialize">4.1.1 <code>up_initialize()</code></a></h3>
|
|
|
|
<p><b>Prototype</b>: <code>void up_initialize(void);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
<code>up_initialize()</code> will be called once during OS
|
|
initialization after the basic OS services have been
|
|
initialized. The architecture specific details of
|
|
initializing the OS will be handled here. Such things as
|
|
setting up interrupt service routines, starting the
|
|
clock, and registering <a href="#DeviceDrivers">device drivers</a> are some of the
|
|
things that are different for each processor and hardware
|
|
platform.
|
|
</p>
|
|
<p>
|
|
<code>up_initialize()</code> is called after the OS initialized but
|
|
before the init process has been started and before the
|
|
libraries have been initialized. OS services and driver
|
|
services are available.
|
|
</p>
|
|
|
|
<h3><a name="upidle">4.1.2 <code>up_idle()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void up_idle(void);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
<code>up_idle()</code> is the logic that will be executed
|
|
when their is no other ready-to-run task. This is processor
|
|
idle time and will continue until some interrupt occurs to
|
|
cause a context switch from the idle task.
|
|
</p>
|
|
<p>
|
|
Processing in this state may be processor-specific. e.g.,
|
|
this is where power management operations might be performed.
|
|
</p>
|
|
|
|
<h3><a name="upinitialstate">4.1.3 <code>up_initial_state()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void up_initial_state(FAR _TCB *tcb);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
A new thread is being started and a new TCB
|
|
has been created. This function is called to initialize
|
|
the processor specific portions of the new TCB.
|
|
</p>
|
|
<p>
|
|
This function must setup the intial architecture registers
|
|
and/or stack so that execution will begin at tcb->start
|
|
on the next context switch.
|
|
</p>
|
|
|
|
<h3><a name="upcreatestack">4.1.4 <code>up_create_stack()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>STATUS up_create_stack(FAR _TCB *tcb, size_t stack_size);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
Allocate a stack for a new thread and setup
|
|
up stack-related information in the TCB.
|
|
</p>
|
|
<p>
|
|
The following TCB fields must be initialized:
|
|
</p>
|
|
<ul>
|
|
<li><code>adj_stack_size</code>: Stack size after adjustment for hardware,
|
|
processor, etc. This value is retained only for debug
|
|
purposes.</li>
|
|
<li><code>stack_alloc_ptr</code>: Pointer to allocated stack</li>
|
|
<li><code>adj_stack_ptr</code>: Adjusted <code>stack_alloc_ptr</code> for HW. The
|
|
initial value of the stack pointer.
|
|
</ul>
|
|
<p>
|
|
This API is <i>NOT</i> required if <code>CONFIG_CUSTOM_STACK</code>
|
|
is defined.
|
|
</p>
|
|
|
|
<p><b>Inputs</b>:</p?
|
|
<ul>
|
|
<li>
|
|
<code>tcb</code>: The TCB of new task.
|
|
</li>
|
|
<li>
|
|
<code>stack_size</code>: The requested stack size. At least this much
|
|
must be allocated.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="upusestack">4.1.5 <code>up_use_stack()</code></a></h3>
|
|
<p><b>Prototype</b>:
|
|
<code>STATUS up_use_stack(FAR _TCB *tcb, FAR void *stack, size_t stack_size);</code>
|
|
</p>
|
|
|
|
<p><b>Description</b>.
|
|
Setup up stack-related information in the TCB
|
|
using pre-allocated stack memory.
|
|
</p>
|
|
<p>
|
|
The following TCB fields must be initialized:
|
|
</p>
|
|
<ul>
|
|
<li><code>adj_stack_size</code>: Stack size after adjustment for hardware,
|
|
processor, etc. This value is retained only for debug
|
|
purposes.</li>
|
|
<li><code>stack_alloc_ptr</code>: Pointer to allocated stack</li>
|
|
<li><code>adj_stack_ptr</code>: Adjusted <code>stack_alloc_ptr</code> for HW. The
|
|
initial value of the stack pointer.
|
|
</ul>
|
|
<p>
|
|
This API is <i>NOT</i> required if <code>CONFIG_CUSTOM_STACK</code>
|
|
is defined.
|
|
</p>
|
|
|
|
<p><b>Inputs:</b></p>
|
|
<ul>
|
|
<li>
|
|
<code>tcb</code>: The TCB of new task.
|
|
</li>
|
|
<li>
|
|
<code>stack_size</code>: The allocated stack size.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="upreleasestack">4.1.6 <code>up_release_stack()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void up_release_stack(FAR _TCB *dtcb);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
A task has been stopped. Free all stack
|
|
related resources retained int the defunct TCB.
|
|
</p>
|
|
<p>
|
|
This API is <i>NOT</i> required if <code>CONFIG_CUSTOM_STACK</code>
|
|
is defined.
|
|
</p>
|
|
|
|
<h3><a name="upunblocktask">4.1.7 <code>up_unblock_task()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void up_unblock_task(FAR _TCB *tcb);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
A task is currently in an inactive task list
|
|
but has been prepped to execute. Move the TCB to the
|
|
ready-to-run list, restore its context, and start execution.
|
|
</p>
|
|
<p>
|
|
This function is called only from the NuttX scheduling
|
|
logic. Interrupts will always be disabled when this
|
|
function is called.
|
|
</p>
|
|
|
|
<p><b>Inputs</b>:
|
|
<ul>
|
|
<li><code>tcb</code>: Refers to the tcb to be unblocked. This tcb is
|
|
in one of the waiting tasks lists. It must be moved to
|
|
the ready-to-run list and, if it is the highest priority
|
|
ready to run taks, executed.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="upblocktask">4.1.8 <code>up_block_task()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void up_block_task(FAR _TCB *tcb, tstate_t task_state);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
The currently executing task at the head of
|
|
the ready to run list must be stopped. Save its context
|
|
and move it to the inactive list specified by task_state.
|
|
|
|
This function is called only from the NuttX scheduling
|
|
logic. Interrupts will always be disabled when this
|
|
function is called.
|
|
|
|
<p><b>Inputs:</b></p>
|
|
<ul>
|
|
<li><code>tcb</code>: Refers to a task in the ready-to-run list (normally
|
|
the task at the head of the list). It most be
|
|
stopped, its context saved and moved into one of the
|
|
waiting task lists. It it was the task at the head
|
|
of the ready-to-run list, then a context to the new
|
|
ready to run task must be performed.
|
|
</li>
|
|
<li><code>task_state</code>: Specifies which waiting task list should be
|
|
hold the blocked task TCB.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="upreleasepending">4.1.9 <code>up_release_pending()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void up_release_pending(void);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
When tasks become ready-to-run but cannot run because pre-emption
|
|
is disabled, they are placed into a pending task list.
|
|
This function releases and makes ready-to-run all of the tasks that have
|
|
collected in the pending task list. This can cause a
|
|
context switch if a new task is placed at the head of
|
|
the ready to run list.
|
|
</p>
|
|
<p>
|
|
This function is called only from the NuttX scheduling logic when
|
|
pre-emption is re-enabled. Interrupts will always be disabled when this
|
|
function is called.
|
|
</p>
|
|
|
|
<h3><a name="upreprioritizertr">4.1.10 <code>up_reprioritize_rtr()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void up_reprioritize_rtr(FAR _TCB *tcb, ubyte priority);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
Called when the priority of a running or
|
|
ready-to-run task changes and the reprioritization will
|
|
cause a context switch. Two cases:
|
|
</p>
|
|
<ol>
|
|
<li>
|
|
The priority of the currently running task drops and the next
|
|
task in the ready to run list has priority.
|
|
</li>
|
|
<li>
|
|
An idle, ready to run task's priority has been raised above the
|
|
the priority of the current, running task and it now has the
|
|
priority.
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
This function is called only from the NuttX scheduling
|
|
logic. Interrupts will always be disabled when this
|
|
function is called.
|
|
</p>
|
|
|
|
<p><b>Inputs:</b></p>
|
|
<ul>
|
|
<li>
|
|
<code>tcb</code>: The TCB of the task that has been reprioritized
|
|
</li>
|
|
<li>
|
|
<code>priority</code>: The new task priority
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="_exit">4.1.11 <code>_exit()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void _exit(int status) noreturn_function;</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
This function causes the currently executing task to cease
|
|
to exist. This is a special case of task_delete().
|
|
</p>
|
|
<p>
|
|
Unlike other UP APIs, this function may be called
|
|
directly from user programs in various states. The
|
|
implementation of this function should diable interrupts
|
|
before performing scheduling operations.
|
|
</p>
|
|
|
|
<h3><a name="upassert">4.1.12 <code>up_assert()</code></a></h3>
|
|
<p><b>Prototype</b>:<br>
|
|
<code>void up_assert(FAR const ubyte *filename, int linenum);</code></br>
|
|
<code>void up_assert_code(FAR const ubyte *filename, int linenum, int error_code);</code></br>
|
|
</p>
|
|
|
|
<p><b>Description</b>.
|
|
Assertions may be handled in an architecture-specific
|
|
way.
|
|
</p>
|
|
|
|
<h3><a name="upschedulesigaction">4.1.13 <code>up_schedule_sigaction()</code></a></h3>
|
|
<p><b>Prototype</b>:
|
|
<code>void up_schedule_sigaction(FAR _TCB *tcb, sig_deliver_t sigdeliver);</code>
|
|
</p>
|
|
|
|
<p><b>Description</b>.
|
|
This function is called by the OS when one or more
|
|
signal handling actions have been queued for execution.
|
|
The architecture specific code must configure things so
|
|
that the 'igdeliver' callback is executed on the thread
|
|
specified by 'tcb' as soon as possible.
|
|
</p>
|
|
<p>
|
|
This function may be called from interrupt handling logic.
|
|
</p>
|
|
<p>
|
|
This operation should not cause the task to be unblocked
|
|
nor should it cause any immediate execution of sigdeliver.
|
|
Typically, a few cases need to be considered:
|
|
</p>
|
|
<ol>
|
|
<li>
|
|
This function may be called from an interrupt handler
|
|
During interrupt processing, all xcptcontext structures
|
|
should be valid for all tasks. That structure should
|
|
be modified to invoke sigdeliver() either on return
|
|
from (this) interrupt or on some subsequent context
|
|
switch to the recipient task.
|
|
</li>
|
|
<li>
|
|
If not in an interrupt handler and the tcb is NOT
|
|
the currently executing task, then again just modify
|
|
the saved xcptcontext structure for the recipient
|
|
task so it will invoke sigdeliver when that task is
|
|
later resumed.
|
|
</li>
|
|
<li>
|
|
If not in an interrupt handler and the tcb IS the
|
|
currently executing task -- just call the signal
|
|
handler now.
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
This API is <i>NOT</i> required if <code>CONFIG_DISABLE_SIGNALS</code>
|
|
is defined.
|
|
</p>
|
|
|
|
<h3><a name="upallocateheap">4.1.14 <code>up_allocate_heap()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void up_allocate_heap(FAR void **heap_start, size_t *heap_size);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
The heap may be statically allocated by
|
|
defining CONFIG_HEAP_BASE and CONFIG_HEAP_SIZE. If these
|
|
are not defined, then this function will be called to
|
|
dynamically set aside the heap region.
|
|
</p>
|
|
<p>
|
|
This API is <i>NOT</i> required if <code>CONFIG_HEAP_BASE</code>
|
|
is defined.
|
|
</p>
|
|
|
|
<h3><a name="upinterruptcontext">4.1.15 <code>up_interrupt_context()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>boolean up_interrupt_context(void)</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
Return TRUE is we are currently executing in
|
|
the interrupt handler context.
|
|
</p>
|
|
|
|
<h3><a name="updisableirq">4.1.16 <code>up_disable_irq()</code></a></h3>
|
|
<p><b>Prototype</b>:</p>
|
|
<ul><pre>
|
|
#ifndef CONFIG_ARCH_NOINTC
|
|
void up_disable_irq(int irq);
|
|
#endf
|
|
</pre></ul>
|
|
|
|
<p><b>Description</b>.
|
|
Disable the IRQ specified by 'irq'
|
|
On many architectures, there are three levels of interrupt enabling: (1)
|
|
at the global level, (2) at the level of the interrupt controller,
|
|
and (3) at the device level. In order to receive interrupts, they
|
|
must be enabled at all three levels.
|
|
</p>
|
|
<p>
|
|
This function implements enabling of the device specified by 'irq'
|
|
at the interrupt controller level if supported by the architecture
|
|
(irqsave() supports the global level, the device level is hardware
|
|
specific).
|
|
<p>
|
|
If the architecture does not support <code>up_disable_irq</code>,
|
|
<code>CONFIG_ARCH_NOINTC</code> should be defined in the NuttX configuration file.
|
|
Since this API cannot be supported on all architectures, it should be
|
|
avoided in common implementations where possible.
|
|
</p>
|
|
|
|
<h3><a name="upenableirq">4.1.17 <code>up_enable_irq()</code></a></h3>
|
|
<p><b>Prototype</b>:</p>
|
|
<ul><pre>
|
|
#ifndef CONFIG_ARCH_NOINTC
|
|
void up_enable_irq(int irq);
|
|
#endf
|
|
</pre></ul>
|
|
|
|
<p><b>Description</b>.
|
|
This function implements disabling of the device specified by 'irq'
|
|
at the interrupt controller level if supported by the architecture
|
|
(irqrestore() supports the global level, the device level is hardware
|
|
specific).
|
|
</p>
|
|
<p>
|
|
If the architecture does not support <code>up_disable_irq</code>,
|
|
<code>CONFIG_ARCH_NOINTC</code> should be defined in the NuttX configuration file.
|
|
Since this API cannot be supported on all architectures, it should be
|
|
avoided in common implementations where possible.
|
|
</p>
|
|
|
|
<h3><a name="upprioritizeirq">4.1.18 <code>up_prioritize_irq()</code></a></h3>
|
|
<p><b>Prototype</b>:</p>
|
|
<ul><pre>
|
|
#ifdef CONFIG_ARCH_IRQPRIO
|
|
void up_enable_irq(int irq);
|
|
#endf
|
|
</pre></ul>
|
|
<p><b>Description</b>.
|
|
Set the priority of an IRQ.
|
|
</p>
|
|
<p>
|
|
If the architecture supports <code>up_enable_irq</code>,
|
|
<code>CONFIG_ARCH_IRQPRIO</code> should be defined in the NuttX configuration file.
|
|
Since this API cannot be supported on all architectures, it should be
|
|
avoided in common implementations where possible.
|
|
</p>
|
|
|
|
<h3><a name="upputc">4.1.19 <code>up_putc()</code></a></h3>
|
|
|
|
<p><b>Prototype</b>: <code>int up_putc(int ch);</code></p>
|
|
<p><b>Description</b>.
|
|
This is a debug interface exported by the architecture-specific logic.
|
|
Output one character on the console
|
|
</p>
|
|
|
|
<h2><a name="exports">4.2 APIs Exported by NuttX to Architecture-Specific Logic</a></h2>
|
|
<p>
|
|
These are standard interfaces that are exported by the OS
|
|
for use by the architecture specific logic.
|
|
</p>
|
|
|
|
<h3><a name="osstart">4.2.1 <code>os_start()</code></a></h3>
|
|
<p>
|
|
<b><i>To be provided</i></b>
|
|
</p>
|
|
|
|
<h3><a name="listmgmt">4.2.2 OS List Management APIs</a></h3></h3>
|
|
<p>
|
|
<b><i>To be provided</i></b>
|
|
</p>
|
|
|
|
<h3><a name="schedprocesstimer">4.2.3 <code>sched_process_timer()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void sched_process_timer(void);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
This function handles system timer events.
|
|
The timer interrupt logic itself is implemented in the
|
|
architecture specific code, but must call the following OS
|
|
function periodically -- the calling interval must be
|
|
<code>MSEC_PER_TICK</code>.
|
|
</p>
|
|
|
|
<h3><a name="irqdispatch">4.2.4 <code>irq_dispatch()</code></a></h3>
|
|
<p><b>Prototype</b>: <code>void irq_dispatch(int irq, FAR void *context);</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
This function must be called from the achitecture-
|
|
specific logic in order to dispaly an interrupt to
|
|
the appropriate, registered handling logic.
|
|
</p>
|
|
|
|
<h2><a name="ledsupport">4.3 LED Support</a></h2>
|
|
|
|
<p>
|
|
A board architecture may or may not have LEDs.
|
|
If the board does have LEDs, then most architectures provide similar LED support that is enabled when <code>CONFIG_ARCH_LEDS</code>
|
|
is selected in the NuttX configuration file.
|
|
This LED support is part of architecture-specific logic and is not managed by the core NuttX logic.
|
|
However, the support provided by each architecture is sufficiently similar that it can be documented here.
|
|
</p>
|
|
|
|
<h3><a name="ledheaders">4.3.1 Header Files</a></h3>
|
|
|
|
<p>
|
|
LED-related definitions are provided in two header files:
|
|
<ul>
|
|
<li>
|
|
LED definitions are provided for each board in the <code>board.h</code> that resides
|
|
in the <code><i><board-name></i>/include/board.h</code> file (which is also
|
|
linked to <code>include/arch/board/board.h</code> when the RTOS is configured).
|
|
Those definitions are discussed <a href="#leddefinitions">below</a>.
|
|
</li>
|
|
<li>
|
|
The board-specific logic provides unique instances of the LED interfaces.
|
|
This is because the implementation of LED support may be very different
|
|
on different boards.
|
|
Prototypes for these board-specific implementations are, however, provided
|
|
in architecture-common header files.
|
|
That header file is usually at <code><i><arch-name></i>/src/common/up_internal.h</code>,
|
|
but could be at other locations in particular architectures.
|
|
These prototypes are discussed <a href="#ledapis">below</a>.
|
|
</li>
|
|
</ul>
|
|
</p>
|
|
|
|
<h3><a name="leddefinitions">4.3.2 LED Definitions</a></h3>
|
|
|
|
<p>
|
|
The implementation of LED support is very specific to a board architecture.
|
|
Some boards have several LEDS, others have only one or two.
|
|
Some have none.
|
|
Others LED matrices and show alphnumeric data, etc.
|
|
The NuttX logic does not refer to specific LEDS, rather, it refers to an event to be shown on the LEDS
|
|
in whatever manner is appropriate for the board;
|
|
the way that this event is presented depends upon the hardware available on the board.
|
|
</p>
|
|
<p>
|
|
The model used by NuttX is that the board can show 8 events defined as follows in <code><i><board-name></i>/include/board.h</code>:
|
|
</p>
|
|
<ul><pre>
|
|
#define LED_STARTED ??
|
|
#define LED_HEAPALLOCATE ??
|
|
#define LED_IRQSENABLED ??
|
|
#define LED_STACKCREATED ??
|
|
#define LED_INIRQ ??
|
|
#define LED_SIGNAL ??
|
|
#define LED_ASSERTION ??
|
|
#define LED_PANIC ??
|
|
</pre></ul>
|
|
<p>
|
|
The specific value assigned to each pre-processor variable can be whatever makes the implementation easiest for the board logic.
|
|
The <i>meaning</i> associated with each definition is as follows:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>LED_STARTED</code> is the value that describes the setting of the LEDs when the LED logic is first initialized.
|
|
This LED value is set but never cleared.
|
|
</li>
|
|
<li>
|
|
<code>LED_HEAPALLOCATE</code> indicates that the NuttX heap has been configured.
|
|
This is an important place in the boot sequence because if the memory is configured wrong, it will probably crash leaving this LED setting.
|
|
This LED value is set but never cleared.
|
|
</li>
|
|
<li>
|
|
<code>LED_IRQSENABLED</code> indicates that interrupts have been enabled.
|
|
Again, during bring-up (or if there are hardware problems), it is very likely that the system may crash just when interrupts are enabled, leaving this setting on the LEDs.
|
|
This LED value is set but never cleared.
|
|
</li>
|
|
<li>
|
|
<code>LED_STACKCREATED</code> is set each time a new stack is created.
|
|
If set, it means that the system attempted to start at least one new thread.
|
|
This LED value is set but never cleared.
|
|
</li>
|
|
<li>
|
|
<code>LED_INIRQ</code> is set and cleared on entry and exit from each interrupt.
|
|
If interrupts are working okay, this LED will have a dull glow.
|
|
</li>
|
|
<li>
|
|
<code>LED_SIGNAL</code> is set and cleared on entry and exit from a signal handler.
|
|
Signal handlers are tricky so this is especially useful during bring-up or a new architecture.
|
|
</li>
|
|
<li>
|
|
<code>LED_ASSERTION</code> is set if an assertion occurs.
|
|
</li>
|
|
<li>
|
|
<code>LED_PANIC</code> will blink at around 1Hz if the system panics and hangs.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="ledapis">4.3.3 Common LED interfaces</a></h3>
|
|
|
|
<p>
|
|
The <code><i><arch-name></i>/src/common/up_internal.h</code> probably has definitions
|
|
like:
|
|
</p>
|
|
<ul><pre>
|
|
/* Defined in board/up_leds.c */
|
|
|
|
#ifdef CONFIG_ARCH_LEDS
|
|
extern void up_ledinit(void);
|
|
extern void up_ledon(int led);
|
|
extern void up_ledoff(int led);
|
|
#else
|
|
# define up_ledinit()
|
|
# define up_ledon(led)
|
|
# define up_ledoff(led)
|
|
#endif
|
|
</pre></ul>
|
|
<p>
|
|
Where:
|
|
<p>
|
|
<ul>
|
|
<li>
|
|
<code>void up_ledinit(void)</code> is called early in power-up initialization to initialize the LED hardware.
|
|
</li>
|
|
<li>
|
|
<code>up_ledon(int led)</code> is called to instantiate the LED presentation of the event.
|
|
The <code>led</code> argument is one of the definitions provided in <code><i><board-name></i>/include/board.h</code>.
|
|
</li>
|
|
<li>
|
|
<code>up_ledoff(int led</code>is called to terminate the LED presentation of the event.
|
|
The <code>led</code> argument is one of the definitions provided in <code><i><board-name></i>/include/board.h</code>.
|
|
Note that only <code>LED_INIRQ</code>, <code>LED_SIGNAL</code>, <code>LED_ASSERTION</code>, and <code>LED_PANIC</code>
|
|
indications are terminated.
|
|
</li>
|
|
</ul>
|
|
|
|
<table width ="100%">
|
|
<tr bgcolor="#e4e4e4">
|
|
<td>
|
|
<h1><a name="NxFileSystem">5.0 NuttX File System</a></h1>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p><b>Overview</b>.
|
|
NuttX includes an optional, scalable file system.
|
|
This file-system may be omitted altogther; NuttX does not depend on the presence
|
|
of any file system.
|
|
</p>
|
|
|
|
<p><b>Pseudo Root File System</b>.
|
|
Or, a simple <i>in-memory</i>, <i>psuedo</i> file system can be enabled.
|
|
This simple file system can be enabled setting the CONFIG_NFILE_DESCRIPTORS
|
|
option to a non-zero value (see <a href="#apndxconfigs">Appendix A</a>).
|
|
This is an <i>in-memory</i> file system because it does not require any
|
|
storage medium or block driver support.
|
|
Rather, file system contents are generated on-the-fly as referenced via
|
|
standard file system operations (open, close, read, write, etc.).
|
|
In this sense, the file system is <i>psuedo</i> file system (in the
|
|
same sense that the Linux <code>/proc</code> file system is also
|
|
referred to as a psuedo file system).
|
|
</p>
|
|
|
|
<p>
|
|
Any user supplied data or logic can be accessed via the psuedo-file system.
|
|
Built in support is provided for character and block <a href="#DeviceDrivers">drivers</a> in the
|
|
<code>/dev</code> psuedo file system directory.
|
|
</p>
|
|
|
|
<p><b>Mounted File Systems</b>
|
|
The simple in-memory file system can be extended my mounting block
|
|
devices that provide access to true file systems backed up via some
|
|
mass storage device.
|
|
NuttX supports the standard <code>mount()</code> command that allows
|
|
a block driver to be bound to a mountpoint within the psuedo file system
|
|
and to a file system.
|
|
At present, NuttX supports only the VFAT file system.
|
|
</p>
|
|
|
|
<p><b>Comparison to Linux</b>
|
|
From a programming perspective, the NuttX file system appears very similar
|
|
to a Linux file system.
|
|
However, there is a fundamental difference:
|
|
The NuttX root file system is a psuedo file system and true file systems may be
|
|
mounted in the psuedo file system.
|
|
In the typical Linux installation by comparison, the Linux root file system
|
|
is a true file system and psuedo file systems may be mounted in the true,
|
|
root file system.
|
|
The approach selected by NuttX is intended to support greater scalability
|
|
from the very tiny platform to the moderate platform.
|
|
</p>
|
|
|
|
<table width ="100%">
|
|
<tr bgcolor="#e4e4e4">
|
|
<td>
|
|
<h1><a name="DeviceDrivers">6.0 NuttX Device Drivers</a></h1>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>
|
|
NuttX supports a variety of device drivers including:
|
|
<ul>
|
|
<li><i>Character</i> Device Drivers,</li>
|
|
<li><i>Block</i> Device Drivers, and</li>
|
|
<li>Other <i>Specialized</i> Drivers.</li>
|
|
</ul>
|
|
These different device driver types are discussed in the following paragraphs.
|
|
Note: device driver support requires that the <i>in-memory</i>, <i>psuedo</i> file system
|
|
is enabled by setting the CONFIG_NFILE_DESCRIPTORS in the NuttX configuration file to a
|
|
non-zero value.
|
|
</p>
|
|
|
|
<h2><a name="chardrivers">6.1 Character Device Drivers</a></h2>
|
|
|
|
<p>
|
|
Character device drivers have these properties:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<b><code>include/nuttx/fs.h</code></b>.
|
|
All structures and APIs needed to work with character drivers are provided in this header file.
|
|
</li>
|
|
<li>
|
|
<b><code>struct file_operations</code></b>.
|
|
Each character device driver must implement an instance of <code>struct file_operations</code>.
|
|
That structure defines a call table with the following methods:
|
|
<ul>
|
|
<p><code>int open(FAR struct file *filp);</code><br>
|
|
<code>int close(FAR struct file *filp);</code><br>
|
|
<code>ssize_t read(FAR struct file *filp, FAR char *buffer, size_t buflen);</code><br>
|
|
<code>ssize_t write(FAR struct file *filp, FAR const char *buffer, size_t buflen);</code><br>
|
|
<code>off_t seek(FAR struct file *filp, off_t offset, int whence);</code><br>
|
|
<code>int ioctl(FAR struct file *filp, int cmd, unsigned long arg);</code><br>
|
|
<code>int poll(FAR struct file *filp, struct pollfd *fds, boolean setup);</code></p>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<b><code>int register_driver(const char *path, const struct file_operations *fops, mode_t mode, void *priv);</code></b>.
|
|
Each character driver registers itself by calling <code>register_driver()</code>, passing it the
|
|
<code>path</code> where it will appear in the <a href="#NxFileSystem">pseudo-file-system</a> and it's
|
|
initialized instance of <code>struct file_operations</code>.
|
|
</li>
|
|
<li>
|
|
<b>User Access</b>.
|
|
After it has been registered, the character driver can be accessed by user code using the standard
|
|
<a href="NuttxUserGuide.html#driveroperations">driver operations</a> including
|
|
<code>open()</code>, <code>close()</code>, <code>read()</code>, <code>write()</code>, etc.
|
|
</li>
|
|
<li>
|
|
<b>Examples</b>:
|
|
<code>drivers/dev_null.c</code>, <code>drivers/fifo.c</code>, <code>drivers/serial.c</code>, etc.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2><a name="blockdrivers">6.2 Block Device Drivers</a></h2>
|
|
|
|
<p>
|
|
Block device drivers have these properties:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<b><code>include/nuttx/fs.h</code></b>.
|
|
All structures and APIs needed to work with block drivers are provided in this header file.
|
|
</li>
|
|
<li>
|
|
<b><code>struct block_operations</code></b>.
|
|
Each block device driver must implement an instance of <code>struct block_operations</code>.
|
|
That structure defines a call table with the following methods:
|
|
<ul>
|
|
<p><code>int open(FAR struct inode *inode);</code><br>
|
|
<code>int close(FAR struct inode *inode);</code><br>
|
|
<code>ssize_t read(FAR struct inode *inode, FAR unsigned char *buffer, size_t start_sector, unsigned int nsectors);</code><br>
|
|
<code>ssize_t write(FAR struct inode *inode, FAR const unsigned char *buffer, size_t start_sector, unsigned int nsectors);</code><br>
|
|
<code>int geometry(FAR struct inode *inode, FAR struct geometry *geometry);</code><br>
|
|
<code>int ioctl(FAR struct inode *inode, int cmd, unsigned long arg);</code></p>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<b><code>int register_blockdriver(const char *path, const struct block_operations *bops, mode_t mode, void *priv);</code></b>.
|
|
Each block driver registers itself by calling <code>register_blockdriver()</code>, passing it the
|
|
<code>path</code> where it will appear in the <a href="#NxFileSystem">pseudo-file-system</a> and it's
|
|
initialized instance of <code>struct block_operations</code>.
|
|
</li>
|
|
<li>
|
|
<b>User Access</b>.
|
|
Users do not normally access block drivers directly, rather, they access block drivers
|
|
indirectly through the <code>mount()</code> API.
|
|
The <code>mount()</code> API binds a block driver instance with a file system and with a mountpoint.
|
|
Then the user may use the block driver to access the file system on the underlying media.
|
|
<i>Example</i>: See the <code>cmd_mount()</code> implementation in <code>examples/nsh/nsh_fscmds.c</code>.
|
|
</li>
|
|
<li>
|
|
<b>Accessing a Character Driver as a Block Device</b>.
|
|
See the loop device at <code>drivers/loop.c</code>.
|
|
<i>Example</i>: See the <code>cmd_losetup()</code> implementation in <code>examples/nsh/nsh_fscmds.c</code>.
|
|
</li>
|
|
<li>
|
|
<b>Accessing a Block Driver as Character Device</b>.
|
|
See the Block-to-Character (BCH) conversion logic in <code>drivers/bch/</code>.
|
|
<i>Example</i>: See the <code>cmd_dd()</code> implementation in <code>examples/nsh/nsh_ddcmd.c</code>.
|
|
</li>
|
|
<li>
|
|
<b>Examples</b>.
|
|
<code>drivers/loop.c</code>, <code>drivers/mmcds/mmcsd_spi.c</code>, <code>drivers/ramdisk.c</code>, etc.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2><a name="blockdrivers">6.3 Specialized Device Drivers</a></h2>
|
|
|
|
<h3><a name="ethdrivers">6.3.1 Ethernet Device Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<b><code>include/net/uip/uip-arch.h</code></b>.
|
|
All structures and APIs needed to work with Ethernet drivers are provided in this header file.
|
|
The structure <code>struct uip_driver_s</code> defines the interface and is passed to uIP via
|
|
<code>netdev_register()</code>.
|
|
</li>
|
|
<li>
|
|
<b><code>int netdev_register(FAR struct uip_driver_s *dev);</code></b>.
|
|
Each Eterhenet driver registers itself by calling <code>netdev_register()</code>.
|
|
</li>
|
|
<li>
|
|
<b>Examples</b>:
|
|
<code>drivers/net/dm90x0.c</code>, <code>arch/drivers/arm/src/c5471/c5471_ethernet.c</code>, <code>arch/z80/src/ez80/ez80_emac.c</code>, etc.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="spidrivers">6.3.2 SPI Device Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<b><code>include/nuttx/spi.h</code></b>.
|
|
All structures and APIs needed to work with SPI drivers are provided in this header file.
|
|
</li>
|
|
<li>
|
|
<b><code>struct spi_ops_s</code></b>.
|
|
Each SPI device driver must implement an instance of <code>struct spi_ops_s</code>.
|
|
That structure defines a call table with the following methods:
|
|
<ul>
|
|
<p><code>void select(FAR struct spi_dev_s *dev, enum spi_dev_e devid, boolean selected);</code><br>
|
|
<code>uint32 setfrequency(FAR struct spi_dev_s *dev, uint32 frequency);</code><br>
|
|
<code>void setmode(FAR struct spi_dev_s *dev, enum spi_mode_e mode);</code><br>
|
|
<code>void setbits(FAR struct spi_dev_s *dev, int nbits);</code><br>
|
|
<code>ubyte status(FAR struct spi_dev_s *dev, enum spi_dev_e devid);</code><br>
|
|
<code>uint16 send(FAR struct spi_dev_s *dev, uint16 wd);</code><br>
|
|
<code>void exchange(FAR struct spi_dev_s *dev, FAR const void *txbuffer, FAR void *rxbuffer, size_t nwords);</code><br>
|
|
<p><codei>nt registercallback(FAR struct spi_dev_s *dev, mediachange_t callback, void *arg);</code></p>
|
|
</ul>
|
|
<li>
|
|
<b>Binding SPI Drivers</b>.
|
|
SPI drivers are not normally directly accessed by user code, but are usually bound to another,
|
|
higher level device driver.
|
|
See for example, <code>int mmcsd_spislotinitialize(int minor, int slotno, FAR struct spi_dev_s *spi)</code> in <code>drivers/mmcsd/mmcsd_spi.c</code>.
|
|
</li>
|
|
<li>
|
|
<b>Examples</b>:
|
|
<code>drivers/loop.c</code>, <code>drivers/mmcds/mmcsd_spi.c</code>, <code>drivers/ramdisk.c</code>, etc.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="i2cdrivers">6.3.3 I2C Device Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<b><code>include/nuttx/i2c.h</code></b>.
|
|
All structures and APIs needed to work with I2C drivers are provided in this header file.
|
|
</li>
|
|
<li>
|
|
<b><code>struct i2c_ops_s</code></b>.
|
|
Each I2C device driver must implement an instance of <code>struct i2c_ops_s</code>.
|
|
That structure defines a call table with the following methods:
|
|
<ul>
|
|
<p><code>uint32 setfrequency(FAR struct i2c_dev_s *dev, uint32 frequency);</code><br>
|
|
<code>int setaddress(FAR struct i2c_dev_s *dev, int addr, int nbits);</code><br>
|
|
<code>int write(FAR struct i2c_dev_s *dev, const ubyte *buffer, int buflen);</code><br>
|
|
<code>int read(FAR struct i2c_dev_s *dev, ubyte *buffer, int buflen);</code></p>
|
|
</ul>
|
|
<li>
|
|
<b>Binding I2C Drivers</b>.
|
|
SPI drivers are not normally directly accessed by user code, but are usually bound to another,
|
|
higher level device driver.
|
|
</li>
|
|
<li>
|
|
<b>Examples</b>:
|
|
<code>arch/z80/src/ez80/ez80_i2c.c</code>, <code>arch/z80/src/z8/z8_i2c.c</code>, etc.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="serialdrivers">6.3.4 Serial Device Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<b><code>include/nuttx/serial.h</code></b>.
|
|
All structures and APIs needed to work with serial drivers are provided in this header file.
|
|
</li>
|
|
<li>
|
|
<b><code>struct uart_ops_s</code></b>.
|
|
Each serial device driver must implement an instance of <code>struct uart_ops_s</code>.
|
|
That structure defines a call table with the following methods:
|
|
<ul>
|
|
<p><code>int setup(FAR struct uart_dev_s *dev);</code><br>
|
|
<code>void shutdown(FAR struct uart_dev_s *dev);</code><br>
|
|
<code>int attach(FAR struct uart_dev_s *dev);</code><br>
|
|
<code>void detach(FAR struct uart_dev_s *dev);</code><br>
|
|
<code>int ioctl(FAR struct file *filep, int cmd, unsigned long arg);</code><br>
|
|
<code>int receive(FAR struct uart_dev_s *dev, unsigned int *status);</code><br>
|
|
<code>void rxint(FAR struct uart_dev_s *dev, boolean enable);</code><br>
|
|
<code>boolean rxavailable(FAR struct uart_dev_s *dev);</code><br>
|
|
<code>void send(FAR struct uart_dev_s *dev, int ch);</code><br>
|
|
<code>void txint(FAR struct uart_dev_s *dev, boolean enable);</code><br>
|
|
<code>boolean txready(FAR struct uart_dev_s *dev);</code><br>
|
|
<code>boolean txempty(FAR struct uart_dev_s *dev);</code></p>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<b><code>int uart_register(FAR const char *path, FAR uart_dev_t *dev);</code></b>.
|
|
A serial driver may register itself by calling <code>uart_register()</code>, passing it the
|
|
<code>path</code> where it will appear in the <a href="#NxFileSystem">pseudo-file-system</a> and it's
|
|
initialized instance of <code>struct uart_ops_s</code>.
|
|
By convention, serial device drivers are registered at pathes like <code>/dev/ttyS0</code>, <code>/dev/ttyS1</code>, etc.
|
|
See the <code>uart_register()</code> implementation in <code>drivers/serial.c</code>.
|
|
</li>
|
|
<li>
|
|
<b>User Access</b>.
|
|
Serial drivers are, ultimately, normal <a href="#chardrivers">character drivers</a> and are accessed as other character drivers.
|
|
</li>
|
|
<li>
|
|
<b>Examples</b>:
|
|
<code>arch/arm/src/chip/lm3s_serial.c</code>, <code>arch/arm/src/lpc214x/lpc214x_serial.c</code>, <code>arch/z16/src/z16f/z16f_serial.c</code>, etc.
|
|
</li>
|
|
</ul>
|
|
|
|
<table width ="100%">
|
|
<tr bgcolor="#e4e4e4">
|
|
<td>
|
|
<h1><a name="apndxconfigs">Appendix A: NuttX Configuration Settings</a></h1>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>
|
|
The following variables are recognized by the build (you may
|
|
also include architecture-specific settings).
|
|
</p>
|
|
|
|
<h2>Architecture selection</h2>
|
|
<p>
|
|
The following configuration itemes select the architecture, chip, and
|
|
board configuration for the build.
|
|
</p>
|
|
<ul>
|
|
<li><code>CONFIG_ARCH</code>:
|
|
Identifies the arch subdirectory</li>
|
|
<li><code>CONFIG_ARCH_name</code>:
|
|
For use in C code</li>
|
|
<li><code>CONFIG_ARCH_CHIP</code>:
|
|
Identifies the arch/*/chip subdirectory</li>
|
|
<li><code>CONFIG_ARCH_CHIP_name</code>:
|
|
For use in C code</li>
|
|
<li><code>CONFIG_ARCH_BOARD</code>:
|
|
Identifies the configs subdirectory and hence, the board that supports
|
|
the particular chip or SoC.</li>
|
|
<li><code>CONFIG_ARCH_BOARD_name</code>:
|
|
For use in C code</li>
|
|
<li><code>CONFIG_ENDIAN_BIG</code>:
|
|
Define if big endian (default is little endian).</li>
|
|
<li><code>CONFIG_ARCH_NOINTC</code>:
|
|
Define if the architecture does not support an interrupt controller
|
|
or otherwise cannot support APIs like up_enable_irq() and up_disable_irq().</li>
|
|
<li><code>CONFIG_ARCH_IRQPRIO</code>:
|
|
Define if the architecture suports prioritizaton of interrupts and the
|
|
up_prioritize_irq() API.</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Some architectures require a description of the RAM configuration:
|
|
</p>
|
|
<ul>
|
|
<li><code>CONFIG_DRAM_SIZE</code>:
|
|
Describes the installed DRAM.</li>
|
|
<li><code>CONFIG_DRAM_START</code>:
|
|
The start address of DRAM (physical)</li>
|
|
<li><code>CONFIG_DRAM_VSTART</code>:
|
|
The start address of DRAM (virtual)</li>
|
|
</ul>
|
|
|
|
<p>
|
|
General build options:
|
|
</p>
|
|
<ul>
|
|
<li><code>CONFIG_RRLOAD_BINARY</code>:
|
|
Make the rrload binary format used with BSPs from <a href="www.ridgerun.com">ridgerun.com</a>
|
|
using the <code>tools/mkimage.sh</code> script.
|
|
</li>
|
|
<li><code>CONFIG_INTELHEX_BINARY</code>:
|
|
Make the Intel HEX binary format used with many different loaders using the GNU objcopy program
|
|
This option hould not be selected if you are not using the GNU toolchain.
|
|
</li>
|
|
<li><code>CONFIG_MOTOROLA_SREC</code>:
|
|
Make the Motorola S-Record binary format used with many different loaders using the GNU objcopy program
|
|
Should not be selected if you are not using the GNU toolchain.
|
|
</li>
|
|
<li><code>CONFIG_RAW_BINARY</code>:
|
|
mmke a raw binary format file used with many different loaders using the GNU objcopy program.
|
|
This option should not be selected if you are not using the GNU toolchain.
|
|
</li>
|
|
<li><code>CONFIG_HAVE_LIBM</code>:
|
|
Toolchain supports libm.a
|
|
</li>
|
|
<li><code>CONFIG_HAVE_CXX</code>:
|
|
Toolchain supports C++ and <code>CXX</code>, <code>CXXFLAGS</code>, and <code>COMPILEXX</code>
|
|
have been defined in the configuratins <code>Make.defs</code> file.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>General OS setup</h2>
|
|
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_EXAMPLE</code>: identifies the subdirectory in examples
|
|
that will be used in the build.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEBUG</code>: enables built-in debug options
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEBUG_VERBOSE</code>: enables verbose debug output
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEBUG_SCHED</code>: enable OS debug output (disabled by default)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEBUG_MM</code>: enable memory management debug output (disabld by default)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEBUG_NET</code>: enable network debug output (disabled by default)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEBUG_FS</code>: enable file system debug output (disabled by default)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEBUG_LIB</code>: enable C library debug output (disabled by default)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_ARCH_LOWPUTC</code>: architecture supports low-level, boot
|
|
time console output
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_MM_REGIONS</code>: If the architecture includes multiple
|
|
regions of memory to allocate from, this specifies the
|
|
number of memory regions that the memory manager must
|
|
handle and enables the API mm_addregion(start, end);
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_TICKS_PER_MSEC</code>: The default system timer is 100Hz
|
|
or <code>TICKS_PER_MSEC</code>=10. This setting may be defined to inform NuttX
|
|
that the processor hardware is providing system timer interrupts at some interrupt
|
|
interval other than 10 msec.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_RR_INTERVAL</code>: The round robin timeslice will be set
|
|
this number of milliseconds; Round robin scheduling can
|
|
be disabled by setting this value to zero.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SCHED_INSTRUMENTATION</code>: enables instrumentation in
|
|
scheduler to monitor system performance
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_TASK_NAME_SIZE</code>: Spcifies that maximum size of a
|
|
task name to save in the TCB. Useful if scheduler
|
|
instrumentation is selected. Set to zero to disable.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_START_YEAR, CONFIG_START_MONTH, CONFIG_START_DAY -
|
|
Used to initialize the internal time logic.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_JULIAN_TIME</code>: Enables Julian time conversions
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEV_CONSOLE</code>: Set if architecture-specific logic
|
|
provides /dev/console. Enables stdout, stderr, stdin.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_MUTEX_TYPES</code>: Set to enable support for recursive and
|
|
errorcheck mutexes. Enables <code>pthread_mutexattr_settype()</code>.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PRIORITY_INHERITANCE</code>: Set to enable support for
|
|
priority inheritance on mutexes and semaphores.
|
|
Priority inheritance is a strategy of addessing
|
|
<a href="NuttxUserGuide.html#priorityinversion"><i>priority inversion</i></a>.
|
|
Details of the NuttX implementation of priority inheritance is
|
|
discussed <a href="NuttxUserGuide.html#priorityinheritance">elsewhere</a>.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SEM_PREALLOCHOLDERS</code>: This setting is only used
|
|
if priority inheritance is enabled.
|
|
It defines the maximum number of different threads (minus one) that
|
|
can take counts on a semaphore with priority inheritance support.
|
|
This may be set to zero if priority inheritance is disabled OR if you
|
|
are only using semaphores as mutexes (only one holder) OR if no more
|
|
than two threads participate using a counting semaphore.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SEM_NNESTPRIO</code>: If priority inheritance is enabled,
|
|
then this setting is the maximum number of higher priority threads (minus
|
|
1) than can be waiting for another thread to release a count on a semaphore.
|
|
This value may be set to zero if no more than one thread is expected to
|
|
wait for a semaphore.
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
The following can be used to disable categories of APIs supported
|
|
by the OS. If the compiler supports weak functions, then it
|
|
should not be necessary to disable functions unless you want to
|
|
restrict usage of those APIs.
|
|
</p>
|
|
<p>
|
|
There are certain dependency relationships in these features.
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>mq_notify()</code> logic depends on signals to awaken tasks
|
|
waiting for queues to become full or empty.
|
|
</li>
|
|
<li>
|
|
<code>pthread_condtimedwait()</code> depends on signals to wake
|
|
up waiting tasks.
|
|
</li>
|
|
</ul>
|
|
|
|
<ul>
|
|
<code>CONFIG_DISABLE_CLOCK</code>, <code>CONFI_DISABLE_POSIX_TIMERS</code>,
|
|
<code>CONFIG_DISABLE_PTHREAD</code>, <code>CONFIG_DISABLE_SIGNALS</code>,
|
|
<code>CONFIG_DISABLE_MQUEUE</code>, <code>CONFIG_DISABLE_MOUNTPOUNT</code>
|
|
</ul>
|
|
|
|
<h2>Miscellaneous libc settings</h2>
|
|
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NOPRINTF_FIELDWIDTH</code>: sprintf-related logic is a
|
|
little smaller if we do not support fieldwidthes
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>Allow for architecture optimized implementations</h2>
|
|
|
|
<p>
|
|
The architecture can provide optimized versions of the
|
|
following to improve sysem performance.
|
|
</p>
|
|
|
|
<ul>
|
|
<p>
|
|
<code>CONFIG_ARCH_MEMCPY</code>, <code>CONFIG_ARCH_MEMCMP</code>, <code>CONFIG_ARCH_MEMMOVE</code>,
|
|
<code>CONFIG_ARCH_MEMSET</code>, <code>CONFIG_ARCH_STRCMP</code>, <code>CONFIG_ARCH_STRCPY</code>,
|
|
<code>CONFIG_ARCH_STRNCPY</code>, <code>CONFIG_ARCH_STRLEN</code>, <code>CONFIG_ARCH_BZERO</code>,
|
|
<code>CONFIG_ARCH_KMALLOC</code>, <code>CONFIG_ARCH_KZMALLOC</code>, <code>ONFIG_ARCH_KFREE</code>,
|
|
</p>
|
|
</ul>
|
|
|
|
<h2>Sizes of configurable things (0 disables)</h2>
|
|
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_MAX_TASKS</code>: The maximum number of simultaneously
|
|
active tasks. This value must be a power of two.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NPTHREAD_KEYS</code>: The number of items of thread-
|
|
specific data that can be retained
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NFILE_DESCRIPTORS</code>: The maximum number of file
|
|
descriptors (one for each open)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NFILE_STREAMS</code>: The maximum number of streams that
|
|
can be fopen'ed
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NAME_MAX</code>: The maximum size of a file name.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_STDIO_BUFFER_SIZE</code>: Size of the buffer to allocate
|
|
on fopen. (Only if CONFIG_NFILE_STREAMS > 0)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NUNGET_CHARS</code>: Number of characters that can be
|
|
buffered by ungetc() (Only if CONFIG_NFILE_STREAMS > 0)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PREALLOC_MQ_MSGS</code>: The number of pre-allocated message
|
|
structures. The system manages a pool of preallocated
|
|
message structures to minimize dynamic allocations
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_MQ_MAXMSGSIZE</code>: Message structures are allocated with
|
|
a fixed payload size given by this settin (does not include
|
|
other message structure overhead.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PREALLOC_WDOGS</code>: The number of pre-allocated watchdog
|
|
structures. The system manages a pool of preallocated
|
|
watchdog structures to minimize dynamic allocations
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEV_PIPE_SIZE</code>: Size, in bytes, of the buffer to allocated
|
|
for pipe and FIFO support (default is 1024).
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>File Systems</h2>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_FS_FAT</code>: Enable FAT filesystem support.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_FAT_SECTORSIZE</code>: Max supported sector size.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_FS_ROMFS</code>: Enable ROMFS filesystem support
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>SPI-based MMC/SD driver</h2>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_MMCSD_NSLOTS</code>: Number of MMC/SD slots supported by the driver. Default is one.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_MMCSD_READONLY</code>: Provide read-only access. Default is Read/Write
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>Network Support</h2>
|
|
<h3>TCP/IP and UDP support via uIP</h2>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NET</code>: Enable or disable all network features
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_IPv6</code>: Build in support for IPv6
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NSOCKET_DESCRIPTORS</code>: Maximum number of socket descriptors per task/thread.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_NACTIVESOCKETS</code>: Maximum number of concurrent socket operations (recv, send, etc.).
|
|
Default: <code>CONFIG_NET_TCP_CONNS</code>+<code>CONFIG_NET_UDP_CONNS</code>.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_SOCKOPTS</code>: Enable or disable support for socket options.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_BUFSIZE</code>: uIP buffer size
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_TCP</code>: TCP support on or off
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_TCP_CONNS</code>: Maximum number of TCP connections (all tasks).
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_TCPBACKLOG</code>:
|
|
Incoming connections pend in a backlog until <code>accept()</code> is called.
|
|
The size of the backlog is selected when <code>listen()</code> is called.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_TCP_READAHEAD_BUFSIZE</code>: Size of TCP read-ahead buffers
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_NTCP_READAHEAD_BUFFERS</code>: Number of TCP read-ahead buffers (may be zero)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_MAX_LISTENPORTS</code>: Maximum number of listening TCP ports (all tasks).
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_TCPURGDATA</code>: Determines if support for TCP urgent data
|
|
notification should be compiled in. Urgent data (out-of-band data)
|
|
is a rarely used TCP feature that is very seldom would be required.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_UDP</code>: UDP support on or off
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_UDP_CHECKSUMS</code>: UDP checksums on or off
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_UDP_CONNS</code>: The maximum amount of concurrent UDP connections
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_ICMP</code>: Enable minimal ICMP support. Includes built-in support
|
|
for sending replies to received ECHO (ping) requests.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_ICMP_PING</code>: Provide interfaces to support application level
|
|
support for sending ECHO (ping) requests and associating ECHO replies.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_PINGADDRCONF</code>: Use "ping" packet for setting IP address
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_STATISTICS</code>: uIP statistics on or off
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_RECEIVE_WINDOW</code>: The size of the advertised receiver's window
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_ARPTAB_SIZE</code>: The size of the ARP table
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_BROADCAST</code>: Incoming UDP broadcast support
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_MULTICAST</code>: Outgoing multi-cast address support
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_LLH_LEN</code>: The link level header length
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_FWCACHE_SIZE</code>: number of packets to remember when looking for duplicates
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>UIP Network Utilities</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NET_DHCP_LIGHT</code>: Reduces size of DHCP
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_RESOLV_ENTRIES</code>: Number of resolver entries
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>USB Device-Side Support</h2>
|
|
<h3>USB Device Controller Driver</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_USBDEV</code>: Enables USB device support
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBDEV_ISOCHRONOUS</code>: Build in extra support for isochronous endpoints
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBDEV_DUALSPEED</code>: Hardware handles high and full speed operation (USB 2.0)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBDEV_SELFPOWERED</code>: Will cause USB features to indicate that the device is self-powered
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBDEV_MAXPOWER</code>: Maximum power consumption in mA
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBDEV_TRACE</code>: Enables USB tracing for debug
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBDEV_TRACE_NRECORDS</code>: Number of trace entries to remember
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>USB Serial Device Class Driver</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_USBSER</code>: Enable compilation of the USB serial driver
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSER_EPINTIN</code>: The logical 7-bit address of a hardware endpoint that supports interrupt IN operation
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSER_EPBULKOUT</code>: The logical 7-bit address of a hardware endpoint that supports bulk OUT operation
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSER_EPBULKIN</code>: The logical 7-bit address of a hardware endpoint that supports bulk IN operation
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSER_NWRREQS</code> and <code>CONFIG_USBSER_NRDREQS</code>: The number of write/read requests that can be in flight
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSER_VENDORID</code> and <code>CONFIG_USBSER_VENDORSTR</code>: The vendor ID code/string
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSER_PRODUCTID</code> and <code>CONFIG_USBSER_PRODUCTSTR</code>: The product ID code/string
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSER_RXBUFSIZE</code> and <code>CONFIG_USBSER_TXBUFSIZE</code>: Size of the serial receive/transmit buffers
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>USB Storage Device Configuration</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_USBSTRG</code>:
|
|
Enable compilation of the USB storage driver
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSTRG_EP0MAXPACKET</code>:
|
|
Max packet size for endpoint 0
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSTRGEPBULKOUT</code> and <code>CONFIG_USBSTRG_EPBULKIN</code>:
|
|
The logical 7-bit address of a hardware endpoints that support bulk OUT and IN operations
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSTRG_NWRREQS</code> and <code>CONFIG_USBSTRG_NRDREQS</code>:
|
|
The number of write/read requests that can be in flight
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSTRG_BULKINREQLEN</code> and <code>CONFIG_USBSTRG_BULKOUTREQLEN</code>:
|
|
The size of the buffer in each write/read request.
|
|
This value needs to be at least as large as the endpoint maxpacket and
|
|
ideally as large as a block device sector.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSTRG_VENDORID</code> and <code>CONFIG_USBSTRG_VENDORSTR</code>:
|
|
The vendor ID code/string
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSTRG_PRODUCTID</code> and <code>CONFIG_USBSTRG_PRODUCTSTR</code>:
|
|
The product ID code/string
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBSTRG_REMOVABLE</code>:
|
|
Select if the media is removable
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>Graphics related configuration settings</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NX</code>
|
|
Enables overall support for graphics library and NX
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>NX configuration setting</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NX_MULTIUSER</code>:
|
|
Configures NX in multi-user mode.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NX_NPLANES</code>:
|
|
Some YUV color formats requires support for multiple planes,
|
|
one for each color component. Unless you have such special
|
|
hardware, this value should be undefined or set to 1.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NX_DISABLE_1BPP</code>, <code>CONFIG_NX_DISABLE_2BPP</code>,
|
|
<code>CONFIG_NX_DISABLE_4BPP</code>, <code>CONFIG_NX_DISABLE_8BPP</code>
|
|
<code>CONFIG_NX_DISABLE_16BPP</code>, <code>CONFIG_NX_DISABLE_24BPP</code>, and
|
|
<code>CONFIG_NX_DISABLE_32BPP</code>:
|
|
NX supports a variety of pixel depths. You can save some
|
|
memory by disabling support for unused color depths.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NX_PACKEDMSFIRST</code>:
|
|
If a pixel depth of less than 8-bits is used, then NX needs
|
|
to know if the pixels pack from the MS to LS or from LS to MS
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NX_MOUSE</code>:
|
|
Build in support for mouse input.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NX_KBD</code>:
|
|
Build in support of keypad/keyboard input.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NXTK_BORDERWIDTH</code>:
|
|
Specifies with with of the border (in pixels) used with
|
|
framed windows. The default is 4.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NXTK_BORDERCOLOR1</code> and <code>CONFIG_NXTK_BORDERCOLOR2</code>:
|
|
Specify the colors of the border used with framed windows.
|
|
<code>CONFIG_NXTK_BORDERCOLOR2</code> is the shadow side color and so
|
|
is normally darker. The default is medium and dark grey,
|
|
respectively
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NXTK_AUTORAISE</code>:
|
|
If set, a window will be raised to the top if the mouse position
|
|
is over a visible portion of the window. Default: A mouse
|
|
button must be clicked over a visible portion of the window.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NXFONTS_CHARBITS</code>:
|
|
The number of bits in the character set. Current options are
|
|
only 7 and 8. The default is 7.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NXFONT_SANS</code>:
|
|
At present, there is only one font. But if there were were more,
|
|
then this option would select the sans serif font.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>NX Multi-user only options</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NX_BLOCKING</code>
|
|
Open the client message queues in blocking mode. In this case,
|
|
<code>nx_eventhandler()</code> will not return until a message is received and processed.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NX_MXSERVERMSGS</code> and <code>CONFIG_NX_MXCLIENTMSGS</code>
|
|
Specifies the maximum number of messages that can fit in
|
|
the message queues. No additional resources are allocated, but
|
|
this can be set to prevent flooding of the client or server with
|
|
too many messages (<code>CONFIG_PREALLOC_MQ_MSGS</code> controls how many
|
|
messages are pre-allocated).
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>Stack and heap information</h2>
|
|
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_BOOT_RUNFROMFLASH</code>: Some configurations support XIP
|
|
operation from FLASH but must copy initialized .data sections to RAM.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_BOOT_COPYTORAM</code>: Some configurations boot in FLASH
|
|
but copy themselves entirely into RAM for better performance.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_STACK_POINTER</code>: The initial stack pointer
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_IDLETHREAD_STACKSIZE</code>: The size of the initial stack.
|
|
This is the thread that (1) performs the inital boot of the system up
|
|
to the point where user_start() is spawned, and (2) there after is the
|
|
IDLE thread that executes only when there is no other thread ready to
|
|
run.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USERMAIN_STACKSIZE</code>: The size of the stack to allocate
|
|
for the main user thread that begins at the user_start() entry point.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PTHREAD_STACK_MIN</code>: Minimum pthread stack size
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PTHREAD_STACK_DEFAULT</code>: Default pthread stack size
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_HEAP_BASE</code>: The beginning of the heap
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_HEAP_SIZE</code>: The size of the heap
|
|
</li>
|
|
</ul>
|
|
|
|
<table width ="100%">
|
|
<tr bgcolor="#e4e4e4">
|
|
<td>
|
|
<h1><a name="apndxtrademarks">Appendix B: Trademarks</a></h1>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<li>ARM, ARM7 ARM7TDMI, ARM9, ARM920T, ARM926EJS, Cortex-M3 are trademarks of Advanced RISC Machines, Limited.</li>
|
|
<li>Cygwin is a trademark of Red Hat, Incorporated.</li>
|
|
<li>Linux is a registered trademark of Linus Torvalds.</li>
|
|
<li>Eagle-100 is a trademark of <a href=" http://www.micromint.com/">Micromint USA, LLC</a>.
|
|
<li>LPC2148 is a trademark of NXP Semiconductors.</li>
|
|
<li>TI is a tradename of Texas Instruments Incorporated.</li>
|
|
<li>UNIX is a registered trademark of The Open Group.</li>
|
|
<li>VxWorks is a registered trademark of Wind River Systems, Incorporated.</li>
|
|
<li>ZDS, ZNEO, Z16F, Z80, and Zilog are a registered trademark of Zilog, Inc.</li>
|
|
|
|
<p>
|
|
NOTE: NuttX is <i>not</i> licensed to use the POSIX trademark. NuttX uses the POSIX
|
|
standard as a development guideline only.
|
|
</p>
|
|
|
|
</body>
|
|
</html>
|
|
|
|
|