Newer
Older
<head>
<title>NuttX Users Manual</title>
<meta name="AUTHOR" content="Gregory Nutt">
</head>
<body background="backgd.gif">
<hr>
<hr>
<center><h1><i>Under Construction</i></h1></center>
<hr>
<hr>
NuttX Operating System
<h1>1.0 <A NAME="Introduction">Introduction</a></h1>
<p>
This manual provides general usage information for the NuttX RTOS from the
perspective of the firmware developer.
<h2>1.1 <a name="overview">Document Overview</a></h2>
<p>
This user's manual is divided into three sections plus a index:
</p>
<ul>
<li>
<b>Section 1.0, <a href="#Introduction">Introduction</a></b>:
This section provides an overview of the NuttX user's manual.
</li>
<li>
<b>Section 2.0, <a href="#OS_Interfaces">OS Interfaces</a></b>:
This section details the program interfaces provided by NuttX.
This section is divided into several paragraphs that describe different groups of OS interfaces:
<ul>
<li>Paragraph 2.1 <a href="#Task_Control">Task Control Interfaces</a></li>
<li>Paragraph 2.2 <a href="#Task_Schedule">Task Scheduling Interfaces</a></li>
<li>Paragraph 2.3 <a href="#Task_Switch">Task Switching Interfaces</a></li>
<li>Paragraph 2.4 <a href="#Message_Queue">Named Message Queue Interfaces</a></li>
<li>Paragraph 2.5 <a href="#Semaphores">Counting Semaphore Interfaces</a></li>
<li>Paragraph 2.6 <a href="#Watchdogs">Watchdog Timer Interfaces</a></li>
<li>Paragraph 2.7 <a href="#ClocksNTimers">Clocks and Timers</a></li>
<li>Paragraph 2.8 <a href="#Signals">Signal Interfaces</a></li>
<li>Paragraph 2.9 <a href="#Pthread">Pthread Interfaces</a></li>
<li>Paragraph 2.10 <a href="#Environ">Environment Variables</a></li>
<li>Paragraph 2.11 <a href="#FileSystem">Filesystem Interfaces</a></li>
<li>Paragraph 2.12 <a href="#Network">Network Interfaces</a></li>
</ul>
</li>
<li>
<b>Section 3.0, <a href="#Data_Structures">OS Data Structures</a></b>:
This section documents the data structures that are used at the NuttX
interface.
</li>
<li>
<a href="#index">Index</a>
</li>
</ul>
<h2>1.2 <a name="scope">Intended Audience and Scope</a></h2>
<p>
The intended audience for this document are firmware developers who are implementing applications on NuttX.
Specifically, this documented is limited to addressing only NuttX RTOS APIs that are available to the application developer.
As such, this document does not focus on any technical details of the organization or implementation of NuttX.
Those technical details are provided in the <a href="NuttxPortingGuide.html">NuttX Porting Guide</a>.
</p>
<p>
Information about configuring and building NuttX is also needed by the application developer.
That information can also be found in the <a href="NuttxPortingGuide.html#configandbuild">NuttX Porting Guide</a>.
</p>
<hr>
<h1>2.0 <A NAME="OS_Interfaces">OS Interfaces</a></h1>
<p>
This section describes each C-callable interface to the NuttX
Operating System. The description of each interface is presented
in the following format:
<p>
<b>Function Prototype:</b> The C prototype of the interface function
<p>
<b>Description:</b> The operation performed by the interface function
<p>
<b>Input Parameters:</b> All input parameters are listed along
<p>
<b>Returned Values:</b> All possible values returned by the interface
function are listed. Values returned as side-effects (through
pointer input parameters or through global variables) will be
addressed in the description of the interface function.
<p>
<b>Assumptions/Limitations:</b> Any unusual assumptions made by
the interface function or any non-obvious limitations to the use
of the interface function will be indicated here.
<p>
<b>POSIX Compatibility:</b> Any significant differences between the
NuttX interface and its corresponding POSIX interface will be noted
NOTE: In order to achieve an independent name space for the NuttX
interface functions, differences in function names and types are
to be expected and will not be identified as differences in these
paragraphs.
NuttX is a flat address OS. As such it does not support <i>processes</i>
in the way that, say, Linux does.
NuttX only supports simple threads running within the same address space.
However, the programming model makes a distinction between <i>tasks</i>
and <i>pthreads</i>:
<li><i>tasks</i> are threads which have a degree of independence
<li><a href="#Pthread"><i>pthreads</i></a> share some resources.
<b>File Descriptors and Streams</b>.
This applies, in particular, in the area of opened file descriptors and streams.
When a task is started using the interfaces in this section, it will be created
with at most three open files.
</p>
</p>
If CONFIG_DEV_CONSOLE is defined, the first three file descriptors (corresponding
to stdin, stdout, stderr) will be duplicated for the the new task.
Since these file descriptors are duplicated, the child task can free close
them or manipulate them in any way without effecting the parent task.
File-related operations (open, close, etc.) within a task will have no effect
on other tasks.
Since the three file descriptors are duplicated, it is also possible to perform
some level of redirection.
</p>
<p>
pthreads, on the other hand, will always share file descriptors with the parent
thread. In this case, file operations will have effect only all pthreads the
were started from the same parent thread.
</p>
The following task control interfaces are provided by Nuttx:
</p>
<ul>
<li><a href="#taskcreate">2.1.1 task_create</a></li>
<li><a href="#taskinit">2.1.2 task_init</a></li>
<li><a href="#taskactivate">2.1.3 task_activate</a></li>
<li><a href="#taskdelete">2.1.4 task_delete</a></li>
<li><a href="#exit">2.1.5 exit</a></li>
<li><a href="#taskrestart">2.1.6 task_restart</a></li>
<li><a href="#getpid">2.1.7 getpid</a></li>
</ul>
int task_create(char *name, int priority, int stack_size, main_t entry, const char *argv[]);
This function creates and activates a new task with a
specified priority and returns its system-assigned ID.
</p>
function of the task.
This function will be called once the C environment has been set up.
The specified function will be called with four arguments.
Should the specified routine return, a call to exit() will automatically be made.
</P>
<p>
Note that an arbitrary number of arguments may be passed to the
spawned functions. The maximum umber of arguments is an OS
configuration parameter (<code>CONFIG_MAX_TASK_ARGS</code>).
</p>
<p>
The arguments are copied (via <code>strdup</code>) so that the
life of the passed strings is not dependent on the life of the
caller to <code>task_create()</code>.
</p>
<p>
The newly created task does not inherit scheduler characteristics
from the parent task: The new task is started at the
default system priority and with the SCHED_FIFO scheduling
policy. These characteristcs may be modified after the new
task has been started.
</p>
<p>
The newly created task does inherit the first three file
descriptors (corresponding to stdin, stdout, and stderr) and
redirection of standard I/O is supported.
</p>
<p>
<b>Input Parameters:</b>
<ul>
<li><I>name</I>. Name of the new task</LI>
<li><I>priority</I>. Priority of the new task</LI>
<li><I>stack_size</I>. size (in bytes) of the stack needed</LI>
<li><I>entry</I>. Entry point of a new task</LI>
<li><I>argv</I>. A pointer to an array of input parameters. Up to
<code>CONFIG_MAX_TASK_ARG</code> parameters may be provided.
If fewer than <code>CONFIG_MAX_TASK_ARG</code> parameters are
passed, the list should be terminated with a NULL argv[] value.
If no parameters are required, argv may be NULL.
Returns the non-zero task ID of the new task or
ERROR if memory is insufficient or the task cannot be
created (errno is not set).
</LI>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b>POSIX Compatibility:</b> This is a NON-POSIX interface.
int taskSpawn(char *name, int priority, int options, int stackSize, FUNCPTR entryPt,
int arg1, int arg2, int arg3, int arg4, int arg5,
int arg6, int arg7, int arg8, int arg9, int arg10);
The NuttX task_create() differs from VxWorks' taskSpawn() in the
following ways:
</p>
<ul>
<li>Interface name
<li>Various differences in types of arguments
<li>There is no options arguement.
<li>A variable number of parameters can be passed to a task (VxWorks supports ten).
</ul>
STATUS task_init(_TCB *tcb, char *name, int priority, uint32 *stack, uint32 stack_size,
maint_t entry, const char *argv[]);
in preparation for starting a new thread. It performs a subset
of the functionality of <code>task_create()</code> (see above).
Unlike task_create(), task_init() does not activate the task.
This must be done by calling task_activate().
</P>
<p>
<b>Input Parameters:</b>
<ul>
<li><I>tcb</I>. Address of the new task's TCB
<li><I>name</I>. Name of the new task (not used)
<li><I>priority</I>. Priority of the new task
<li><I>stack</I>. Start of the pre-allocated stack
<li><I>stack_size</I>. size (in bytes) of the pre-allocated stack
<li><I>entry</I>. Entry point of a new task
<li><I>argv</I>. A pointer to an array of input parameters. Up to
<code>CONFIG_MAX_TASK_ARG</code> parameters may be provided.
If fewer than <code>CONFIG_MAX_TASK_ARG</code> parameters are
passed, the list should be terminated with a NULL argv[] value.
If no parameters are required, argv may be NULL.
<ul>
<li><p>OK, or ERROR if the task cannot be initialized.</P>
<p>This function can only failure is it is unable to assign
</ul>
<p>
<b>Assumptions/Limitations:</b>
<ul>
<li>task_init() is provided to support internal OS functionality. It is
<b>not recommended</b> for normal usage. task_create() is the preferred
</ul>
<p>
<b>POSIX Compatibility:</b> This is a NON-POSIX interface.
STATUS taskInit(WIND_TCB *pTcb, char *name, int priority, int options, uint32 *pStackBase, int stackSize,
FUNCPTR entryPt, int arg1, int arg2, int arg3, int arg4, int arg5,
int arg6, int arg7, int arg8, int arg9, int arg10);
The NuttX task_init() differs from VxWorks' taskInit() in the
following ways:
</p>
<ul>
<li>Interface name
<li>Various differences in types or arguments
<li>There is no options argument.
<li>A variable number of parameters can be passed to a task (VxWorks supports ten).
</ul>
<p>
<b>Description:</b> This function activates tasks created by task_init().
Without activation, a task is ineligible for execution by the
scheduler.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>tcb</I>. The TCB for the task for the task (same as the
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>OK, or ERROR if the task cannot be activated (errno is not set).
</ul>
<p>
<b>Assumptions/Limitations:</b>
<ul>
<li>task_activate() is provided to support internal OS functionality. It is
<b>not recommended</b> for normal usage. task_create() is the preferred
</ul>
<p>
<b>POSIX Compatibility:</b> This is a NON-POSIX interface.
The NuttX task_activate() differs from VxWorks' taskActivate() in the
following ways:
</p>
<ul>
<li>Function name
<li>With VxWork's taskActivate, the pid argument is supposed to be
<p>
<b>Description:</b> This function causes a specified task to cease
to exist -- its stack and TCB will be deallocated. This function
is the companion to task_create().
<p>
<b>Input Parameters:</b>
<ul>
<li><I>pid</I>. The task ID of the task to delete. An ID of
<p>
<b>Returned Values:</b>
<ul>
<li>OK, or ERROR if the task cannot be deleted.
This function can fail if the provided pid does not correspond to a task (errno is not set)
task_delete() must be used with caution: If the task holds resources
(for example, allocated memory or semaphores needed by other tasks), then
task_delete() can strand those resources.
The NuttX task_delete() differs from VxWorks' taskDelete() in
the following ways:
</p>
<ul>
<li>No support is provided for calling the tasks deletion routines
#include <sched.h>
void exit( int code );
#include <nuttx/unistd.h>
void _exit( int code );
<p>
<b>Description:</b> This function causes the calling task to cease
to exist -- its stack and TCB will be deallocated. exit differs from
_exit in that it flushs streams, closes file descriptors and will
execute any function registered with atexit().
<p>
<b>Input Parameters:</b>
<ul>
<li><I>code</I>. (ignored)
</ul>
<p>
<b>POSIX Compatibility:</b> This is equivalent to the ANSI interface:
The NuttX exit() differs from ANSI exit() in the following ways:
</p>
<p>
<b>Description:</b> This function "restarts" a task.
The task is first terminated and then reinitialized with same
ID, priority, original entry point, stack size, and parameters
it had when it was first started.
<p>
<b>Input Parameters:</b>
<ul>
<li><I>pid</I>. The task ID of the task to delete. An ID of
OK, or ERROR if the task ID is invalid or the task could
not be restarted.
This function can fail if:
(1) A pid of zero or the pid of the calling task is provided (functionality not implemented)
(2) The pid is not associated with any task known to the system.
</LI>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b>POSIX Compatibility:</b> This is a NON-POSIX interface.
The NuttX task_restart() differs from VxWorks' taskRestart() in the following ways:
</p>
<ul>
<li>Restart of the currently running task is not supported.
<li>The VxWorks description says that the ID, priority, etc. take
<p>
<b>Description:</b> This function returns the task ID of the
calling task. The task ID will be invalid if called at the interrupt
level.
<p>
<b>Input Parameters:</b> None.
<p>
<b>Returned Values:</b>
<ul>
<li>The task ID of the calling task.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b>POSIX Compatibility:</b>
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
<p>
By default, NuttX performs strict priority scheduling: Tasks of higher
priority have exclusive access to the CPU until they become blocked.
At that time, the CPU is available to tasks of lower priority.
Tasks of equal priority are scheduled FIFO.
</p>
<p>
Optionally, a Nuttx task or thread can be configured with round-robin
scheduler. This is similar to priority scheduling <i>except</i> that
tasks with equal priority and share CPU time via <i>time-slicing</i>.
The time-slice interval is a constant determined by the configuration
setting <code>CONFIG_RR_INTERVAL</code>.
</p>
<p>
The OS interfaces described in the following paragraphs provide
a POSIX- compliant interface to the NuttX scheduler:
</p>
<ul>
<li><a href="#schedsetparam">2.2.1 sched_setparam</a></li>
<li><a href="#schedgetparam">2.2.2 sched_getparam</a></li>
<li><a href="#schedsetscheduler">2.2.3 sched_setscheduler</a></li>
<li><a href="#setgetscheduler">2.2.4 sched_getscheduler</a></li>
<li><a href="#sched_yield">2.2.5 sched_yield</a></li>
<li><a href="#schedgetprioritymax">2.2.6 sched_get_priority_max</a></li>
<li><a href="#schedgetprioritymin">2.2.7 sched_get_priority_min</a></li>
<li><a href="#schedgetrrinterval">2.2.8 sched_get_rr_interval</a></li>
</ul>
int sched_setparam(pid_t pid, const struct sched_param *param);
</pre>
<p>
This function sets the priority of the task specified by pid input parameter.
</p>
<p>
NOTE: Setting a task's priority to the same value has the similar
effect to <code>sched_yield()</code>: The task will be moved to after all
other tasks with the same priority.
</p>
<p>
<b>Input Parameters:</b>
</p>
<ul>
<li>
<code>pid</code>.
The task ID of the task.
If <code>pid</code> is zero, the priority of the calling task is set.
</li>
<li>
<code>param</code>.
A structure whose member <code>sched_priority</code> is the integer priority.
The range of valid priority numbers is from <code>SCHED_PRIORITY_MIN</code> through <code>SCHED_PRIORITY_MAX</code>.
</li>
</ul>
<p>
<b>Returned Values:</b>
On success, sched_setparam() returns 0 (OK).
On error, -1 (ERROR) is returned, and<code>errno</code>is set appropriately.
<li>
<code>EINVAL</code>.
The parameter <code>param</code> is invalid or does not make sense for the current scheduling policy.
</li>
<li>
<code>EPERM</code>.
The calling task does not have appropriate privileges.
</li>
<li>
<code>ESRCH</code>.
The task whose ID is <code>pid</code> could not be found.
</li>
</ul>
<p>
<b>Assumptions/Limitations:</b>
</p>
<p>
Comparable to the POSIX interface of the same name.
Differences from the full POSIX implementation include:
</p>
<ul>
<li>The range of priority values for the POSIX call is 0 to 255.</li>
</ul>
#include <sched.h>
int sched_getparam (pid_t pid, struct sched_param *param);
<p>
<b>Description:</b> This function gets the scheduling priority
<p>
<b>Input Parameters:</b>
<ul>
<li>
<code>pid</code>. The task ID of the task.
If pid is zero, the priority of the calling task is returned.
</li>
<li>
<code>param</code>.
A structure whose member <code>sched_priority</code> is the integer priority.
The task's priority is copied to the <code>sched_priority</code> element of this structure.
</li>
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK) if successful, otherwise -1 (ERROR).
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<H3><a name="schedsetscheduler">2.2.3 sched_setscheduler</a></H3>
#include <sched.h>
int sched_setscheduler (pid_t pid, int policy, const struct sched_param *param);
<i>sched_setscheduler()</i> sets both the scheduling policy
and the priority for the task identified by pid.
If pid equals zero, the scheduler of the calling
thread will be set.
The parameter 'param' holds the priority of the thread under the new policy.
</p>
<p>
<b>Input Parameters:</b>
<ul>
<li>
<I>pid</I>. The task ID of the task. If pid is zero, the
</li>
<li>
<I>policy</I>. Scheduling policy requested (either SCHED_FIFO or SCHED_RR).
</li>
<li>
<code>param<code>. A structure whose member sched_priority is the
integer priority. The range of valid priority numbers is from
SCHED_PRIORITY_MIN through SCHED_PRIORITY_MAX.
error, ERROR (-1) is returned, and<code>errno</code>is set appropriately:
</p>
<ul>
<li>EINVAL The scheduling policy is not one of the
recognized policies.</li>
<li>ESRCH The task whose ID is pid could not be found.</li>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
pid equals zero, the policy of the calling process will
be retrieved.
*
* Inputs:
*
* Return Value:
This function returns the current scheduling
policy.
The task ID of the task to query.
If pid is zero, the calling task is queried.
</LI>
On success, <i>sched_getscheduler()</i> returns the policy for
the task (either SCHED_FIFO or SCHED_RR).
On error, ERROR (-1) is returned, and<code>errno</code>is set appropriately:
<ul>
<li>ESRCH The task whose ID is pid could not be found.</li>
</ul>
</li>
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
interface of the same name.
Differences from the full POSIX implementation include:
<p>
<b>Description:</b> This function forces the calling task to give
<p>
<b>Input Parameters:</b> None.
<p>
<b>Returned Values:</b>
<ul>
<li>0 (OK) or -1 (ERROR)
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<H3><a name="schedgetprioritymax">2.2.6 sched_get_priority_max</a></H3>
#include <sched.h>
int sched_get_priority_max (int policy)
<p>
<b>Description:</b> This function returns the value of the highest
<p>
<b>Input Parameters:</b>
<ul>
<li><I>policy</I>. Scheduling policy requested.
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>The maximum priority value or -1 (ERROR).
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<H3><a name="schedgetprioritymin">2.2.7 sched_get_priority_min</a></H3>
#include <sched.h>
int sched_get_priority_min (int policy);
<p>
<b>Description:</b> This function returns the value of the lowest
<p>
<b>Input Parameters:</b>
<ul>
<li><I>policy</I>. Scheduling policy requested.
</ul>
<p>
<b>Returned Values:</b>
<ul>
<li>The minimum priority value or -1 (ERROR)
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX
<H3><a name="schedgetrrinterval">2.2.8 sched_get_rr_interval</a></H3>
#include <sched.h>
int sched_get_rr_interval (pid_t pid, struct timespec *interval);
<i>sched_rr_get_interval()</i> writes the timeslice interval
for task identified by <i>pid</i> into the timespec structure
pointed to by <i>interval</i>. If pid is zero, the timeslice
for the calling process is written into 'interval. The
identified process should be running under the SCHED_RR
scheduling policy.'
</p>
<ul>
<li><I>pid</I>. The task ID of the task. If pid is zero, the
<li><I>interval</I>. A structure used to return the time slice.
</ul>
error, ERROR (-1) is returned, and<code>errno</code>is set to:
<ul>
<li>EFAULT Cannot copy to interval</LI>
<li>EINVAL Invalid pid.</LI>
<li>ENOSYS The system call is not yet implemented.</LI>
<li>ESRCH The process whose ID is pid could not be found.</LI>
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b>POSIX Compatibility:</b> Comparable to the POSIX
<ul>
<li><a href="#schedlock">2.3.1 sched_lock</a></li>
<li><a href="#schedunlock">2.3.2 sched_unlock</a></li>
<li><a href="#schedlockcount">2.3.3 sched_lockcount</a></li>
</ul>
<H3><a name="schedlock">2.3.1 sched_lock</a></H3>
<p>
<b>Description:</b> This function disables context switching by
Disabling addition of new tasks to the ready-to-run task list.
The task that calls this function will be the only task that is
allowed to run until it either calls sched_unlock (the appropriate
number of times) or until it blocks itself.
<p>
<b>Input Parameters:</b> None.
<p>
<b>Returned Values:</b>
<ul>
<li>OK or ERROR.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> This is a NON-POSIX interface.
<p>
<b>Description:</b> This function decrements the preemption lock
count. Typically this is paired with sched_lock() and concludes
a critical section of code. Preemption will not be unlocked until
sched_unlock() has been called as many times as sched_lock().
When the lockCount is decremented to zero, any tasks that were
eligible to preempt the current task will execute.
<p>
<b>Input Parameters:</b> None.
<p>
<b>Returned Values:</b>
<ul>
<li>OK or ERROR.
</ul>
<p>
<b>Assumptions/Limitations:</b>
<p>
<b> POSIX Compatibility:</b> This is a NON-POSIX interface.
<p>
<b>Description:</b> This function returns the current value of
the lockCount. If zero, preemption is enabled; if non-zero, this
value indicates the number of times that sched_lock() has been called
on this thread of execution.