4108 lines
154 KiB
HTML
4108 lines
154 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: April 14, 2011</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="#DirStructBinFmt">2.3 binfmt/</a><br>
|
|
<a href="#DirStructConfigs">2.4 configs/</a>
|
|
<ul>
|
|
<a href="#configsdirectorystructure">2.4.1 Subdirectory Structure</a><br>
|
|
<a href="#summaryofconfigfiles">2.4.2 Summary of Files</a>
|
|
<ul>
|
|
<a href="#boardlogic">2.4.2.1 Board Specific Logic</a><br>
|
|
<a href="#boardconfigsubdirs">2.4.2.2 Board Specific Configuration Sub-Directories</a>
|
|
</ul>
|
|
<a href="#supportedboards">2.4.3 Supported Boards</a>
|
|
</ul>
|
|
<a href="#DirStructDrivers">2.5 nuttx/drivers/</a><br>
|
|
<a href="#DirStructFs">2.6 nuttx/fs/</a><br>
|
|
<a href="#DirStructGraphics">2.7 nuttx/graphics/</a><br>
|
|
<a href="#DirStructInclude">2.8 nuttx/include/</a><br>
|
|
<a href="#DirStructLib">2.9 nuttx/lib/</a><br>
|
|
<a href="#DirStructLibXX">2.10 nuttx/libxx/</a><br>
|
|
<a href="#DirStructMm">2.11 nuttx/mm/</a><br>
|
|
<a href="#DirStructNet">2.12 nuttx/net</a><br>
|
|
<a href="#DirStructSched">2.13 nuttx/sched/</a><br>
|
|
<a href="#DirStructSyscall">2.14 nuttx/syscall/</a><br>
|
|
<a href="#DirStructTools">2.15 nuttx/tools/</a><br>
|
|
<a href="#topmakefile">2.16 nuttx/Makefile</a>
|
|
<a href="#DirStructNetUtils">2.17 apps/netutils</a><br>
|
|
<a href="#DirStructNshLib">2.18 apps/nshlib</a><br>
|
|
<a href="#DirStructExamples">2.19 apps/examples/</a><br>
|
|
</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="#demandpaging">4.3 On-Demand Paging</a><br>
|
|
<a href="#ledsupport">4.4 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><br>
|
|
<a href="#fbdrivers">6.3.5 Frame Buffer Drivers</a><br>
|
|
<a href="#lcddrivers">6.3.6 LCD Drivers</a><br>
|
|
<a href="#mtddrivers">6.3.7 Memory Technology Device Drivers</a><br>
|
|
<a href="#sdiodrivers">6.3.8 SDIO Device Drivers</a><br>
|
|
<a href="#usbhostdrivers">6.3.9 USB Host-Side Drivers</a><br>
|
|
<a href="#usbdevdrivers">6.3.10 USB Device-Side Drivers</a><br>
|
|
</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>
|
|
.
|
|
|- nuttx
|
|
| |-- <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="#DirStructBinFmt">binfmt</a>/
|
|
| | |-- Makefile
|
|
| | |-- <i>(binfmt-specific sub-directories)</i>/
|
|
| | | `-- <i>(binfmt-specific source files)</i>
|
|
| | `-- <i>(common binfmt source files)</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="#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="#DirStructLibXX">libxx</a>/
|
|
| | |-- Makefile
|
|
| | `-- <i>(libxx management 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="#DirStructSched">sched</a>/
|
|
| | |-- Makefile
|
|
| | `-- <i>(sched source files)</i>
|
|
| |-- <a href="#DirStructSysCall">syscall</a>/
|
|
| | |-- Makefile
|
|
| | `-- <i>(syscall source files)</i>
|
|
| `-- <a href="#DirStructTools">tools</a>/
|
|
| `-- <i>(miscellaneous scripts and programs)</i>
|
|
`- apps
|
|
|-- <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="#DirStructNshLib">nshlib</a>/
|
|
| |-- Makefile
|
|
| `-- <i>NuttShell (NSH) files</i>
|
|
|-- <i>(Board-specific applications)</i>/
|
|
| |-- Makefile
|
|
| |-- <i>(Board-specific application sub-directories)</i>/
|
|
| | `-- <i>(Board-specific application source files)</i>
|
|
| `-- <i>(Board-specific common files)</i>
|
|
`-- <a href="#DirStructExamples">examples</a>/
|
|
`-- <i>(example)</i>/
|
|
|-- Makefile
|
|
`-- <i>(example source files)</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">nuttx/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
|
|
| `-- syscall.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>
|
|
_int8_t, _uint8_t, _int16_t, _uint16_t, _int32_t, _uint32_t_t
|
|
</code></ul>
|
|
<p>and if the architecture supports 24- or 64-bit integers</p>
|
|
<ul><code>
|
|
_int24_t, _uint24_t, int64_t, uint64_t
|
|
</code></ul>
|
|
<p>
|
|
NOTE that these type names have a leading underscore character. This
|
|
file will be included(indirectly) by include/stdint.h and typedef'ed to
|
|
the final name without the underscore character. This roundabout way of
|
|
doings things allows the stdint.h to be removed from the include/
|
|
directory in the event that the user prefers to use the definitions
|
|
provided by their toolchain header files
|
|
</p>
|
|
<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 some structures. 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>include/syscall.h</code>:
|
|
This file needs to define some architecture specific functions (usually
|
|
inline if the compiler supports inlining) to support software interrupts
|
|
or <i>syscall</i>s that can be used all from user-mode applications into
|
|
kernel-mode NuttX functions.
|
|
This directory must always be provided to prevent compilation errors.
|
|
However, it need only contain valid function declarations if the architecture
|
|
supports the <code>CONFIG_NUTTX_KERNEL</code> configuration.
|
|
<ul>
|
|
<li>
|
|
<code>uintptr_t sys_call0(unsigned int nbr)</code>:
|
|
<code>nbr</code> is one of the system call numbers that can be found in <code>include/sys/syscall.h</code>.
|
|
This function will perform a system call with no (additional) parameters.
|
|
</li>
|
|
<li>
|
|
<code>uintptr_t sys_call1(unsigned int nbr, uintptr_t parm1)</code>:
|
|
<code>nbr</code> is one of the system call numbers that can be found in <code>include/sys/syscall.h</code>.
|
|
This function will perform a system call with one (additional) parameter.
|
|
</li>
|
|
<li>
|
|
<code>uintptr_t sys_call2(unsigned int nbr, uintptr_t parm1, uintptr_t parm2)</code>:
|
|
<code>nbr</code> is one of the system call numbers that can be found in <code>include/sys/syscall.h</code>.
|
|
This function will perform a system call with two (additional) parameters.
|
|
</li>
|
|
<li>
|
|
<code>uintptr_t sys_call3(unsigned int nbr, uintptr_t parm1, uintptr_t parm2, uintptr_t parm3)</code>:
|
|
<code>nbr</code> is one of the system call numbers that can be found in <code>include/sys/syscall.h</code>.
|
|
This function will perform a system call with three (additional) parameters.
|
|
</li>
|
|
<li>
|
|
<code>uintptr_t sys_call4(unsigned int nbr, uintptr_t parm1, uintptr_t parm2, uintptr_t parm3, uintptr_t parm4)</code>:
|
|
<code>nbr</code> is one of the system call numbers that can be found in <code>include/sys/syscall.h</code>.
|
|
This function will perform a system call with four (additional) parameters.
|
|
</li>
|
|
<li>
|
|
<code>uintptr_t sys_call5(unsigned int nbr, uintptr_t parm1, uintptr_t parm2, uintptr_t parm3, uintptr_t parm4, uintptr_t parm5)</code>:
|
|
<code>nbr</code> is one of the system call numbers that can be found in <code>include/sys/syscall.h</code>.
|
|
This function will perform a system call with five (additional) parameters.
|
|
</li>
|
|
<li>
|
|
<code>uintptr_t sys_call6(unsigned int nbr, uintptr_t parm1, uintptr_t parm2, uintptr_t parm3, uintptr_t parm4, uintptr_t parm5, uintptr_t parm6)</code>:
|
|
<code>nbr</code> is one of the system call numbers that can be found in <code>include/sys/syscall.h</code>.
|
|
This function will perform a system call with six (additional) parameters.
|
|
</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>Architecture- 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 development.
|
|
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 boots and passes the OS test (apps/examples/ostest).
|
|
The port is complete and verified. As of NuttX 0.3.17, the port includes:
|
|
timer interrupts, serial console, USB driver, and SPI-based MMC/SD card
|
|
support. A verified NuttShell configuration is also available.
|
|
</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/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 SVN at
|
|
http://nuttx.svn.sourceforge.net/viewvc/nuttx/trunk/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="DirStructBinFmt">nuttx/binfmt</a></h2>
|
|
|
|
<p>
|
|
The <code>binfmt/</code> subdirectory contains logic for loading binaries in the file
|
|
system into memory in a form that can be used to execute them.
|
|
</p>
|
|
|
|
<h2>2.4 <a name="DirStructConfigs">nuttx/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.4.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
|
|
| |-- appconfig<sup>1</sup>
|
|
| `-- setenv.sh
|
|
|-- <i><config2-dir></i>
|
|
| |-- Make.defs
|
|
| |-- defconfig
|
|
| |-- appconfig<sup>1</sup>
|
|
| `-- setenv.sh
|
|
| ...
|
|
`-- <i>(other board-specific configuration sub-directories)</i>/
|
|
</pre>
|
|
<p><small>
|
|
<sup>1</sup>Optional
|
|
</small></p>
|
|
</ul>
|
|
|
|
<h3><a name="summaryofconfigfiles">2.4.2 Summary of Files</a></h3>
|
|
<h4><a name="boardlogic">2.4.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</code> 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.4.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>
|
|
<p>
|
|
<code>defconfig</code>: This is a configuration file similar to the Linux
|
|
configuration file. In contains variable/value pairs like:
|
|
</p>
|
|
<ul>
|
|
<li><code>CONFIG_VARIABLE</code>=value</li>
|
|
</ul>
|
|
<p>
|
|
This configuration file will be used at build time:
|
|
</p>
|
|
<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></p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<code>appconfig</code>: This is another configuration file that is specific to the
|
|
application. This file is copied into the application build directory
|
|
when NuttX is configured. See <code>../apps/README.txt</code> for further details.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<code>setenv.sh</code>: This is a script that you can include that will be installed at
|
|
the top level of the directory structure and can be sourced to set any
|
|
necessary environment variables.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="supportedboards">2.4.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 further 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 further 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 development.
|
|
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: This port is available as of release 0.3.18 of NuttX. The port is basically
|
|
complete and many examples run correctly. However, there are remaining instabilities
|
|
that make the port un-usable. The nature of these is not understood; the behavior is
|
|
that certain SH-1 instructions stop working as advertised. This could be a silicon
|
|
problem, some pipeline issue that is not handled properly by the gcc 3.4.5 toolchain
|
|
(which has very limited SH-1 support to begin with), or perhaps with the CMON debugger.
|
|
At any rate, I have exhausted all of the energy that I am willing to put into this cool
|
|
old processor for the time being.
|
|
</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 SVN
|
|
<a href="http://nuttx.svn.sourceforge.net/viewvc/nuttx/trunk/misc/sims/z80sim">here</a>.
|
|
This port also the <a href="http://sdcc.sourceforge.net/">SDCC</a> toolchain
|
|
under Linux or Cygwin(verified 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.5 <a name="DirStructDrivers">nuttx/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>(USB device driver source files)</i>
|
|
|-- usbhost/
|
|
| |-- Make.defs
|
|
| `-- <i>(USB host driver source files)</i>
|
|
`-- <i>(common driver source files)</i>
|
|
</pre></ul>
|
|
|
|
<h2>2.6 <a name="DirStructFs">nuttx/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">nuttx/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">nuttx/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">nuttx/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="DirStructLibXX">nuttx/libxx</a></h2>
|
|
<p>
|
|
This directory holds a tiny, minimal standard std C++ that can be used to
|
|
build some, simple C++ applications in NuttX.
|
|
</p>
|
|
|
|
<h2>2.11 <a name="DirStructMm">nuttx/mm</a></h2>
|
|
<p>
|
|
This is the NuttX memory manager.
|
|
</p>
|
|
|
|
<h2>2.12 <a name="DirStructNet">nuttx/net</a></h2>
|
|
<p>
|
|
This directory contains the implementation of the socket APIs.
|
|
The subdirectory, <code>uip</code> contains the uIP port.
|
|
</P>
|
|
|
|
<h2>2.13 <a name="DirStructSched">nuttx/sched</a></h2>
|
|
<p>
|
|
The files forming core of the NuttX RTOS reside here.
|
|
</p>
|
|
|
|
<h2>2.14 <a name="DirStructSyscall">nuttx/syscall</a></h2>
|
|
<p>
|
|
If NuttX is built as a separately compiled kernel (with CONFIG_NUTTX_KERNEL=y),
|
|
then the contents of this directory are built.
|
|
This directory holds a syscall interface that can be used for communication
|
|
between user-mode applications and the kernel-mode RTOS.
|
|
</p>
|
|
|
|
<h2>2.15 <a name="DirStructTools">nuttx/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.host
|
|
|-- README.txt
|
|
|-- configure.sh
|
|
|-- cfgparser.c
|
|
|-- cfgparser.h
|
|
|-- define.sh
|
|
|-- incdir.sh
|
|
|-- indent.sh
|
|
|-- link.sh
|
|
|-- mkconfig.c
|
|
|-- mkdeps.sh
|
|
|-- mkimage.sh
|
|
|-- mknulldeps.sh
|
|
|-- mkromfsimg.sh
|
|
|-- mksyscall.c
|
|
|-- mkversion.c
|
|
|-- unlink.sh
|
|
|-- version.sh
|
|
|-- winlink.sh
|
|
`-- zipme.sh
|
|
</pre></ul>
|
|
|
|
<p>
|
|
Refer to the README file in the <code>tools</code> directory for more information about the individual files.
|
|
Some of these tools are discussed below as well in the discussion of <a href="#configandbuild">configuring and building</a> NuttX.
|
|
</p>
|
|
|
|
<h2>2.16 <a name="topmakefile">nuttx/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>
|
|
|
|
<h2>2.17 <a name="DirStructNetUtils">apps/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>
|
|
|-- thttpd/
|
|
| |-- Make.defs
|
|
| `-- <i>(thttpd 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.18 <a name="DirStructNshLib">apps/nshlib</a></h2>
|
|
<p>
|
|
This directory contains for the core of the NuttShell (NSH) application.
|
|
</p>
|
|
|
|
<h2>2.19 <a name="DirStructExamples">apps/examples</a></h2>
|
|
<p>
|
|
Example and test programs to build against.
|
|
</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.defs</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>
|
|
And if <code>configs/</code><i><board-name></i><code>/[</code><i><config-dir></i><code>/appconfig</code> exists in the board configuration directory:
|
|
</p>
|
|
<ul>
|
|
<li>Copy <code>configs/</code><i><board-name></i><code>/[</code><i><config-dir></i><code>/appconfig</code> to <app-dir><code>/.config</code></li>
|
|
<li><code>echo "APPS_LOC=\"<app-dir>\"" >> "${TOPDIR}/.config"</code></li>
|
|
</ul>
|
|
|
|
</p>
|
|
<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>.
|
|
<config-dir> is the optional, specific configuration directory for the board.
|
|
And <app-dir> is the location of the optonal application directory.
|
|
</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>[/<i><config-dir></i>]
|
|
</pre></ul>
|
|
|
|
<p>
|
|
And if <code>configs/</code><i><board-name></i><code>/[</code><i><config-dir></i><code>/appconfig</code>
|
|
exists and your application directory is not in the standard loction (<config>../apps</config>),
|
|
then you should also specify the location of the application directory on the command line like:
|
|
</p>
|
|
<ul><pre>
|
|
cd tools
|
|
./configure.sh -a <app-dir> <i><board-name></i></i>[/<i><config-dir></i>]
|
|
</pre></ul>
|
|
|
|
<p>
|
|
<b>Version Files</b>.
|
|
The NuttX build expects to find a version file located in the top-level NuttX build directory.
|
|
That version file is called <code>.version</code>.
|
|
The correct version file is installed in each versioned NuttX released.
|
|
However, if you are working from an SVN snapshot, then there will be no version file.
|
|
If there is no version file, the top-level <code>Makefile</code> will create a dummy <code>.version</code> file on the first make.
|
|
This dummy version file will contain all zeroes for version information.
|
|
If that is not what you want, they you should run the <code>version.sh</code> script to create a better <code>.version</code> file.
|
|
</p>
|
|
|
|
<p>
|
|
You can get help information from the <code>version.sh</code> script using the <code>-h</code> option.
|
|
For example:
|
|
</p>
|
|
<ul><pre>
|
|
$ tools/version.sh -h
|
|
tools/version.sh is a tool for generation of proper version files for the NuttX build
|
|
|
|
USAGE: tools/version.sh [-d|-h] [-b build] -v <major.minor> <outfile-path>
|
|
|
|
Where:
|
|
-d
|
|
Enable script debug
|
|
-h
|
|
show this help message and exit
|
|
-v <major.minor>
|
|
The NuttX version number expressed a major and minor number separated
|
|
by a period
|
|
<outfile-path>
|
|
The full path to the version file to be created
|
|
</pre></ul>
|
|
|
|
<p>
|
|
As an example, the following command will generate a version file for version 6.1 using the current SVN revision number:
|
|
</p>
|
|
<ul><pre>
|
|
tools/version.h -v 6.1 .version
|
|
</pre></ul>
|
|
|
|
<p>
|
|
The <code>.version</code> file is also used during the build process to create a C header file at <code>include/nuttx/version.h</code> that contains the same version information.
|
|
That version file may be used by your C applications for, as an example, reporting version information.
|
|
</p>
|
|
|
|
<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 targets, 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.h</code> using the <code>${TOPDIR}/.config</code> file.
|
|
<li>Auto-generating the file <code>include/nuttx/version.h</code> using the <code>${TOPDIR}/.version</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 initial architecture registers and/or stack so that execution
|
|
will begin at tcb->start on the next context switch.
|
|
</p>
|
|
<p>
|
|
This function may also need to set up processor registers so that the new thread executes
|
|
with the correct privileges.
|
|
If <code>CONFIG_NUTTX_KERNEL</code> has been selected in the NuttX configuration,
|
|
then special initialization may need to be performed depending on the task type specified
|
|
in the TCB's flags field:
|
|
Kernel threads will require kernel-mode privileges;
|
|
User tasks and pthreads should have only user-mode privileges.
|
|
If <code>CONFIG_NUTTX_KERNEL</code> has <i>not</i> been selected,
|
|
then all threads should have kernel-mode privileges.
|
|
</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 tasks, 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, uint8_t 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 disable 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 uint8_t *filename, int linenum);</code></br>
|
|
<code>void up_assert_code(FAR const uint8_t *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 'sigdeliver' 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>bool up_interrupt_context(void)</code></p>
|
|
|
|
<p><b>Description</b>.
|
|
Return true if 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);
|
|
#endif
|
|
</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);
|
|
#endif
|
|
</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);
|
|
#endif
|
|
</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 architecture-
|
|
specific logic in order to display an interrupt to
|
|
the appropriate, registered handling logic.
|
|
</p>
|
|
|
|
<h2><a name="demandpaging">4.3 On-Demand Paging</a></h2>
|
|
|
|
<p>
|
|
The NuttX On-Demand Paging feature permits embedded MCUs with some limited RAM space to execute large programs from some non-random access media.
|
|
If the platform meets certiain requirements, then NuttX can provide on-demand paging:
|
|
It can copy .text from the large program in non-volatile media into RAM as needed to execute a huge program from the small RAM.
|
|
Design and porting issues for this feature are discussed in a sepate document.
|
|
Please see the <a href="NuttXDemandPaging.html">NuttX Demand Paging</a> design document for further information.
|
|
</p>
|
|
|
|
<h2><a name="ledsupport">4.4 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 alphanumeric 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 altogether; 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>pseudo</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>pseudo</i> file system (in the
|
|
same sense that the Linux <code>/proc</code> file system is also
|
|
referred to as a pseudo file system).
|
|
</p>
|
|
|
|
<p>
|
|
Any user supplied data or logic can be accessed via the pseudo-file system.
|
|
Built in support is provided for character and block <a href="#DeviceDrivers">drivers</a> in the
|
|
<code>/dev</code> pseudo 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 pseudo 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 pseudo file system and true file systems may be
|
|
mounted in the pseudo file system.
|
|
In the typical Linux installation by comparison, the Linux root file system
|
|
is a true file system and pseudo 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>pseudo</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>
|
|
<p>
|
|
<b><code>include/nuttx/fs.h</code></b>.
|
|
All structures and APIs needed to work with character drivers are provided in this header file.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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, bool setup);</code></p>
|
|
</ul>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>drivers/dev_null.c</code>, <code>drivers/fifo.c</code>, <code>drivers/serial.c</code>, etc.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2><a name="blockdrivers">6.2 Block Device Drivers</a></h2>
|
|
|
|
<p>
|
|
Block device drivers have these properties:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/fs.h</code></b>.
|
|
All structures and APIs needed to work with block drivers are provided in this header file.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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>apps/nshlib/nsh_fscmds.c</code>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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>apps/nshlib/nsh_fscmds.c</code>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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>apps/nshlib/nsh_ddcmd.c</code>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Examples</b>.
|
|
<code>drivers/loop.c</code>, <code>drivers/mmcsd/mmcsd_spi.c</code>, <code>drivers/ramdisk.c</code>, etc.
|
|
</p>
|
|
</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>
|
|
<p>
|
|
<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>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b><code>int netdev_register(FAR struct uip_driver_s *dev);</code></b>.
|
|
Each Ethernet driver registers itself by calling <code>netdev_register()</code>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="spidrivers">6.3.2 SPI Device Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/spi.h</code></b>.
|
|
All structures and APIs needed to work with SPI drivers are provided in this header file.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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 lock(FAR struct spi_dev_s *dev);</code></p>
|
|
<p><code>void select(FAR struct spi_dev_s *dev, enum spi_dev_e devid, bool selected);</code><br>
|
|
<code>uint32_t setfrequency(FAR struct spi_dev_s *dev, uint32_t 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>uint8_t status(FAR struct spi_dev_s *dev, enum spi_dev_e devid);</code><br>
|
|
<code>uint16_t send(FAR struct spi_dev_s *dev, uint16_t 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><code>int registercallback(FAR struct spi_dev_s *dev, mediachange_t callback, void *arg);</code></p>
|
|
</ul>
|
|
</p>
|
|
<li>
|
|
<p>
|
|
<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>.
|
|
In general, the binding sequence is:
|
|
</p>
|
|
<p>
|
|
<ol>
|
|
<li>Get an instance of <code>struct spi_dev_s</code> from the hardware-specific SPI device driver, and </li>
|
|
<li>Provide that instance to the initialization method of the higher level device driver.</li>
|
|
</ol>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>drivers/loop.c</code>, <code>drivers/mmcsd/mmcsd_spi.c</code>, <code>drivers/ramdisk.c</code>, etc.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="i2cdrivers">6.3.3 I2C Device Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/i2c/i2c.h</code></b>.
|
|
All structures and APIs needed to work with I2C drivers are provided in this header file.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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_t setfrequency(FAR struct i2c_dev_s *dev, uint32_t 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 uint8_t *buffer, int buflen);</code><br>
|
|
<code>int read(FAR struct i2c_dev_s *dev, uint8_t *buffer, int buflen);</code></p>
|
|
</p>
|
|
</ul>
|
|
<li>
|
|
<p>
|
|
<b>Binding I2C Drivers</b>.
|
|
I2C drivers are not normally directly accessed by user code, but are usually bound to another,
|
|
higher level device driver.
|
|
In general, the binding sequence is:
|
|
</p>
|
|
<p>
|
|
<ol>
|
|
<li>Get an instance of <code>struct i2c_dev_s</code> from the hardware-specific I2C device driver, and </li>
|
|
<li>Provide that instance to the initialization method of the higher level device driver.</li>
|
|
</ol>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>arch/z80/src/ez80/ez80_i2c.c</code>, <code>arch/z80/src/z8/z8_i2c.c</code>, etc.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="serialdrivers">6.3.4 Serial Device Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/serial.h</code></b>.
|
|
All structures and APIs needed to work with serial drivers are provided in this header file.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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, bool enable);</code><br>
|
|
<code>bool 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, bool enable);</code><br>
|
|
<code>bool txready(FAR struct uart_dev_s *dev);</code><br>
|
|
<code>bool txempty(FAR struct uart_dev_s *dev);</code></p>
|
|
</ul>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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 paths like <code>/dev/ttyS0</code>, <code>/dev/ttyS1</code>, etc.
|
|
See the <code>uart_register()</code> implementation in <code>drivers/serial.c</code>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>User Access</b>.
|
|
Serial drivers are, ultimately, normal <a href="#chardrivers">character drivers</a> and are accessed as other character drivers.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<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.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="fbdrivers">6.3.5 Frame Buffer Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/fb.h</code></b>.
|
|
All structures and APIs needed to work with frame buffer drivers are provided in this header file.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b><code>struct fb_vtable_s</code></b>.
|
|
Each frame buffer device driver must implement an instance of <code>struct fb_vtable_s</code>.
|
|
That structure defines a call table with the following methods:
|
|
</p>
|
|
<p>
|
|
Get information about the video controller configuration and the configuration of each color plane.
|
|
</p>
|
|
<ul>
|
|
<p><code>int (*getvideoinfo)(FAR struct fb_vtable_s *vtable, FAR struct fb_videoinfo_s *vinfo);</code><br>
|
|
<code>int (*getplaneinfo)(FAR struct fb_vtable_s *vtable, int planeno, FAR struct fb_planeinfo_s *pinfo);</code></p>
|
|
</ul>
|
|
<p>
|
|
The following are provided only if the video hardware supports RGB color mapping:
|
|
</p>
|
|
<ul>
|
|
<p><code>int (*getcmap)(FAR struct fb_vtable_s *vtable, FAR struct fb_cmap_s *cmap);</code><br>
|
|
<code>int (*putcmap)(FAR struct fb_vtable_s *vtable, FAR const struct fb_cmap_s *cmap);</code></p>
|
|
</ul>
|
|
<p>
|
|
The following are provided only if the video hardware supports a hardware cursor:
|
|
</p>
|
|
<ul>
|
|
<p><code>int (*getcursor)(FAR struct fb_vtable_s *vtable, FAR struct fb_cursorattrib_s *attrib);</code><br>
|
|
<code>int (*setcursor)(FAR struct fb_vtable_s *vtable, FAR struct fb_setcursor_s *settings);</code></p>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Binding Frame Buffer Drivers</b>.
|
|
Frame buffer drivers are not normally directly accessed by user code, but are usually bound to another,
|
|
higher level device driver.
|
|
In general, the binding sequence is:
|
|
</p>
|
|
<p>
|
|
<ol>
|
|
<li>Get an instance of <code>struct fb_vtable_s</code> from the hardware-specific frame buffer device driver, and </li>
|
|
<li>Provide that instance to the initialization method of the higher level device driver.</li>
|
|
</ol>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>arch/sim/src/up_framebuffer.c</code>.
|
|
See also the usage of the frame buffer driver in the <code>graphics/</code> directory.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="lcddrivers">6.3.6 LCD Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/lcd/lcd.h</code></b>.
|
|
Structures and APIs needed to work with LCD drivers are provided in this header file.
|
|
This header file also depends on some of the same definitions used for the frame buffer driver as privided in <code>include/nuttx/fb.h</code>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b><code>struct lcd_dev_s</code></b>.
|
|
Each LCD device driver must implement an instance of <code>struct lcd_dev_s</code>.
|
|
That structure defines a call table with the following methods:
|
|
</p>
|
|
<p>
|
|
Get information about the LCD video controller configuration and the configuration of each LCD color plane.
|
|
</p>
|
|
<ul>
|
|
<p>
|
|
<code>int (*getvideoinfo)(FAR struct lcd_dev_s *dev, FAR struct fb_videoinfo_s *vinfo);</code><br>
|
|
<code>int (*getplaneinfo)(FAR struct lcd_dev_s *dev, unsigned int planeno, FAR struct lcd_planeinfo_s *pinfo);</code>
|
|
</p>
|
|
</ul>
|
|
<p>
|
|
The following are provided only if the video hardware supports RGB color mapping:
|
|
</p>
|
|
<ul>
|
|
<p>
|
|
<code>int (*getcmap)(FAR struct lcd_dev_s *dev, FAR struct fb_cmap_s *cmap);</code><br>
|
|
<code>int (*putcmap)(FAR struct lcd_dev_s *dev, FAR const struct fb_cmap_s *cmap);</code>
|
|
</p>
|
|
</ul>
|
|
<p>
|
|
The following are provided only if the video hardware supports a hardware cursor:
|
|
</p>
|
|
<ul>
|
|
<p>
|
|
<code>int (*getcursor)(FAR struct lcd_dev_s *dev, FAR struct fb_cursorattrib_s *attrib);</code><br>
|
|
<code>int (*setcursor)(FAR struct lcd_dev_s *dev, FAR struct fb_setcursor_s *settings)</code>
|
|
</p>
|
|
</ul>
|
|
<p>
|
|
Get the LCD panel power status (0: full off - <code>CONFIG_LCD_MAXPOWER</code>: full on).
|
|
On backlit LCDs, this setting may correspond to the backlight setting.
|
|
</p>
|
|
<ul>
|
|
<p>
|
|
<code>int (*getpower)(struct lcd_dev_s *dev);</code>
|
|
</p>
|
|
</ul>
|
|
<p>
|
|
Enable/disable LCD panel power (0: full off - <code>CONFIG_LCD_MAXPOWER</code>: full on).
|
|
On backlit LCDs, this setting may correspond to the backlight setting.
|
|
</p>
|
|
<ul>
|
|
<p>
|
|
<code>int (*setpower)(struct lcd_dev_s *dev, int power);</code>
|
|
</p>
|
|
</ul>
|
|
<p>
|
|
Get the current contrast setting (0-CONFIG_LCD_MAXCONTRAST) */
|
|
</p>
|
|
<ul>
|
|
<p>
|
|
<code>int (*getcontrast)(struct lcd_dev_s *dev);</code>
|
|
</p>
|
|
</ul>
|
|
<p>
|
|
Set LCD panel contrast (0-CONFIG_LCD_MAXCONTRAST)
|
|
</p>
|
|
<ul>
|
|
<p>
|
|
<code>int (*setcontrast)(struct lcd_dev_s *dev, unsigned int contrast);</code>
|
|
</p>
|
|
</ul>
|
|
</p>
|
|
<li>
|
|
<p>
|
|
<b>Binding LCD Drivers</b>.
|
|
LCD drivers are not normally directly accessed by user code, but are usually bound to another,
|
|
higher level device driver.
|
|
In general, the binding sequence is:
|
|
</p>
|
|
<p>
|
|
<ol>
|
|
<li>Get an instance of <code>struct lcd_dev_s</code> from the hardware-specific LCD device driver, and </li>
|
|
<li>Provide that instance to the initialization method of the higher level device driver.</li>
|
|
</ol>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>drivers/lcd/nokia6100.c</code>, <code>drivers/lcd/p14201.c</code>, <code>configs/sam3u-ek/src/up_lcd.c.</code>
|
|
See also the usage of the LCD driver in the <code>graphics/</code> directory.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="mtddrivers">6.3.7 Memory Technology Device Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/mtd.h</code></b>.
|
|
All structures and APIs needed to work with MTD drivers are provided in this header file.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b><code>struct mtd_dev_s</code></b>.
|
|
Each MTD device driver must implement an instance of <code>struct mtd_dev_s</code>.
|
|
That structure defines a call table with the following methods:
|
|
</p>
|
|
<p>
|
|
Erase the specified erase blocks (units are erase blocks):
|
|
</p>
|
|
<ul>
|
|
<p><code>int (*erase)(FAR struct mtd_dev_s *dev, off_t startblock, size_t nblocks);</code></p>
|
|
</ul>
|
|
<p>
|
|
Read/write from the specified read/write blocks:
|
|
</p>
|
|
<ul>
|
|
<p><code>ssize_t (*bread)(FAR struct mtd_dev_s *dev, off_t startblock, size_t nblocks, FAR uint8_t *buffer);</code><br>
|
|
<code>ssize_t (*bwrite)(FAR struct mtd_dev_s *dev, off_t startblock, size_t nblocks, FAR const uint8_t *buffer);</code></p>
|
|
</ul>
|
|
<p>
|
|
Some devices may support byte oriented reads (optional).
|
|
Most MTD devices are inherently block oriented so byte-oriented writing is not supported.
|
|
It is recommended that low-level drivers not support read() if it requires buffering.
|
|
</p>
|
|
<ul>
|
|
<p><code>ssize_t (*read)(FAR struct mtd_dev_s *dev, off_t offset, size_t nbytes, FAR uint8_t *buffer);</code></p>
|
|
</ul>
|
|
<p>
|
|
Support other, less frequently used commands:
|
|
</p>
|
|
<ul>
|
|
<li><code>MTDIOC_GEOMETRY</code>: Get MTD geometry</li>
|
|
<li><code>MTDIOC_XIPBASE:</code>: Convert block to physical address for eXecute-In-Place</li>
|
|
<li><code>MTDIOC_BULKERASE</code>: Erase the entire device</li>
|
|
</ul>
|
|
<p>
|
|
is provided via a sinble <code>ioctl</code> method (see <code>include/nuttx/ioctl.h</code>):
|
|
</p>
|
|
<ul>
|
|
<p><code>int (*ioctl)(FAR struct mtd_dev_s *dev, int cmd, unsigned long arg);</code></p>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Binding MTD Drivers</b>.
|
|
MTD drivers are not normally directly accessed by user code, but are usually bound to another,
|
|
higher level device driver.
|
|
In general, the binding sequence is:
|
|
</p>
|
|
<p>
|
|
<ol>
|
|
<li>Get an instance of <code>struct mtd_dev_s</code> from the hardware-specific MTD device driver, and </li>
|
|
<li>Provide that instance to the initialization method of the higher level device driver.</li>
|
|
</ol>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>drivers/mtd/m25px.c</code> and <code>drivers/mtd/ftl.c</code>
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="sdiodrivers">6.3.8 SDIO Device Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/sdio.h</code></b>.
|
|
All structures and APIs needed to work with SDIO drivers are provided in this header file.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b><code>struct sdio_dev_s</code></b>.
|
|
Each SDIOI device driver must implement an instance of <code>struct sdio_dev_s</code>.
|
|
That structure defines a call table with the following methods:
|
|
</p>
|
|
<p>
|
|
Initialization/setup:
|
|
</p>
|
|
<ul>
|
|
<p><code>void (*reset)(FAR struct sdio_dev_s *dev);</code><br>
|
|
<code>uint8_t (*status)(FAR struct sdio_dev_s *dev);</code><br>
|
|
<code>void (*widebus)(FAR struct sdio_dev_s *dev, bool enable);</code><br>
|
|
<code>void (*clock)(FAR struct sdio_dev_s *dev, enum sdio_clock_e rate);</code><br>
|
|
<code>int (*attach)(FAR struct sdio_dev_s *dev);</code></p>
|
|
</ul>
|
|
<p>
|
|
Command/Status/Data Transfer:
|
|
</p>
|
|
<ul>
|
|
<p><code>void (*sendcmd)(FAR struct sdio_dev_s *dev, uint32_t cmd, uint32_t arg);</code><br>
|
|
<code>int (*recvsetup)(FAR struct sdio_dev_s *dev, FAR uint8_t *buffer, size_t nbytes);</code><br>
|
|
<code>int (*sendsetup)(FAR struct sdio_dev_s *dev, FAR const uint8_t *buffer, size_t nbytes);</code><br>
|
|
<code>int (*cancel)(FAR struct sdio_dev_s *dev);</code><br>
|
|
<code>int (*waitresponse)(FAR struct sdio_dev_s *dev, uint32_t cmd);</code><br>
|
|
<code>int (*recvR1)(FAR struct sdio_dev_s *dev, uint32_t cmd, uint32_t *R1);</code><br>
|
|
<code>int (*recvR2)(FAR struct sdio_dev_s *dev, uint32_t cmd, uint32_t R2[4]);</code><br>
|
|
<code>int (*recvR3)(FAR struct sdio_dev_s *dev, uint32_t cmd, uint32_t *R3);</code><br>
|
|
<code>int (*recvR4)(FAR struct sdio_dev_s *dev, uint32_t cmd, uint32_t *R4);</code><br>
|
|
<code>int (*recvR5)(FAR struct sdio_dev_s *dev, uint32_t cmd, uint32_t *R5);</code><br>
|
|
<code>int (*recvR6)(FAR struct sdio_dev_s *dev, uint32_t cmd, uint32_t *R6);</code><br>
|
|
<code>int (*recvR7)(FAR struct sdio_dev_s *dev, uint32_t cmd, uint32_t *R7);</code></p>
|
|
</ul>
|
|
<p>
|
|
Event/Callback support:
|
|
</p>
|
|
<ul>
|
|
<p><code>void (*waitenable)(FAR struct sdio_dev_s *dev, sdio_eventset_t eventset);</code><br>
|
|
<code>sdio_eventset_t (*eventwait)(FAR struct sdio_dev_s *dev, uint32_t timeout);</code><br>
|
|
<code>void (*callbackenable)(FAR struct sdio_dev_s *dev, sdio_eventset_t eventset);</code><br>
|
|
<code>int (*registercallback)(FAR struct sdio_dev_s *dev, worker_t callback, void *arg);</code></p>
|
|
</ul>
|
|
<p>
|
|
DMA support:
|
|
</p>
|
|
<ul>
|
|
<p><code>bool (*dmasupported)(FAR struct sdio_dev_s *dev);</code><br>
|
|
<code>int (*dmarecvsetup)(FAR struct sdio_dev_s *dev, FAR uint8_t *buffer, size_t buflen);</code><br>
|
|
<code>int (*dmasendsetup)(FAR struct sdio_dev_s *dev, FAR const uint8_t *buffer, size_t buflen);</code></p>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Binding SDIO Drivers</b>.
|
|
SDIO drivers are not normally directly accessed by user code, but are usually bound to another,
|
|
higher level device driver.
|
|
In general, the binding sequence is:
|
|
</p>
|
|
<p>
|
|
<ol>
|
|
<li>Get an instance of <code>struct sdio_dev_s</code> from the hardware-specific SDIO device driver, and </li>
|
|
<li>Provide that instance to the initialization method of the higher level device driver.</li>
|
|
</ol>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>arch/arm/src/stm32/stm32_sdio.c</code> and <code>drivers/mmcsd/mmcsd_sdio.c</code>
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="usbhostdrivers">6.3.9 USB Host-Side Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/usb/usbhost.h</code></b>.
|
|
All structures and APIs needed to work with USB host-side drivers are provided in this header file.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b><code>struct usbhost_driver_s</code></b>.
|
|
Each USB host controller driver must implement an instance of <code>struct usbhost_driver_s</code>.
|
|
This structure is defined in <code>include/nuttx/usb/usbhost.h</code>.
|
|
</p>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>arch/arm/src/lpc17xx/lpc17_usbhost.c</code>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b><code>struct usbhost_class_s</code></b>.
|
|
Each USB host class driver must implement an instance of <code>struct usbhost_class_s</code>.
|
|
This structure is also defined in <code>include/nuttx/usb/usbhost.h</code>.
|
|
</p>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>drivers/usbhost/usbhost_storage.c</code>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>USB Host Class Driver Registry</b>.
|
|
The NuttX USB host infrastructure includes a <i>registry</i>.
|
|
During its initialization, each USB host class driver must call the interface, <code>usbhost_registerclass()</code>
|
|
in order add its interface to the registery.
|
|
Later, when a USB device is connected, the USB host controller will look up the USB host class driver that is needed to support the connected device in this registry.
|
|
</p>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>drivers/usbhost/usbhost_registry.c</code>, <code>drivers/usbhost/usbhost_registerclass.c</code>, and <code>drivers/usbhost/usbhost_findclass.c</code>,
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Detection and Enumeration of Connected Devices</b>.
|
|
Each USB host device controller supports two methods that are used to detect and enumeration newly connected devices
|
|
(and also detect disconnected devices):
|
|
</p>
|
|
<p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<code>int (*wait)(FAR struct usbhost_driver_s *drvr, bool connected);</code>
|
|
</p>
|
|
<p>
|
|
Wait for a device to be connected or disconnected.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<code>int (*enumerate)(FAR struct usbhost_driver_s *drvr);</code>
|
|
</p>
|
|
<p>
|
|
Enumerate the connected device.
|
|
As part of this enumeration process, the driver will
|
|
(1) get the device's configuration descriptor,
|
|
(2) extract the class ID info from the configuration descriptor,
|
|
(3) call <code>usbhost_findclass(</code>) to find the class that supports this device,
|
|
(4) call the <code>create()</code> method on the <code>struct usbhost_registry_s interface</code> to get a class instance, and
|
|
finally (5) call the <code>connect()</code> method of the <code>struct usbhost_class_s</code> interface.
|
|
After that, the class is in charge of the sequence of operations.
|
|
</p>
|
|
</ul>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Binding USB Host-Side Drivers</b>.
|
|
USB host-side controller drivers are not normally directly accessed by user code,
|
|
but are usually bound to another, higher level USB host class driver.
|
|
The class driver exports the standard NuttX device interface so that the connected USB device can be accessed just as with other, similar, on-board devices.
|
|
For example, the USB host mass storage class driver (<code>drivers/usbhost/usbhost_storage.c</code>) will register a standard, NuttX block driver interface (like <code>/dev/sda</code>)
|
|
that can be used to mount a file system just as with any other other block driver instance.
|
|
In general, the binding sequence is:
|
|
</p>
|
|
<p>
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Each USB host class driver includes an intialization entry point that is called from the
|
|
application at initialization time.
|
|
This driver calls <code>usbhost_registerclass()</code> during this initialization in order to makes itself available in the event the the device that it supports is connected.
|
|
</p>
|
|
<p>
|
|
<b>Examples</b>:
|
|
The function <code>usbhost_storageinit()</code> in the file <code>drivers/usbhost/usbhost_storage.c</code>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Each application must include a <i>waiter</i> thread thread that (1) calls the USB host controller driver's <code>wait()</code> to detect the connection of a device, and then
|
|
(2) call the USB host controller driver's <code>enumerate</code> method to bind the registered USB host class driver to the USB host controller driver.
|
|
</p>
|
|
<p>
|
|
<b>Examples</b>:
|
|
The function <code>nsh_waiter()</code> in the file <code>configs/nucleus2g/src/up_nsh.c</code> and
|
|
the function <code>nsh_waiter()</code> in the file <code>configs/olimex-lpc1766stk/src/up_nsh.c</code>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
As part of its operation during the binding operation, the USB host class driver will register an instances of a standard NuttX driver under the <code>/dev</code> directory.
|
|
To repeat the above example, the USB host mass storage class driver (<code>drivers/usbhost/usbhost_storage.c</code>) will register a standard, NuttX block driver interface (like <code>/dev/sda</code>)
|
|
that can be used to mount a file system just as with any other other block driver instance.
|
|
</p>
|
|
<p>
|
|
<b>Examples</b>:
|
|
See the call to <code>register_blockdriver()</code> in the function <code>usbhost_initvolume()</code> in the file <code>drivers/usbhost/usbhost_storage.c</code>.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="usbdevdrivers">6.3.10 USB Device-Side Drivers</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/usb/usbdev.h</code></b>.
|
|
All structures and APIs needed to work with USB device-side drivers are provided in this header file.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b><code>include/nuttx/usb/usbdev_trace.h</code></b>.
|
|
Declarations needed to work the the NuttX USB device driver trace capability.
|
|
That USB trace capability is detailed in <a href="UsbTrace.html">separate document</a>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b><code>struct usbdev_s</code></b>.
|
|
Each USB device controller driver must implement an instance of <code>struct usbdev_s</code>.
|
|
This structure is defined in <code>include/nuttx/usb/usbdev.h</code>.
|
|
</p>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>arch/arm/src/dm320/dm320_usbdev.c</code>, <code>arch/arm/src/lpc17xx/lpc17_usbdev.c</code>,
|
|
<code>arch/arm/src/lpc214x/lpc214x_usbdev.c</code>, <code>arch/arm/src/lpc313x/lpc313x_usbdev.c</code>, and
|
|
<code>arch/arm/src/stm32/stm32_usbdev.c</code>.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b><code>struct usbdevclass_driver_s</code></b>.
|
|
Each USB device class driver must implement an instance of <code>struct usbdevclass_driver_s</code>.
|
|
This structure is also defined in <code>include/nuttx/usb/usbdev.h</code>.
|
|
</p>
|
|
<p>
|
|
<b>Examples</b>:
|
|
<code>drivers/usbdev/usbdev_serial.c</code> and <code>drivers/usbdev/usbdev_storage.c</code>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<b>Binding USB Device-Side Drivers</b>.
|
|
USB device-side controller drivers are not normally directly accessed by user code,
|
|
but are usually bound to another, higher level USB device class driver.
|
|
The class driver is then configured to export the USB device functionality.
|
|
In general, the binding sequence is:
|
|
</p>
|
|
<p>
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Each USB device class driver includes an intialization entry point that is called from the
|
|
application at initialization time.
|
|
</p>
|
|
<p>
|
|
<b>Examples</b>:
|
|
The function <code>usbdev_serialinitialize()</code> in the file <code>drivers/usbdev/usbdev_serial.c</code> and
|
|
the function <code></code> in the file <code>drivers/usbdev/usbdev_storage.c</code>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
These initialization functions called the driver API, <code>usbdev_register()</code>.
|
|
This driver function will <i>bind</i> the USB class driver to the USB device controller driver,
|
|
completing the initialization.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
</p>
|
|
</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 items 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 supports prioritization 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>
|
|
|
|
<h2>Build Options</h2>
|
|
<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 should 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>:
|
|
Make 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 configurations <code>Make.defs</code> file.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
Building application code:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<code>CONFIG_APPS_DIR</code>: Identifies the directory that builds the application to link with NuttX.
|
|
This symbol must be assigned to the path of the application build directory <i>relative</i> to the NuttX top build directory.
|
|
If the application resides in the top-level <code>../apps/</code> directory, it is not necessary to define <code>CONFIG_APPS_DIR</code>.
|
|
If you have an application directory and the NuttX directory each in separate directories such as this:
|
|
<ul><pre>
|
|
build
|
|
|-nuttx
|
|
| |
|
|
| `- Makefile
|
|
`-application
|
|
|
|
|
`- Makefile
|
|
</pre></ul>
|
|
Then you would set <code>CONFIG_APPS_DIR=../application</code>.
|
|
The default value of <code>CONFIG_APPS_DIR</code> is <code>../apps/</code>.
|
|
</p>
|
|
<p>
|
|
The application direction must contain <code>Makefile</code> and this make file must support the following targets:
|
|
<ul>
|
|
<li>
|
|
<code>libapps$(LIBEXT)</code> (usually <code>libapps.a</code>).
|
|
<code>libapps.a</code> is a static library ( an archive) that contains all of application object files.
|
|
</li>
|
|
<li>
|
|
<code>clean</code>.
|
|
Do whatever is appropriate to clean the application directories for a fresh build.
|
|
</li>
|
|
<li>
|
|
<code>distclean</code>.
|
|
Clean everthing -- auto-generated files, symbolic links etc. -- so that the directory contents are the same as the contents in your configuration management system.
|
|
This is only done when you change the NuttX configuration.
|
|
</li>
|
|
<li>
|
|
<code>context</code>.
|
|
Perform one-time configuration-related setup.
|
|
This might includes such things as creating auto-generated files or symbolic links for directory configurations.
|
|
</li>
|
|
<li>
|
|
<code>depend</code>.
|
|
Make or update the application build dependencies.
|
|
</li>
|
|
</ul>
|
|
</p>
|
|
<p>
|
|
When this application is invoked it will receive the setting <code>TOPDIR</code> like:
|
|
<ul>
|
|
<code>$(MAKE) -C $(CONFIG_APPS_DIR) TOPDIR="$(TOPDIR)"</code> <target>
|
|
</ul>
|
|
</p>
|
|
<p>
|
|
<code>TOPDIR</code> is the full path to the NuttX directory.
|
|
It can be used, for example, to include makefile fragments (e.g., <code>.config</code> or <code>Make.defs</code>) or to set up include file paths.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
Two-pass Build Options.
|
|
If the 2 pass build option is selected, then these options configure the make system build a extra link object.
|
|
This link object is assumed to be an incremental (relative) link object, but could be a static library (archive)
|
|
(some modification to this Makefile would be required if CONFIG_PASS1_TARGET generates an archive).
|
|
Pass 1 1ncremental (relative) link objects should be put into the processor-specific source directory
|
|
where other link objects will be created - ff the pass1 obect is an archive, it could go anywhere.
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_BUILD_2PASS</code>:
|
|
Enables the two pass build options.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
When the two pass build option is enabled, the following also apply:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<code>CONFIG_PASS1_TARGET</code>: The name of the first pass build target.
|
|
</p>
|
|
</li>
|
|
<li><code>CONFIG_PASS1_BUILDIR</code>:
|
|
<p>
|
|
The path, relative to the top NuttX build directory to directory that contains the Makefile to build the first pass object.
|
|
The Makefile must support the following targets:
|
|
</p>
|
|
<p>
|
|
<ul>
|
|
<li>The special target <code>CONFIG_PASS1_TARGET</code> (if defined), and</li>
|
|
<li>The usual depend, clean, and distclean targets.</li>
|
|
</ul>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PASS1_OBJECT</code>: May be used to include an extra, pass1 object into the final link.
|
|
This would probably be the object generated from the <code>CONFIG_PASS1_TARGET</code>.
|
|
It may be available at link time in the <code>arch/<architecture>/src</code> directory.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>General OS setup</h2>
|
|
<ul>
|
|
<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_SYMBOLS</code>: build without optimization and with debug symbols (needed for use with a debugger).
|
|
</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 (disabled by default)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEBUG_NET</code>: enable network debug output (disabled by default)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEBUG_USB</code>: enable USB 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_DEBUG_BINFMT</code>: enable binary loader debug output (disabled by default)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_DEBUG_GRAPHICS</code>: enable NX graphics debug output (disabled by default)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_ARCH_LOWPUTC</code>: architecture supports low-level, boot
|
|
time console output
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NUTTX_KERNEL</code>:
|
|
With most MCUs, NuttX is built as a flat, single executable image
|
|
containing the NuttX RTOS along with all application code.
|
|
The RTOS code and the application run in the same address space and at the same kernel-mode privileges.
|
|
If this option is selected, NuttX will be built separately as a monolithic, kernel-mode module and the applications
|
|
can be added as a separately built, user-mode module.
|
|
In this a system call layer will be built to support the user- to kernel-mode interface to the RTOS.
|
|
</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 time slice 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>: Specifies 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</code>, <code>CONFIG_START_MONTH</code>, <code>CONFIG_START_DAY</code> -
|
|
Used to initialize the internal time logic.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_GREGORIAN_TIME</code>: Enables Gregorian time conversions.
|
|
You would only need this if you are concerned about accurate time conversions in
|
|
the recent past or in the distant future.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_JULIAN_TIME</code>: Enables Julian time conversions.
|
|
You would only need this if you are concerned about accurate time conversion in the distand past.
|
|
You must also define <code>CONFIG_GREGORIAN_TIME</code> in order to use Julian time.
|
|
</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 addressing
|
|
<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>
|
|
<li>
|
|
<code>CONFIG_FDCLONE_DISABLE</code>: Disable cloning of all file descriptors
|
|
by task_create() when a new task is started.
|
|
If set, all files/drivers will appear to be closed in the new task.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_FDCLONE_STDIO</code>: Disable cloning of all but the first
|
|
three file descriptors (stdin, stdout, stderr) by task_create()
|
|
when a new task is started.
|
|
If set, all files/drivers will appear to be closed in the new task except
|
|
for stdin, stdout, and stderr.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SDCLONE_DISABLE</code>: Disable cloning of all socket
|
|
desciptors by task_create() when a new task is started.
|
|
If set, all sockets will appear to be closed in the new task.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NXFLAT</code>: Enable support for the NXFLAT binary format.
|
|
This format will support execution of NuttX binaries located
|
|
in a ROMFS filesystem (see <code>apps/examples/nxflat</code>).
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SCHED_WORKQUEUE</code>: Create a dedicated "worker" thread to
|
|
handle delayed processing from interrupt handlers. This feature
|
|
is required for some drivers but, if there are not complaints,
|
|
can be safely disabled. The worker thread also performs
|
|
garbage collection -- completing any delayed memory deallocations
|
|
from interrupt handlers. If the worker thread is disabled,
|
|
then that clean will be performed by the IDLE thread instead
|
|
(which runs at the lowest of priority and may not be appropriate
|
|
if memory reclamation is of high priority). If CONFIG_SCHED_WORKQUEUE
|
|
is enabled, then the following options can also be used:
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SCHED_WORKPRIORITY</code>: The execution priority of the worker
|
|
thread. Default: 50
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SCHED_WORKPERIOD</code>: How often the worker thread checks for
|
|
work in units of microseconds. Default: 50*1000 (50 MS).
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SCHED_WORKSTACKSIZE</code>: The stack size allocated for the worker
|
|
thread. Default: CONFIG_IDLETHREAD_STACKSIZE.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SIG_SIGWORK</code>: The signal number that will be used to wake-up
|
|
the worker thread. Default: 4
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Kernel build options:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NUTTX_KERNEL</code>: Builds NuttX as a separately compiled kernel.
|
|
</li>
|
|
<code>CONFIG_SYS_RESERVED</code>: Reserved system call values for use by architecture-specific logic.
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
OS setup related to on-demand paging:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_PAGING</code>: If set =y in your configation file, this setting will
|
|
enable the on-demand paging feature as described in
|
|
<a href="http://www.nuttx.org/NuttXDemandPaging.html">http://www.nuttx.org/NuttXDemandPaging.html</a>.
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
If CONFIG_PAGING is selected, then you will probabaly need <code>CONFIG_BUILD_2PASS</code> to correctly position
|
|
the code and the following configuration options also apply:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_PAGING_PAGESIZE</code>:
|
|
The size of one managed page.
|
|
This must be a value supported by the processor's memory management unit.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_NLOCKED</code>:
|
|
This is the number of locked pages in the memory map.
|
|
The locked address region will then be from <code>CONFIG_DRAM_VSTART</code> through
|
|
(<code>CONFIG_DRAM_VSTART</code> + <code>CONFIG_PAGING_PAGESIZE</code>*<code>CONFIG_PAGING_NLOCKED</code>)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_LOCKED_PBASE</code> and <code>CONFIG_PAGING_LOCKED_VBASE</code>:
|
|
These may be defined to determine the base address of the locked page regions.
|
|
If neither are defined, the logic will be set the bases to <code>CONFIG_DRAM_START</code>
|
|
and <code>CONFIG_DRAM_VSTART</code> (i.e., it assumes that the base address of the locked
|
|
region is at the beginning of RAM).
|
|
<b>NOTE</b>:
|
|
In some architectures, it may be necessary to take some memory from the beginning
|
|
of this region for vectors or for a page table.
|
|
In such cases, <code>CONFIG_PAGING_LOCKED_P/VBASE</code> should take that into consideration
|
|
to prevent overlapping the locked memory region and the system data at the beginning of SRAM.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_NPPAGED</code>:
|
|
This is the number of physical pages available to support the paged text region.
|
|
This paged region begins at
|
|
(<code>CONFIG_PAGING_LOCKED_PBASE</code> + <code>CONFIG_PAGING_PAGESIZE</code>*<code>CONFIG_PAGING_NPPAGED</code>)
|
|
and continues until
|
|
(<code>CONFIG_PAGING_LOCKED_PBASE</code> + <code>CONFIG_PAGING_PAGESIZE</code>*(<code>CONFIG_PAGING_NLOCKED</code> +
|
|
<code>CONFIG_PAGING_NPPAGED</code>)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_NVPAGED</code>:
|
|
This actual size of the paged text region (in pages).
|
|
This is also the number of virtual pages required to support the entire paged region.
|
|
The on-demand paging feature is intended to support only the case where the virtual paged text
|
|
area is much larger the available physical pages.
|
|
Otherwise, why would you enable on-demand paging?
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_NDATA</code>:
|
|
This is the number of data pages in the memory map.
|
|
The data region will extend to the end of RAM unless overridden by a setting in the configuration file.
|
|
<b>NOTE</b>:
|
|
In some architectures, it may be necessary to take some memory from the end of RAM for page tables
|
|
or other system usage.
|
|
The configuration settings and linker directives must be cognizant of that:
|
|
<code>CONFIG_PAGING_NDATA</code> should be defined to prevent the data region from extending all the way to the end of memory.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_DEFPRIO</code>:
|
|
The default, minimum priority of the page fill worker thread.
|
|
The priority of the page fill work thread will be boosted boosted dynmically so that it matches the
|
|
priority of the task on behalf of which it peforms the fill.
|
|
This defines the minimum priority that will be used. Default: 50.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_STACKSIZE</code>:
|
|
Defines the size of the allocated stack for the page fill worker thread. Default: 1024.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_BLOCKINGFILL</code>:
|
|
The architecture specific <code>up_fillpage()</code> function may be blocking or non-blocking.
|
|
If defined, this setting indicates that the <code>up_fillpage()</code> implementation will block until the
|
|
transfer is completed. Default: Undefined (non-blocking).
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_WORKPERIOD</code>:
|
|
The page fill worker thread will wake periodically even if there is no mapping to do.
|
|
This selection controls that wake-up period (in microseconds).
|
|
This wake-up a failsafe that will handle any cases where a single is lost (that would
|
|
really be a bug and shouldn't happen!)
|
|
and also supports timeouts for case of non-blocking, asynchronous fills (see <code>CONFIG_PAGING_TIMEOUT_TICKS</code>).
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_TIMEOUT_TICKS</code>:
|
|
If defined, the implementation will monitor the (asynchronous) page fill logic.
|
|
If the fill takes longer than this number if microseconds, then a fatal error will be declared.
|
|
Default: No timeouts monitored.
|
|
</li>
|
|
<p>
|
|
Some architecture-specific settings.
|
|
Defaults are architecture specific.
|
|
If you don't know what you are doing, it is best to leave these undefined and try the system defaults:
|
|
</p>
|
|
<li>
|
|
<code>CONFIG_PAGING_VECPPAGE</code>:
|
|
This the physical address of the page in memory to be mapped to the vector address.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_VECL2PADDR</code>:
|
|
This is the physical address of the L2 page table entry to use for the vector mapping.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_VECL2VADDR</code>:
|
|
This is the virtual address of the L2 page table entry to use for the vector mapping.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_BINPATH</code>:
|
|
If <code>CONFIG_PAGING_BINPATH</code> is defined, then it is the full path to a file on a mounted file system that contains a binary image of the NuttX executable.
|
|
Pages will be filled by reading from offsets into this file that correspond to virtual fault addresses.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_MOUNTPT</code>:
|
|
If <code>CONFIG_PAGING_BINPATH</code> is defined, additional options may be provided to control the initialization of underlying devices.
|
|
<code>CONFIG_PAGING_MOUNTPT</code> identifies the mountpoint to be used if a device is mounted.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_MINOR</code>:
|
|
Some mount operations require a "minor" number to identify the specific device instance.
|
|
Default: 0
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_SDSLOT</code>:
|
|
If <code>CONFIG_PAGING_BINPATH</code> is defined, additional options may be provided to control the initialization of underlying devices.
|
|
<code>CONFIG_PAGING_SDSLOT</code> identifies the slot number of the SD device to initialize.
|
|
This must be undefined if SD is not being used.
|
|
This should be defined to be zero for the typical device that has only a single slot (See <code>CONFIG_MMCSD_NSLOTS</code>).
|
|
If defined, <code>CONFIG_PAGING_SDSLOT</code> will instruct certain board-specific logic to initialize the media in this SD slot.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_M25PX</code>:
|
|
Use the m25px.c FLASH driver.
|
|
If this is selected, then the MTD interface to the M25Px device will be used to support paging.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_AT45DB</code>:
|
|
Use the at45db.c FLASH driver.
|
|
If this is selected, then the MTD interface to the Atmel AT45DB device will be used to support paging.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_BINOFFSET</code>:
|
|
If CONFIG_PAGING_M25PX or CONFIG_PAGING_AT45DB is defined then CONFIG_PAGING_BINOFFSET will be used to specify the offset in bytes into the FLASH device where the NuttX binary image is located.
|
|
Default: 0
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PAGING_SPIPORT</code>:
|
|
If CONFIG_PAGING_M25PX or CONFIG_PAGING_AT45DB is defined and the device has multiple SPI busses (ports), then this configuration should be set to indicate which SPI port the device is connected.
|
|
Default: 0
|
|
</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>
|
|
<li>
|
|
<code>CONFIG_LIBC_FLOATINGPOINT</code>: By default, floating point
|
|
support in printf, sscanf, etc. is disabled.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>Allow for architecture optimized implementations</h2>
|
|
|
|
<p>
|
|
The architecture can provide optimized versions of the
|
|
following to improve system 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_STRNLEN</code>,
|
|
<code>CONFIG_ARCH_BZERO</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 setting (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_PREALLOC_IGMPGROUPS</code>: Pre-allocated IGMP groups are used
|
|
Only if needed from interrupt level group created (by the IGMP server).
|
|
Default: 4
|
|
</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>Device Drivers</h2>
|
|
<h3>SPI driver</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_SPI_OWNBUS</code> - Set if there is only one active device
|
|
on the SPI bus. No locking or SPI configuration will be performed.
|
|
It is not necessary for clients to lock, re-configure, etc..
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SPI_EXCHANGE</code>: Driver supports a single exchange method
|
|
(vs a recvblock() and sndblock ()methods)
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>SPI-based MMC/SD driver</h3>
|
|
<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>
|
|
<li>
|
|
<code>CONFIG_MMCSD_SPICLOCK</code>: Maximum SPI clock to drive MMC/SD card. Default is 20MHz.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>SDIO-based MMC/SD driver</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_FS_READAHEAD</code>: Enable read-ahead buffering
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_FS_WRITEBUFFER</code>: Enable write buffering
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SDIO_DMA</code>: SDIO driver supports DMA
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_MMCSD_MMCSUPPORT</code>: Enable support for MMC cards
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_MMCSD_HAVECARDDETECT</code>: SDIO driver card detection is 100% accurate
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>RiT P14201 OLED driver</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_LCD_P14201</code>: Enable P14201 support
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_P14201_SPIMODE</code>: Controls the SPI mode
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_P14201_FREQUENCY</code>: Define to use a different bus frequency
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_P14201_NINTERFACES</code>:
|
|
Specifies the number of physical P14201 devices that will be supported.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_P14201_FRAMEBUFFER</code>:
|
|
If defined, accesses will be performed using an in-memory copy of the OLEDs GDDRAM.
|
|
This cost of this buffer is 128 * 96 / 2 = 6Kb.
|
|
If this is defined, then the driver will be fully functional.
|
|
If not, then it will have the following limitations:
|
|
<ul>
|
|
<li>Reading graphics memory cannot be supported, and</li>
|
|
<li>All pixel writes must be aligned to byte boundaries.</li>
|
|
</ul>
|
|
The latter limitation effectively reduces the 128x96 disply to 64x96.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>Nokia 6100 Configuration Settings:</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_SPIMODE</code>: Controls the SPI mode,
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_FREQUENCY</code>: Define to use a different bus frequency.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_NINTERFACES</code>:Specifies the number of physical Nokia
|
|
6100 devices that will be supported.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_BPP</code>: Device supports 8, 12, and 16 bits per pixel.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_S1D15G10</code>: Selects the Epson S1D15G10 display controller
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_PCF8833</code>: Selects the Phillips PCF8833 display controller
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_BLINIT</code>: Initial backlight setting
|
|
</li>
|
|
<p>
|
|
The following may need to be tuned for your hardware:
|
|
</p>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_INVERT</code>: Display inversion, 0 or 1, Default: 1
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_MY</code>: Display row direction, 0 or 1, Default: 0
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_MX</code>: Display column direction, 0 or 1, Default: 1
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_V</code>: Display address direction, 0 or 1, Default: 0
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_ML</code>: Display scan direction, 0 or 1, Default: 0
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NOKIA6100_RGBORD</code>: Display RGB order, 0 or 1, Default: 0
|
|
</li>
|
|
<p>
|
|
Required LCD driver settings:
|
|
</p>
|
|
<li>
|
|
<code>CONFIG_LCD_NOKIA6100</code>: Enable Nokia 6100 support
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_LCD_MAXCONTRAST</code>: Must be 63 with the Epson controller and 127 with
|
|
the Phillips controller.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_LCD_MAXPOWER</code>:Maximum value of backlight setting. The backlight
|
|
control is managed outside of the 6100 driver so this value has no
|
|
meaning to the driver. Board-specific logic may place restrictions on
|
|
this value.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>ENC28J60 Ethernet Driver Configuration Settings</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NET_ENC28J60</code>: Enabled ENC28J60 support
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_ENC28J60_SPIMODE</code>: Controls the SPI mode
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_ENC28J60_FREQUENCY</code>: Define to use a different bus frequency
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_ENC28J60_NINTERFACES</code>:
|
|
Specifies the number of physical ENC28J60 devices that will be supported.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_ENC28J60_STATS</code>: Collect network statistics
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_ENC28J60_HALFDUPPLEX</code>: Default is full duplex
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>Network Support</h2>
|
|
<h3>TCP/IP and UDP support via uIP</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NET</code>: Enable or disable all network features
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_SLIP</code>: Selects the Serial Line Internet Protocol (SLIP) data link layer.
|
|
(This selection is discussed further <a href="#slipdriver">below</a>).
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_NOINTS</code>: <code>CONFIG_NET_NOINT</code> indicates that uIP not called from the interrupt level.
|
|
If <code>CONFIG_NET_NOINTS</code> is defined, critical sections will be managed with semaphores;
|
|
Otherwise, it assumed that uIP will be called from interrupt level handling and critical sections will be managed by enabling and disabling interrupts.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_NET_MULTIBUFFER</code>: Traditionally, uIP has used a single buffer for all incoming and outgoing traffic.
|
|
If this configuration is selected, then the driver can manage multiple I/O buffers and can, for example, be filling one input buffer while sending another output buffer.
|
|
Or, as another example, the driver may support queuing of concurrent input/ouput and output transfers for better performance.
|
|
</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_IGMP</code>: Enable IGMPv2 client support.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_PREALLOC_IGMPGROUPS</code>: Pre-allocated IGMP groups are used
|
|
Only if needed from interrupt level group created (by the IGMP server).
|
|
Default: 4
|
|
</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_ARP_IPIN</code>: Harvest IP/MAC address mappings for the ARP table from incoming IP packets.
|
|
</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_FWCACHE_SIZE</code>: number of packets to remember when looking for duplicates
|
|
</li>
|
|
</ul>
|
|
|
|
<h3><a name="slipdriver">SLIP</a></h3>
|
|
<p>
|
|
The NuttX SLIP driver supports point-to-point IP communications over a serial port.
|
|
The default data link layer for uIP is Ethernet.
|
|
If <code>CONFIG_NET_SLIP</code> is defined in the NuttX configuration file, then SLIP will be supported.
|
|
The basic differences between the SLIP and Ethernet configurations is that when SLIP is selected:
|
|
<ul>
|
|
<li>The link level header (that comes before the IP header) is omitted.</li>
|
|
<li>All MAC address processing is suppressed.</li>
|
|
<li>ARP is disabled.</li>
|
|
</ul>
|
|
If <code>CONFIG_NET_SLIP</code> is not selected, then Ethernet will be used
|
|
(there is no need to define anything special in the configuration file to use Ethernet -- it is the default).
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_NET_SLIP</code>: Enables building of the SLIP driver.
|
|
SLIP requires at least one IP protocols selected and the following additional network settings: <code>CONFIG_NET_NOINTS</code> and <code>CONFIG_NET_MULTIBUFFER</code>.
|
|
<code>CONFIG_NET_BUFSIZE</code> <i>must</i> be set to 296.
|
|
Other optional configuration settings that affect the SLIP driver: <code>CONFIG_NET_STATISTICS</code>.
|
|
Default: Ethernet.
|
|
</li>
|
|
<p>
|
|
If SLIP is selected, then the following SLIP options are available:
|
|
</p>
|
|
<li>
|
|
<code>CONFIG_CLIP_NINTERFACES</code>: Selects the number of physical SLIP interfaces to support. Default: 1
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SLIP_STACKSIZE</code>: Select the stack size of the SLIP RX and TX tasks. Default: 2048
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_SLIP_DEFPRIO</code>: The priority of the SLIP RX and TX tasks. Default: 128
|
|
</li>
|
|
</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>
|
|
|
|
<h3>THTTPD</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_THTTPD_PORT</code>: THTTPD Server port number
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_IPADDR</code>: Server IP address (no host name)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_SERVER_ADDRESS</code>: SERVER_ADDRESS: response
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_SERVER_SOFTWARE</code>: SERVER_SOFTWARE: response
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_PATH</code>: Server working directory. Default: <code>/mnt/www</code>.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_CGI_PATH</code>: Path to CGI executables. Default: <code>/mnt/www/cgi-bin</code>.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_CGI_PATTERN</code>: Only CGI programs whose expanded paths
|
|
match this pattern will be executed. In fact, if this value is not defined
|
|
then no CGI logic will be built. Default: <code>/mnt/www/cgi-bin/*</code>.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_CGI_PRIORITY</code>: Provides the priority of CGI child tasks
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_CGI_STACKSIZE</code>: Provides the initial stack size of
|
|
CGI child task (will be overridden by the stack size in the NXFLAT
|
|
header)
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_CGI_BYTECOUNT</code>: Byte output limit for CGI tasks.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_CGI_TIMELIMIT</code>: How many seconds to allow CGI programs
|
|
to run before killing them.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_CHARSET</code>: The default character set name to use with
|
|
text MIME types.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_IOBUFFERSIZE</code>:
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_INDEX_NAMES</code>: A list of index filenames to check. The
|
|
files are searched for in this order.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_AUTH_FILE</code>: The file to use for authentication. If this is
|
|
defined then thttpd checks for this file in the local directory
|
|
before every fetch. If the file exists then authentication is done,
|
|
otherwise the fetch proceeds as usual. If you leave this undefined
|
|
then thttpd will not implement authentication at all and will not
|
|
check for auth files, which saves a bit of CPU time. A typical
|
|
value is ".htpasswd&quout;
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_LISTEN_BACKLOG</code>: The listen() backlog queue length.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_LINGER_MSEC</code>: How many milliseconds to leave a connection
|
|
open while doing a lingering close.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_OCCASIONAL_MSEC</code>: How often to run the occasional
|
|
cleanup job.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_IDLE_READ_LIMIT_SEC</code>: How many seconds to allow for
|
|
reading the initial request on a new connection.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_IDLE_SEND_LIMIT_SEC</code>: How many seconds before an
|
|
idle connection gets closed.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_TILDE_MAP1 and CONFIG_THTTPD_TILDE_MAP2</code>: Tilde mapping.
|
|
Many URLs use ~username to indicate a user's home directory. thttpd
|
|
provides two options for mapping this construct to an actual filename.
|
|
<ol>
|
|
<li>
|
|
Map ~username to <prefix>/username. This is the recommended choice.
|
|
Each user gets a subdirectory in the main web tree, and the tilde
|
|
construct points there. The prefix could be something like "users",
|
|
or it could be empty.
|
|
</li>
|
|
<li>
|
|
Map ~username to <user's homedir>/<postfix>. The postfix would be
|
|
the name of a subdirectory off of the user's actual home dir,
|
|
something like "public_html".
|
|
</li>
|
|
</ol>
|
|
You can also leave both options undefined, and thttpd will not do
|
|
anything special about tildes. Enabling both options is an error.
|
|
Typical values, if they're defined, are "users" for
|
|
CONFIG_THTTPD_TILDE_MAP1 and "public_html" forCONFIG_THTTPD_TILDE_MAP2.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_GENERATE_INDICES</code>:
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_THTTPD_URLPATTERN</code>: If defined, then it will be used to match
|
|
and verify referrers.
|
|
</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>USB Host-Side Support</h2>
|
|
<h3>USB Host Controller Driver</h3>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_USBHOST</code>: Enables USB host support
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBHOST_NPREALLOC</code>: Number of pre-allocated class instances
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBHOST_BULK_DISABLE</code>: On some architectures, selecting this setting will reduce driver size by disabling bulk endpoint support
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBHOST_INT_DISABLE</code>: On some architectures, selecting this setting will reduce driver size by disabling interrupt endpoint support
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_USBHOST_ISOC_DISABLE</code>: On some architectures, selecting this setting will reduce driver size by disabling isochronous endpoint support
|
|
</li>
|
|
</ul>
|
|
<h3>USB Host HID Class Driver</h3>
|
|
<p>
|
|
Requires <code>CONFIG_USBHOST=y</code>, <code>CONFIG_USBHOST_INT_DISABLE=n</code>, <code>CONFIG_NFILE_DESCRIPTORS > 0</code>,
|
|
<code>CONFIG_SCHED_WORKQUEUE=y</code>, and <code>CONFIG_DISABLE_SIGNALS=n</code>.
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>CONFIG_HIDKBD_POLLUSEC</code>: Device poll rate in microseconds. Default: 100 milliseconds.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_HIDKBD_DEFPRIO</code>: Priority of the polling thread. Default: 50.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_HIDKBD_STACKSIZE</code>: Stack size for polling thread. Default: 1024
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_HIDKBD_BUFSIZE</code>: Scancode buffer size. Default: 64.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_HIDKBD_NPOLLWAITERS</code>: If the poll() method is enabled, this defines the maximum number of threads that can be waiting for keyboard events. Default: 2.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_HIDKBD_RAWSCANCODES</code>: If set to <code>y</code> no conversion will be made on the raw keyboard scan codes. Default: ASCII conversion.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_HIDKBD_ALLSCANCODES</code>: If set to <code>y</code> all 231 possible scancodes will be converted to something. Default: 104 key US keyboard.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_HIDKBD_NODEBOUNCE</code>: If set to <code>y</code> normal debouncing is disabled. Default: Debounce/No repeat keys.
|
|
</li>
|
|
</ul>
|
|
<h3>USB Host HID Mass Storage Class Driver</h3>
|
|
<p>
|
|
Requires <code>CONFIG_USBHOST=y</code>, <code>CONFIG_USBHOST_BULK_DISABLE=n</code>, <code>CONFIG_NFILE_DESCRIPTORS > 0</code>,
|
|
and <code>CONFIG_SCHED_WORKQUEUE=y</code>.
|
|
</p>
|
|
|
|
<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_LCDDRIVER</code>:
|
|
By default, NX builds to use a framebuffer driver (see <code>include/nuttx/fb.h</code>).
|
|
If this option is defined, NX will build to use an LCD driver (see <code>include/nuttx/lcd/lcd.h</code>).
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_LCD_MAXPOWER</code>:
|
|
The full-on power setting for an LCD device.
|
|
</li>
|
|
<li>
|
|
<code>CONFIG_LCD_MAXCONTRAST</code>:
|
|
The maximum contrast value for an LCD device.
|
|
</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 initial 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 trade name 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>
|
|
|
|
|