2007-02-17 23:21:28 +00:00
|
|
|
<html>
|
|
|
|
|
|
|
|
|
|
<head>
|
2007-02-28 01:16:49 +00:00
|
|
|
<title>NuttX Porting Manual</title>
|
2007-02-17 23:21:28 +00:00
|
|
|
<meta name="author" content="Gregory Nutt">
|
|
|
|
|
</head>
|
|
|
|
|
|
2007-02-28 01:16:49 +00:00
|
|
|
<body background="backgd.gif">
|
2007-02-22 01:50:30 +00:00
|
|
|
<hr>
|
|
|
|
|
<center><h1><i>Under Construction</i></h1></center>
|
|
|
|
|
<hr>
|
2007-02-17 23:21:28 +00:00
|
|
|
<center>
|
|
|
|
|
<big><b>
|
2007-03-19 22:45:58 +00:00
|
|
|
<p>NuttX Operating System</p>
|
2007-02-17 23:21:28 +00:00
|
|
|
<p>Porting Guide</p>
|
|
|
|
|
</b></big>
|
|
|
|
|
<p><small>by</small></p>
|
|
|
|
|
<p>Gregory Nutt</p>
|
2007-03-23 02:25:54 +00:00
|
|
|
<p><small>Last Update: March 22, 2007</small></p>
|
2007-02-17 23:21:28 +00:00
|
|
|
</center>
|
|
|
|
|
|
|
|
|
|
<center><h1>Table of Contents</h1></center>
|
|
|
|
|
<li>1.0 <a href="#Introduction">1.0 Introduction</a></li>
|
|
|
|
|
<li>2.0 <a href="#DirectoryStructure">Directory Structure</a></li>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>2.1 <a href="#DirStructDocumentation">Documentation</a></li>
|
|
|
|
|
<l1>2.2 <a href="#DirStructArch">arch</a></li>
|
2007-03-19 22:45:58 +00:00
|
|
|
<ul>
|
2007-03-23 02:25:54 +00:00
|
|
|
<li><a href="#archdirectorystructure">2.2.1 Subdirectory Structure</a></li>
|
|
|
|
|
<li><a href="#summaryofarchfiles">2.2.2 Summary of Files</a></li>
|
2007-03-19 22:45:58 +00:00
|
|
|
<li><a href="#supportedarchitectures">2.2.3 Supported Architectures</a></li>
|
|
|
|
|
</ul>
|
2007-03-23 02:25:54 +00:00
|
|
|
<li>2.3 <a href="#DirStructConfigs">configs/</a></li>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><a href="#configsdirectorystructure">2.3.1 Subdirectory Structure</a></li>
|
|
|
|
|
<li><a href="#summaryofconfigfiles">2.3.2 Summary of Files</a></li>
|
|
|
|
|
<li><a href="#supportedboards">2.3.3 Supported Boards</a></li>
|
|
|
|
|
<li><a href="#configuringnuttx">2.3.4 Configuring NuttX</a></li>
|
|
|
|
|
</ul>
|
|
|
|
|
<li>2.4 <a href="#DirStructDrivers">drivers</a></li>
|
|
|
|
|
<li>2.5 <a href="#DirStructExamples">examples</a></li>
|
|
|
|
|
<li>2.6 <a href="#DirStructFs">fs</a></li>
|
|
|
|
|
<li>2.7 <a href="#DirStructInclude">include</a></li>
|
|
|
|
|
<li>2.8 <a href="#DirStructLib">lib</a></li>
|
|
|
|
|
<li>2.9 <a href="#DirStructMm">mm</a></li>
|
|
|
|
|
<li>2.10 <a href="#DirStructSched">sched</a></li>
|
|
|
|
|
<li>2.11 <a href="#DirStructTools">tools</a></li>
|
2007-02-17 23:21:28 +00:00
|
|
|
</ul>
|
|
|
|
|
<li>3.0 <a href="#DirectoryConfiAndBuild">Configuring and Building</a></li>
|
2007-03-19 22:45:58 +00:00
|
|
|
<li>4.0 <a href="#ArchAPIs">Architecture APIs</a></li>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><a href="#imports">4.1 APIs Exported by Architecture-Specific Logic to NuttX</a></li>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><a href="#upinitialize">4.1.1 <code>up_initialize()</code></a></li>
|
|
|
|
|
<li><a href="#upidle">4.1.2 <code>up_idle()</code></a></li>
|
|
|
|
|
<li><a href="#upinitialstate">4.1.3 <code>up_initial_state()</code></a></li>
|
|
|
|
|
<li><a href="#upcreatestack">4.1.4 <code>up_create_stack()</code></a></li>
|
|
|
|
|
<li><a href="#upusestack">4.1.5 <code>up_use_stack()</code></a></li>
|
|
|
|
|
<li><a href="#upreleasestack">4.1.6 <code>up_release_stack()</code></a></li>
|
|
|
|
|
<li><a href="#upunblocktask">4.1.7 <code>up_unblock_task()</code></a></li>
|
|
|
|
|
<li><a href="#upblocktask">4.1.8 <code>up_block_task()</code></a></li>
|
|
|
|
|
<li><a href="#upreleasepending">4.1.9 <code>up_release_pending()</code></a></li>
|
|
|
|
|
<li><a href="#upreprioritizertr">4.1.10 <code>up_reprioritize_rtr()</code></a></li>
|
|
|
|
|
<li><a href="#_exit">4.1.11 <code>_exit()</code></a></li>
|
|
|
|
|
<li><a href="#upassert">4.1.12 <code>up_assert()</code></a></li>
|
|
|
|
|
<li><a href="#upschedulesigaction">4.1.13 <code>up_schedule_sigaction()</code></a></li>
|
|
|
|
|
<li><a href="#upallocateheap">4.1.14 <code>up_allocate_heap()</code></a></li>
|
|
|
|
|
<li><a href="#upinterruptcontext">4.1.15 <code>up_interrupt_context()</code></a></li>
|
|
|
|
|
<li><a href="#updisableirq">4.1.16 <code>up_disable_irq()</code></a></li>
|
|
|
|
|
<li><a href="#upenableirq">4.1.17 <code>up_enable_irq()</code></a></li>
|
|
|
|
|
<li><a href="#upputc">4.1.18 <code>up_putc()</code></a></li>
|
|
|
|
|
</ul>
|
|
|
|
|
<li><a href="#exports">4.2 APIs Exported by NuttX to Architecture-Specific Logic</a></li>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><a href="#osstart">4.2.1 <code>os_start()</code></a></li>
|
|
|
|
|
<li><a href="#listmgmt">4.2.2 OS List Management APIs</a></li></li>
|
|
|
|
|
<li><a href="#schedprocesstimer">4.2.3 <code>sched_process_timer()</code></a></li>
|
|
|
|
|
<li><a href="#irqdispatch">4.2.4 <code>irq_dispatch()</code></a></li>
|
|
|
|
|
</ul>
|
|
|
|
|
</ul>
|
2007-02-17 23:21:28 +00:00
|
|
|
|
|
|
|
|
<hr>
|
|
|
|
|
<h1>1.0 <a name="Introduction">Introduction</a></h1>
|
|
|
|
|
|
|
|
|
|
<p><b>Overview</b>
|
2007-03-19 22:45:58 +00:00
|
|
|
This document provides and overview of the NuttX build and configuration
|
2007-02-17 23:21:28 +00:00
|
|
|
logic and provides hints for the incorporation of new processor/board archectures
|
|
|
|
|
into the build.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
See also arch/README.txt.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p><b>General Philosophy</b>.
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
|
|
|
<h1>2.0 <a name="DirectoryStructure">Directory Structure</a></h1>
|
|
|
|
|
|
2007-03-19 22:45:58 +00:00
|
|
|
<p>The general directly layout for NuttX is very similar to the directory structure
|
2007-02-17 23:21:28 +00:00
|
|
|
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>
|
|
|
|
|
.
|
|
|
|
|
|-- Makefile
|
|
|
|
|
|-- <a href="#DirStructDocumentation">Documentation</a>
|
|
|
|
|
| `-- <i>(documentation files)</i>
|
|
|
|
|
|-- <a href="#DirStructArch">arch</a>
|
2007-03-23 02:25:54 +00:00
|
|
|
| |-- <i><arch-name></i>
|
2007-02-17 23:21:28 +00:00
|
|
|
| | |-- include
|
|
|
|
|
| | `-- src
|
2007-03-23 02:25:54 +00:00
|
|
|
| `-- <i><:;other-architectures></i>
|
|
|
|
|
|-- <a href="#DirStructConfigs">configs</a>
|
|
|
|
|
| |-- <i><board-name></i>
|
|
|
|
|
| | |-- Make.defs
|
|
|
|
|
| | |-- defconfig
|
|
|
|
|
| | `-- setenv.sh
|
|
|
|
|
| `-- <i><:;other-architectures></i>
|
2007-02-17 23:21:28 +00:00
|
|
|
|-- <a href="#DirStructDrivers">drivers</a>
|
|
|
|
|
| |-- Makefile
|
|
|
|
|
| `-- <i>(driver source files)</i>
|
|
|
|
|
|-- <a href="#DirStructExamples">examples</a>
|
|
|
|
|
| `-- <i>(example)</i>
|
|
|
|
|
| |-- Makefile
|
|
|
|
|
| `-- <i>(example source files)</i>
|
|
|
|
|
|-- <a href="#DirStructFs">fs</a>
|
|
|
|
|
| |-- Makefile
|
|
|
|
|
| `-- <i>(fs source files)</i>
|
|
|
|
|
|-- <a href="#DirStructInclude">include</a>
|
|
|
|
|
| |-- <i>(standard header files)</i>
|
|
|
|
|
| |-- nuttx
|
|
|
|
|
| | `-- <i>(nuttx specific header files)</i>
|
|
|
|
|
| `- sys
|
|
|
|
|
| | `-- <i>(more standard header files)</i>
|
|
|
|
|
|-- <a href="#DirStructLib">lib</a>
|
|
|
|
|
| |-- Makefile
|
|
|
|
|
| `-- <i>(lib source files)</i>
|
|
|
|
|
|-- <a href="#DirStructMm">mm</a>
|
|
|
|
|
| |-- Makefile
|
|
|
|
|
| `-- <i>(mm source files)</i>
|
|
|
|
|
|-- <a href="#DirStructSched">sched</a>
|
|
|
|
|
| |-- Makefile
|
|
|
|
|
| `-- <i>(sched source files)</i>
|
|
|
|
|
`-- <a href="#DirStructDrivers">tools</a>
|
|
|
|
|
|-- Makefile.mkconfig
|
|
|
|
|
|-- configure.sh
|
|
|
|
|
|-- mkconfig.c
|
|
|
|
|
|-- mkdeps.sh
|
|
|
|
|
`-- zipme
|
|
|
|
|
</pre></ul>
|
|
|
|
|
|
|
|
|
|
<h2>2.1 <a name="DirStructDocumentation">Documentation</a></h2>
|
2007-03-19 22:45:58 +00:00
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
General documentation for the NuttX OS resides in this directory.
|
|
|
|
|
</p>
|
|
|
|
|
|
2007-02-17 23:21:28 +00:00
|
|
|
<h2>2.2 <a name="DirStructArch">arch</a></h2>
|
2007-03-19 22:45:58 +00:00
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h3><a name="archdirectorystructure">2.2.1 Subdirectory Structure</a></h3>
|
2007-03-19 22:45:58 +00:00
|
|
|
<p>
|
|
|
|
|
This directory contains several sub-directories, each containing
|
|
|
|
|
architecture-specific logic.
|
2007-03-23 02:25:54 +00:00
|
|
|
The task of porting NuttX to a new processor consists of
|
2007-03-19 22:45:58 +00:00
|
|
|
add a new sudirectory under <code>arch/</code> containing logic specific
|
|
|
|
|
to the new architecuture.
|
2007-03-23 02:25:54 +00:00
|
|
|
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).
|
2007-03-19 22:45:58 +00:00
|
|
|
Each architecture must provide a subdirectory, <<i>arch-name</i>>
|
2007-03-23 02:25:54 +00:00
|
|
|
under <code>arch/</code> with the following characteristics:
|
2007-03-19 22:45:58 +00:00
|
|
|
</p>
|
|
|
|
|
<ul><pre>
|
|
|
|
|
<<i>arch-name</i>>
|
2007-03-26 16:47:17 +00:00
|
|
|
|-- include/
|
2007-03-19 22:45:58 +00:00
|
|
|
| |-- arch.h
|
|
|
|
|
| |-- irq.h
|
2007-03-23 16:02:36 +00:00
|
|
|
| |-- types.h
|
|
|
|
|
| `-- limits.h
|
2007-03-26 16:47:17 +00:00
|
|
|
`-- src/
|
2007-03-19 22:45:58 +00:00
|
|
|
|-- Makefile
|
2007-03-23 02:25:54 +00:00
|
|
|
`-- <i>(architecture-specific source files)</i>
|
2007-03-19 22:45:58 +00:00
|
|
|
</pre></ul>
|
|
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h3><a name="summaryofarchfiles">2.2.2 Summary of Files</a></h3>
|
2007-03-19 22:45:58 +00:00
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>include/arch.h</code>:
|
|
|
|
|
This is a hook for any architecture specific definitions that may
|
|
|
|
|
be needed by the system. It is included by <code>include/nuttx/arch.h</code>.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>include/types.h</code>:
|
|
|
|
|
This provides architecture/toolchain-specific definitions for
|
|
|
|
|
standard types. This file should <code>typedef</code>:
|
|
|
|
|
<ul><code>
|
|
|
|
|
sbyte, ubyte, uint8, boolean, sint16, uint16, sint32, uint32
|
|
|
|
|
</code></ul>
|
|
|
|
|
<p>and if the architecture supports 64-bit integers</p>
|
|
|
|
|
<ul><code>
|
|
|
|
|
sint64, uint64
|
|
|
|
|
</code></ul>
|
|
|
|
|
<p>
|
|
|
|
|
and finally
|
|
|
|
|
</p>
|
|
|
|
|
<ul><code>
|
|
|
|
|
irqstate_t
|
|
|
|
|
</code></ul>
|
|
|
|
|
<p>
|
|
|
|
|
Must be defined to the be the size required to hold the interrupt
|
|
|
|
|
enable/disable state.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
This file will be included by include/sys/types.h and be made
|
|
|
|
|
available to all files.
|
|
|
|
|
</p>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>include/irq.h</code>:
|
|
|
|
|
This file needs to define some architecture specific functions (usually
|
|
|
|
|
inline if the compiler supports inlining) and structure. These include:
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>struct xcptcontext</code>:
|
|
|
|
|
This structures represents the saved context of a thread.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>irqstate_t irqsave(void)</code>:
|
|
|
|
|
Used to disable all interrupts.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>void irqrestore(irqstate_t flags)<code>:
|
|
|
|
|
Used to restore interrupt enables to the same state as before <code>irqsave()</code> was called.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
This file must also define <code>NR_IRQS</code>, the total number of IRQs supported
|
|
|
|
|
by the board.
|
|
|
|
|
</p>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>src/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>
|
2007-03-23 02:25:54 +00:00
|
|
|
<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/<arch-name>/arch.h</code> as described above).
|
|
|
|
|
</li>
|
2007-03-19 22:45:58 +00:00
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h3><a name="supportedarchitectures">2.2.3 Supported Architectures</a></h3>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><code>arch/sim</code>:
|
|
|
|
|
A user-mode port of NuttX to the x86 Linux platform is available.
|
|
|
|
|
The purpose of this port is primarily to support OS feature developement.
|
|
|
|
|
This port does not support interrupts or a real timer (and hence no
|
|
|
|
|
round robin scheduler) Otherwise, it is complete.
|
|
|
|
|
<li><code>arch/c5471</code>:
|
|
|
|
|
TI TMS320C5471 (also called TMS320DM180 or just C5471).
|
2007-03-23 02:25:54 +00:00
|
|
|
NuttX operates on the ARM7 of this dual core processor.
|
|
|
|
|
This port is complete, verified, and included in the NuttX release 0.1.1.
|
2007-03-19 22:45:58 +00:00
|
|
|
<li><code>arch/dm320</code>:
|
|
|
|
|
TI TMS320DM320 (also called just DM320).
|
|
|
|
|
NuttX operates on the ARM9EJS of this dual core processor.
|
2007-03-23 02:25:54 +00:00
|
|
|
This port complete, verified, and included in the NuttX release 0.2.1.
|
|
|
|
|
<li><code>arch/m68322</code>
|
|
|
|
|
A work in progress.</li>
|
2007-03-19 22:45:58 +00:00
|
|
|
<li><code>arch/pjrc-8051</code>:
|
2007-03-23 02:25:54 +00:00
|
|
|
8051 Microcontroller. This port is not quite ready for prime time.</li>
|
2007-03-19 22:45:58 +00:00
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
Other ports for the for the TI TMS320DM270 and for MIPS are in various states
|
|
|
|
|
of progress
|
|
|
|
|
</p>
|
|
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h2>2.3 <a name="DirStructConfigs">configs</a></h2>
|
|
|
|
|
<p>
|
|
|
|
|
The <code>configs/</code> subdirectory contains configuration data for each board.
|
|
|
|
|
These board-specific configurations plus the architecture-specific configurations in
|
|
|
|
|
the <code>arch/</code> subdirectory complete define a customized port of NuttX.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="configsdirectorystructure">2.3.1 Subdirectory Structure</a></h3>
|
|
|
|
|
<p>
|
|
|
|
|
The configs directory contains board specific configuration files. Each board must
|
|
|
|
|
provide a subdirectory <board-name> under <code>configs/</code> with the following characteristics:
|
|
|
|
|
</p>
|
|
|
|
|
<ul><pre>
|
|
|
|
|
<<i>board-name</i>>
|
2007-03-26 16:47:17 +00:00
|
|
|
|-- include/
|
2007-03-26 22:14:28 +00:00
|
|
|
|-- src/
|
|
|
|
|
| `-- Makefile
|
2007-03-23 02:25:54 +00:00
|
|
|
|-- Make.defs
|
|
|
|
|
|-- defconfig
|
|
|
|
|
`-- setenv.sh
|
|
|
|
|
</pre></ul>
|
|
|
|
|
|
|
|
|
|
<h3><a name="#summaryofconfigfiles">2.3.2 Summary of Files</a></h3>
|
|
|
|
|
<ul>
|
2007-03-26 16:47:17 +00:00
|
|
|
<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/<arch-name>/include/</code>
|
|
|
|
|
and <code>arch/<arch-name>/src/</code>.
|
|
|
|
|
</li>
|
2007-03-26 22:14:28 +00:00
|
|
|
<li>
|
|
|
|
|
<code>src/</code>:
|
|
|
|
|
This directory contains board specific drivers.
|
|
|
|
|
This directory will be linked as <config>arch/<arch-name>/src/board</config> at configuration
|
|
|
|
|
time and will be integrated into the build system.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>src/Makefile</code>:
|
|
|
|
|
This makefile will be invoked to build the board specific drivers.
|
|
|
|
|
It must support the following targets: <code>libext$(LIBEXT)</code>, <code>clean</code>, and <code>distclean</code>.
|
|
|
|
|
</li>
|
2007-03-23 02:25:54 +00:00
|
|
|
<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>
|
|
|
|
|
</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.
|
2007-03-26 16:47:17 +00:00
|
|
|
</p>
|
2007-03-23 02:25:54 +00:00
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>defconfig</code>: This is a configuration file similar to the Linux
|
|
|
|
|
configuration file. In contains varialble/value pairs like:
|
|
|
|
|
<ul>
|
|
|
|
|
<li><code>CONFIG_VARIABLE</code>=value</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
This configuration file will be used at build time:
|
|
|
|
|
</p>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>As a makefile fragment included in other makefiles, and</li>
|
|
|
|
|
<li>to generate <code>include/nuttx/config.h</code> which is included by
|
|
|
|
|
most C files in the system.</li>
|
|
|
|
|
</ol>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>setenv.sh</code>: This is a script that you can include that will be installed at
|
|
|
|
|
the toplevel of the directory structure and can be sourced to set any
|
|
|
|
|
necessary environment variables.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h3><a name="#supportedboards">2.3.3 Supported Boards</a></h3>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><code>configs/sim</code>:
|
|
|
|
|
A user-mode port of NuttX to the x86 Linux platform is available.
|
|
|
|
|
The purpose of this port is primarily to support OS feature developement.
|
|
|
|
|
This port does not support interrupts or a real timer (and hence no
|
|
|
|
|
round robin scheduler) Otherwise, it is complete.</li>
|
|
|
|
|
|
|
|
|
|
<li><code>configs/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*. This port is complete, verified, and
|
|
|
|
|
included in the NuttX release.</li>
|
|
|
|
|
|
|
|
|
|
<li><code>configs/ntosd-dm320</code>:
|
|
|
|
|
This port uses the Neuros OSD with a GNU arm-elf toolchain*.
|
|
|
|
|
See <a href="http://wiki.neurostechnology.com/index.php/Developer_Welcome">Neuros Wiki</a>
|
|
|
|
|
for futher information.
|
|
|
|
|
NuttX operates on the ARM9EJS of this dual core processor.
|
|
|
|
|
STATUS: This port is code complete, verified, and included in the
|
|
|
|
|
NuttX 0.2.1 release.</li>
|
|
|
|
|
|
|
|
|
|
<li><code>configs/m68322evb</code>:
|
|
|
|
|
This is a work in progress for the venerable m68322evb board from
|
|
|
|
|
Motorola.</li>
|
|
|
|
|
|
|
|
|
|
<li><code>configs/pjrc-8051</code>:
|
|
|
|
|
8051 Microcontroller. This port uses the PJRC 87C52 development system
|
|
|
|
|
and the SDCC toolchain. This port is not quite ready for prime time.</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p><small><blockquote>
|
|
|
|
|
* A customized version of the <a href="http://www.buildroot.org">buildroot</a>
|
|
|
|
|
is available to build these toolchains.
|
|
|
|
|
</blockquote></small></p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="configuringnuttx">2.3.4 Configuring NuttX</a></h3>
|
2007-03-19 22:45:58 +00:00
|
|
|
<p>
|
|
|
|
|
Configuring NuttX requires only copying:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
2007-03-23 02:25:54 +00:00
|
|
|
<code>configs/<<i>board-name</i>>/Make.def</code> to <code>${TOPDIR}/Make.defs</code>,
|
|
|
|
|
<code>configs/<<i>board-name</i>>/setenv.sh</code> to <code>${TOPDIR}/setenv.sh</code>, and
|
|
|
|
|
<code>configs/<<i>board-name</i>>/defconfig</code> to ${TOPDIR}/.config</code>
|
2007-03-19 22:45:58 +00:00
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
There is a script that automates these steps. The following steps will
|
|
|
|
|
accomplish the same configuration:
|
|
|
|
|
</p>
|
|
|
|
|
<ul><pre>
|
|
|
|
|
cd tools
|
2007-03-23 02:25:54 +00:00
|
|
|
./configure.sh <<i>board-name</i>>
|
2007-03-19 22:45:58 +00:00
|
|
|
</pre></ul>
|
|
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h2>2.4 <a name="DirStructDrivers">drivers</a></h2>
|
2007-03-19 22:45:58 +00:00
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
This directory holds architecture-independent device drivers.
|
|
|
|
|
</p>
|
|
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h2>2.5 <a name="DirStructExamples">examples</a></h2>
|
2007-03-19 22:45:58 +00:00
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Example and test programs to build against.
|
|
|
|
|
</p>
|
|
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h2>2.6 <a name="DirStructFs">fs</a></h2>
|
2007-03-19 22:45:58 +00:00
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
This directory contains the NuttX filesystem.
|
|
|
|
|
The NuttX filesystem is very simple; it does not involve any block drivers or
|
|
|
|
|
particular filesystem (like FAT or EXT2 etc.).
|
|
|
|
|
The NuttX filesystem simply supports a set a filesystem APIs
|
|
|
|
|
(<code>open()</code>, <code>close()</code>, <code>read()</code>, <code>write</code>, etc.)
|
|
|
|
|
and a registration mechanism that allows devices drivers to a associated with <i>nodes</i>
|
|
|
|
|
in a file-system-like name space.
|
|
|
|
|
</p>
|
|
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h2>2.7 <a name="DirStructInclude">include</a></h2>
|
2007-03-19 22:45:58 +00:00
|
|
|
<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>
|
|
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h2>2.8 <a name="DirStructLib">lib</a></h2>
|
2007-03-19 22:45:58 +00:00
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
This directory holds a collection of standard libc-like functions with custom
|
|
|
|
|
interfaces into Nuttx.
|
|
|
|
|
</p>
|
|
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h2>2.9 <a name="DirStructMm">mm</a></h2>
|
2007-03-19 22:45:58 +00:00
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
This is the NuttX memory manager.
|
|
|
|
|
</p>
|
|
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h2>2.10 <a name="DirStructSched">sched</a></h2>
|
2007-03-19 22:45:58 +00:00
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The files forming core of the NuttX RTOS reside here.
|
|
|
|
|
</p>
|
|
|
|
|
|
2007-03-23 02:25:54 +00:00
|
|
|
<h2>2.11 <a name="DirStructTools">tools</a></h2>
|
2007-02-17 23:21:28 +00:00
|
|
|
|
2007-03-19 22:45:58 +00:00
|
|
|
<p>
|
|
|
|
|
This directory holds a collection of tools and scripts to simplify
|
|
|
|
|
configuring and building NuttX.
|
|
|
|
|
</p>
|
|
|
|
|
|
2007-02-17 23:21:28 +00:00
|
|
|
<hr>
|
|
|
|
|
<h1>3.0 <a name="DirectoryConfiAndBuild">Configuring and Building</a></h1>
|
|
|
|
|
|
2007-03-19 22:45:58 +00:00
|
|
|
<h1>4.0 <a name="ArchAPIs">Architecture APIs</a></h1>
|
|
|
|
|
|
|
|
|
|
<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 device drivers are some of the
|
|
|
|
|
things that are different for each processor and hardware
|
|
|
|
|
platform.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
<code>up_initialize()</code> is called after the OS initialized but
|
|
|
|
|
before the init process has been started and before the
|
|
|
|
|
libraries have been initialized. OS services and driver
|
|
|
|
|
services are available.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upidle">4.1.2 <code>up_idle()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void up_idle(void);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
<code>up_idle()</code> is the logic that will be executed
|
|
|
|
|
when their is no other ready-to-run task. This is processor
|
|
|
|
|
idle time and will continue until some interrupt occurs to
|
|
|
|
|
cause a context switch from the idle task.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Processing in this state may be processor-specific. e.g.,
|
|
|
|
|
this is where power management operations might be performed.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upinitialstate">4.1.3 <code>up_initial_state()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void up_initial_state(FAR _TCB *tcb);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
A new thread is being started and a new TCB
|
|
|
|
|
has been created. This function is called to initialize
|
|
|
|
|
the processor specific portions of the new TCB.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
This function must setup the intial architecture registers
|
|
|
|
|
and/or stack so that execution will begin at tcb->start
|
|
|
|
|
on the next context switch.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upcreatestack">4.1.4 <code>up_create_stack()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>STATUS up_create_stack(FAR _TCB *tcb, size_t stack_size);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
Allocate a stack for a new thread and setup
|
|
|
|
|
up stack-related information in the TCB.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
The following TCB fields must be initialized:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><code>adj_stack_size</code>: Stack size after adjustment for hardware,
|
|
|
|
|
processor, etc. This value is retained only for debug
|
|
|
|
|
purposes.</li>
|
|
|
|
|
<li><code>stack_alloc_ptr</code>: Pointer to allocated stack</li>
|
|
|
|
|
<li><code>adj_stack_ptr</code>: Adjusted <code>stack_alloc_ptr</code> for HW. The
|
|
|
|
|
initial value of the stack pointer.
|
|
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
This API is <i>NOT</i> required if <code>CONFIG_CUSTOM_STACK</code>
|
|
|
|
|
is defined.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p><b>Inputs</b>:</p?
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>tcb</code>: The TCB of new task.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>stack_size</code>: The requested stack size. At least this much
|
|
|
|
|
must be allocated.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upusestack">4.1.5 <code>up_use_stack()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>:
|
|
|
|
|
<code>STATUS up_use_stack(FAR _TCB *tcb, FAR void *stack, size_t stack_size);</code>
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
Setup up stack-related information in the TCB
|
|
|
|
|
using pre-allocated stack memory.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
The following TCB fields must be initialized:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><code>adj_stack_size</code>: Stack size after adjustment for hardware,
|
|
|
|
|
processor, etc. This value is retained only for debug
|
|
|
|
|
purposes.</li>
|
|
|
|
|
<li><code>stack_alloc_ptr</code>: Pointer to allocated stack</li>
|
|
|
|
|
<li><code>adj_stack_ptr</code>: Adjusted <code>stack_alloc_ptr</code> for HW. The
|
|
|
|
|
initial value of the stack pointer.
|
|
|
|
|
</ul>
|
|
|
|
|
<p>
|
|
|
|
|
This API is <i>NOT</i> required if <code>CONFIG_CUSTOM_STACK</code>
|
|
|
|
|
is defined.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p><b>Inputs:</b></p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>tcb</code>: The TCB of new task.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>stack_size</code>: The allocated stack size.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upreleasestack">4.1.6 <code>up_release_stack()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void up_release_stack(FAR _TCB *dtcb);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
A task has been stopped. Free all stack
|
|
|
|
|
related resources retained int the defunct TCB.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
This API is <i>NOT</i> required if <code>CONFIG_CUSTOM_STACK</code>
|
|
|
|
|
is defined.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upunblocktask">4.1.7 <code>up_unblock_task()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void up_unblock_task(FAR _TCB *tcb);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
A task is currently in an inactive task list
|
|
|
|
|
but has been prepped to execute. Move the TCB to the
|
|
|
|
|
ready-to-run list, restore its context, and start execution.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
This function is called only from the NuttX scheduling
|
|
|
|
|
logic. Interrupts will always be disabled when this
|
|
|
|
|
function is called.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p><b>Inputs</b>:
|
|
|
|
|
<ul>
|
|
|
|
|
<li><code>tcb</code>: Refers to the tcb to be unblocked. This tcb is
|
|
|
|
|
in one of the waiting tasks lists. It must be moved to
|
|
|
|
|
the ready-to-run list and, if it is the highest priority
|
|
|
|
|
ready to run taks, executed.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upblocktask">4.1.8 <code>up_block_task()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void up_block_task(FAR _TCB *tcb, tstate_t task_state);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
The currently executing task at the head of
|
|
|
|
|
the ready to run list must be stopped. Save its context
|
|
|
|
|
and move it to the inactive list specified by task_state.
|
|
|
|
|
|
|
|
|
|
This function is called only from the NuttX scheduling
|
|
|
|
|
logic. Interrupts will always be disabled when this
|
|
|
|
|
function is called.
|
|
|
|
|
|
|
|
|
|
<p><b>Inputs:</b></p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><code>tcb</code>: Refers to a task in the ready-to-run list (normally
|
|
|
|
|
the task at the the head of the list). It most be
|
|
|
|
|
stopped, its context saved and moved into one of the
|
|
|
|
|
waiting task lists. It it was the task at the head
|
|
|
|
|
of the ready-to-run list, then a context to the new
|
|
|
|
|
ready to run task must be performed.
|
|
|
|
|
</li>
|
|
|
|
|
<li><code>task_state</code>: Specifies which waiting task list should be
|
|
|
|
|
hold the blocked task TCB.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upreleasepending">4.1.9 <code>up_release_pending()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void up_release_pending(void);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
When tasks become ready-to-run but cannot run because pre-emption
|
|
|
|
|
is disabled, they are placed into a pending task list.
|
|
|
|
|
This function releases and makes ready-to-run all of the tasks that have
|
|
|
|
|
collected in the pending task list. This can cause a
|
|
|
|
|
context switch if a new task is placed at the head of
|
|
|
|
|
the ready to run list.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
This function is called only from the NuttX scheduling logic when
|
|
|
|
|
pre-emption is re-enabled. Interrupts will always be disabled when this
|
|
|
|
|
function is called.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upreprioritizertr">4.1.10 <code>up_reprioritize_rtr()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void up_reprioritize_rtr(FAR _TCB *tcb, ubyte priority);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
Called when the priority of a running or
|
|
|
|
|
ready-to-run task changes and the reprioritization will
|
|
|
|
|
cause a context switch. Two cases:
|
|
|
|
|
</p>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>
|
|
|
|
|
The priority of the currently running task drops and the next
|
|
|
|
|
task in the ready to run list has priority.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
An idle, ready to run task's priority has been raised above the
|
|
|
|
|
the priority of the current, running task and it now has the
|
|
|
|
|
priority.
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
<p>
|
|
|
|
|
This function is called only from the NuttX scheduling
|
|
|
|
|
logic. Interrupts will always be disabled when this
|
|
|
|
|
function is called.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p><b>Inputs:</b></p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>tcb</code>: The TCB of the task that has been reprioritized
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>priority</code>: The new task priority
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h3><a name="_exit">4.1.11 <code>_exit()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void _exit(int status) noreturn_function;</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
This function causes the currently executing task to cease
|
|
|
|
|
to exist. This is a special case of task_delete().
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Unlike other UP APIs, this function may be called
|
|
|
|
|
directly from user programs in various states. The
|
|
|
|
|
implementation of this function should diable interrupts
|
|
|
|
|
before performing scheduling operations.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upassert">4.1.12 <code>up_assert()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>:<br>
|
|
|
|
|
<code>void up_assert(FAR const ubyte *filename, int linenum);</code></br>
|
|
|
|
|
<code>void up_assert_code(FAR const ubyte *filename, int linenum, int error_code);</code></br>
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
Assertions may be handled in an architecture-specific
|
|
|
|
|
way.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upschedulesigaction">4.1.13 <code>up_schedule_sigaction()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>:
|
|
|
|
|
<code>void up_schedule_sigaction(FAR _TCB *tcb, sig_deliver_t sigdeliver);</code>
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
This function is called by the OS when one or more
|
|
|
|
|
signal handling actions have been queued for execution.
|
|
|
|
|
The architecture specific code must configure things so
|
|
|
|
|
that the 'igdeliver' callback is executed on the thread
|
|
|
|
|
specified by 'tcb' as soon as possible.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
This function may be called from interrupt handling logic.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
This operation should not cause the task to be unblocked
|
|
|
|
|
nor should it cause any immediate execution of sigdeliver.
|
|
|
|
|
Typically, a few cases need to be considered:
|
|
|
|
|
</p>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>
|
|
|
|
|
This function may be called from an interrupt handler
|
|
|
|
|
During interrupt processing, all xcptcontext structures
|
|
|
|
|
should be valid for all tasks. That structure should
|
|
|
|
|
be modified to invoke sigdeliver() either on return
|
|
|
|
|
from (this) interrupt or on some subsequent context
|
|
|
|
|
switch to the recipient task.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
If not in an interrupt handler and the tcb is NOT
|
|
|
|
|
the currently executing task, then again just modify
|
|
|
|
|
the saved xcptcontext structure for the recipient
|
|
|
|
|
task so it will invoke sigdeliver when that task is
|
|
|
|
|
later resumed.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
If not in an interrupt handler and the tcb IS the
|
|
|
|
|
currently executing task -- just call the signal
|
|
|
|
|
handler now.
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
<p>
|
|
|
|
|
This API is <i>NOT</i> required if <code>CONFIG_DISABLE_SIGNALS</code>
|
|
|
|
|
is defined.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upallocateheap">4.1.14 <code>up_allocate_heap()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void up_allocate_heap(FAR void **heap_start, size_t *heap_size);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
The heap may be statically allocated by
|
|
|
|
|
defining CONFIG_HEAP_BASE and CONFIG_HEAP_SIZE. If these
|
|
|
|
|
are not defined, then this function will be called to
|
|
|
|
|
dynamically set aside the heap region.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
This API is <i>NOT</i> required if <code>CONFIG_HEAP_BASE</code>
|
|
|
|
|
is defined.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upinterruptcontext">4.1.15 <code>up_interrupt_context()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>boolean up_interrupt_context(void)</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
Return TRUE is we are currently executing in
|
|
|
|
|
the interrupt handler context.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="updisableirq">4.1.16 <code>up_disable_irq()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void up_disable_irq(int irq);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
Disable the IRQ specified by 'irq'
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upenableirq">4.1.17 <code>up_enable_irq()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void up_enable_irq(int irq);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
Enable the IRQ specified by 'irq'
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="upputc">4.1.18 <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>
|
|
|
|
|
This API is <i>NOT</i> required if <code>CONFIG_HEAP_BASE</code>
|
|
|
|
|
is defined.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h2><a name="exports">4.2 APIs Exported by NuttX to Architecture-Specific Logic</a></h2>
|
|
|
|
|
<p>
|
|
|
|
|
These are standard interfaces that are exported by the OS
|
|
|
|
|
for use by the architecture specific logic.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="osstart">4.2.1 <code>os_start()</code></a></h3>
|
|
|
|
|
<p>
|
|
|
|
|
<b><i>To be provided</i></b>
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="listmgmt">4.2.2 OS List Management APIs</a></h3></h3>
|
|
|
|
|
<p>
|
|
|
|
|
<b><i>To be provided</i></b>
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="schedprocesstimer">4.2.3 <code>sched_process_timer()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void sched_process_timer(void);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
This function handles system timer events.
|
|
|
|
|
The timer interrupt logic itself is implemented in the
|
|
|
|
|
architecture specific code, but must call the following OS
|
|
|
|
|
function periodically -- the calling interval must be
|
|
|
|
|
<code>MSEC_PER_TICK</code>.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3><a name="irqdispatch">4.2.4 <code>irq_dispatch()</code></a></h3>
|
|
|
|
|
<p><b>Prototype</b>: <code>void irq_dispatch(int irq, FAR void *context);</code></p>
|
|
|
|
|
|
|
|
|
|
<p><b>Description</b>.
|
|
|
|
|
This function must be called from the achitecture-
|
|
|
|
|
specific logic in order to dispaly an interrupt to
|
|
|
|
|
the appropriate, registered handling logic.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h1><a name="apndxconfigs">Appendix A: NuttX Configuration Settings</a></h1>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The following variables are recognized by the build (you may
|
|
|
|
|
also include architecture-specific settings).
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h2>Architecture selection</h2>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li><code>CONFIG_ARCH</code>: identifies the arch subdirectory
|
|
|
|
|
<li><code>CONFIG_ARCH_name</code>: for use in C code
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h2>General OS setup</h2>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_EXAMPLE</code>: identifies the subdirectory in examples
|
|
|
|
|
that will be used in the build.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_DEBUG</code>: enables built-in debug options
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_DEBUG_VERBOSE</code>: enables verbose debug output
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_HAVE_LOWPUTC</code>: architecture supports low-level, boot
|
|
|
|
|
time console output
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_MM_REGIONS</code>: If the architecture includes multiple
|
|
|
|
|
regions of memory to allocate from, this specifies the
|
|
|
|
|
number of memory regions that the memory manager must
|
|
|
|
|
handle and enables the API mm_addregion(start, end);
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_RR_INTERVAL</code>: The round robin timeslice will be set
|
|
|
|
|
this number of milliseconds; Round robin scheduling can
|
|
|
|
|
be disabled by setting this value to zero.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_SCHED_INSTRUMENTATION</code>: enables instrumentation in
|
|
|
|
|
scheduler to monitor system performance
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_TASK_NAME_SIZE</code>: Spcifies that maximum size of a
|
|
|
|
|
task name to save in the TCB. Useful if scheduler
|
|
|
|
|
instrumentation is selected. Set to zero to disable.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_START_YEAR, CONFIG_START_MONTH, CONFIG_START_DAY -
|
|
|
|
|
Used to initialize the internal time logic.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_JULIAN_TIME</code>: Enables Julian time conversions
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_DEV_CONSOLE</code>: Set if architecture-specific logic
|
|
|
|
|
provides /dev/console. Enables stdout, stderr, stdin.
|
|
|
|
|
</li>
|
|
|
|
|
</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>
|
2007-03-21 17:21:26 +00:00
|
|
|
<code>CONFIG_DISABLE_CLOCK</code>, <code>CONFI_DISABLE_POSIX_TIMERS</code>, <code>CONFIG_DISABLE_PTHREAD</code>,
|
2007-03-19 22:45:58 +00:00
|
|
|
<code>CONFIG_DISABLE_SIGNALS</code>, <code>CONFIG_DISABLE_MQUEUE</code>,
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h2>Miscellaneous libc settings</h2>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_NOPRINTF_FIELDWIDTH</code>: sprintf-related logic is a
|
|
|
|
|
little smaller if we do not support fieldwidthes
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h2>Allow for architecture optimized implementations</h2>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The architecture can provide optimized versions of the
|
|
|
|
|
following to improve sysem performance.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<p>
|
|
|
|
|
<code>CONFIG_ARCH_MEMCPY</code>, <code>CONFIG_ARCH_MEMCMP</code>, <code>CONFIG_ARCH_MEMMOVE</code>,
|
|
|
|
|
<code>CONFIG_ARCH_MEMSET</code>, <code>CONFIG_ARCH_STRCMP</code>, <code>CONFIG_ARCH_STRCPY</code>,
|
|
|
|
|
<code>CONFIG_ARCH_STRNCPY</code>, <code>CONFIG_ARCH_STRLEN</code>, <code>CONFIG_ARCH_BZERO</code>,
|
|
|
|
|
<code>CONFIG_ARCH_KMALLOC</code>, <code>CONFIG_ARCH_KZMALLOC</code>, <code>ONFIG_ARCH_KFREE</code>,
|
|
|
|
|
</p>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h2>Sizes of configurable things (0 disables)</h2>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_MAX_TASKS</code>: The maximum number of simultaneously
|
|
|
|
|
active tasks. This value must be a power of two.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_NPTHREAD_KEYS</code>: The number of items of thread-
|
|
|
|
|
specific data that can be retained
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_NFILE_DESCRIPTORS</code>: The maximum number of file
|
|
|
|
|
descriptors (one for each open)
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_NFILE_STREAMS</code>: The maximum number of streams that
|
|
|
|
|
can be fopen'ed
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_NAME_MAX</code>: The maximum size of a file name.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_STDIO_BUFFER_SIZE</code>: Size of the buffer to allocate
|
|
|
|
|
on fopen. (Only if CONFIG_NFILE_STREAMS > 0)
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_NUNGET_CHARS</code>: Number of characters that can be
|
|
|
|
|
buffered by ungetc() (Only if CONFIG_NFILE_STREAMS > 0)
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_PREALLOC_MQ_MSGS</code>: The number of pre-allocated message
|
|
|
|
|
structures. The system manages a pool of preallocated
|
|
|
|
|
message structures to minimize dynamic allocations
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_MQ_MAXMSGSIZE</code>: Message structures are allocated with
|
|
|
|
|
a fixed payload size given by this settin (does not include
|
|
|
|
|
other message structure overhead.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_PREALLOC_WDOGS</code>: The number of pre-allocated watchdog
|
|
|
|
|
structures. The system manages a pool of preallocated
|
|
|
|
|
watchdog structures to minimize dynamic allocations
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h2>Stack and heap information</h2>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_BOOT_FROM_FLASH</code>: Some configurations support XIP
|
|
|
|
|
operation from FLASH.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_STACK_POINTER</code>: The initial stack pointer
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>CONFIG_PROC_STACK_SIZE</code>: The size of the initial stack
|
|
|
|
|
</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>
|
|
|
|
|
|
2007-02-17 23:21:28 +00:00
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
|
|
|
|
|
|
