NuttxUserGuide.html

<HTML>

<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>
<CENTER><BIG><B>
NuttX Operating System
<P>
User's Manual
</B></BIG>
<P>
<SMALL>by</SMALL>
<P>
Gregory Nutt
<P>
<SMALL>Last Update: March 21, 2007</SMALL>
</CENTER>

<H1>1.0 <A NAME="Introduction">Introduction</A></H1>

<P>
This user's manual is divided into three sections plus a index:
<UL>
<LI><B>Section 1.0, <A HREF="#Introduction">Introduction</A></B>:
This section provides an overview of the NuttX user's manual.
<LI><B>Section 2.0, <A HREF="#OS_Interfaces">OS Interfaces</A></B>:
This section details the  interfaces provided by NuttX from the
perspective of the firmware developer.  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>Paragraph 2.2 <A HREF="#Task_Schedule">Task Scheduling Interfaces</A>
<LI>Paragraph 2.3 <A HREF="#Task_Switch">Task Switching Interfaces</A>
<LI>Paragraph 2.4 <A HREF="#Message_Queue">Named Message Queue Interfaces</A>
<LI>Paragraph 2.5 <A HREF="#Semaphores">Counting Semaphore Interfaces</A>
<LI>Paragraph 2.6 <A HREF="#Watchdogs">Watchdog Timer Interfaces</A>
<LI>Paragraph 2.7 <A HREF="#ClocksNTimers">Clocks and Timers</A>
<LI>Paragraph 2.8 <A HREF="#Signals">Signal Interfaces</A>
<LI>Paragraph 2.9 <A HREF="#Pthread">Pthread Interfaces</A>
<LI>Paragraph 2.10 <A HREF="#FileSystem">Filesystem Interfaces</A>
</UL>
<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><a href="#index">Index</a></li>
</ul>
<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
is provided.
<P>
<B>Description:</B> The operation performed by the interface function
is discussed.
<P>
<B>Input Parameters:</B> All input parameters are listed along
with brief descriptions of each input parameter.
<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
here.
<P>
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.
<HR>

<H2>2.1 <A NAME="Task_Control">Task Control Interfaces</A></H2>

<p>
  <b>Tasks</b>.
  NuttX is a flat address OS.  As such it does not support &quot;processes&quot;
  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 &quot;tasks&quot;
  and pthreads:
</p>
<ul>
  <li><i>tasks</i> are threads which have a degree of independence
  <li><a href="#Pthread"><i>pthreads</i></a> share some resources.
</ul>
<p>
  <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>
<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>

<H3><a name="taskcreate">2.1.1 task_create</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
   #include &lt;sched.h&gt;
   int task_create(char *name, int priority, int stack_size, main_t entry, const char *argv[]);
</PRE>

<P>
<B>Description:</B> 
   This function creates and activates a new task with a
   specified priority and returns its system-assigned ID.
</p>

<P>The entry address entry is the address of the &quot;main&quot;
   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.
  </UL>
<P>
  <B>Returned Values:</B> 
</P>
<UL>
<LI>
  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>
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>POSIX Compatibility:</B> This is a NON-POSIX interface.
VxWorks provides the following similar interface:
<PRE>
   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);
</PRE>

<P>
  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>

<H3><a name="taskinit">2.1.2 task_init</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
   #include &lt;sched.h&gt;
   STATUS task_init(_TCB *tcb, char *name, int priority, uint32 *stack, uint32 stack_size,
                    maint_t entry, const char *argv[]);
</PRE>

<P>
<B>Description:</B>
<P>
  This function initializes a Task Control Block (TCB)
  in preparation for starting a new thread.  It performs a subset
  of the functionality of <code>task_create()</code> (see above).
</P>
<P>
  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>
</p>
<P>
<B>Returned Values:</B> 
</p>
<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
    a new, unique task ID to the TCB (errno is not set).</P>
</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
mechanism to initialize and start a new task.
</UL>
<P>
<B>POSIX Compatibility:</B> This is a NON-POSIX interface.
VxWorks provides the following similar interface:
<PRE>
   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);
</PRE>

<P>
  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>

<H3><a name="taskactivate">2.1.3 task_activate</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    STATUS task_activate( _TCB *tcb );
</PRE>

<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
task_init argument).
</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
mechanism to initialize and start a new task.
</UL>
<P>
<B>POSIX Compatibility:</B> This is a NON-POSIX interface.
VxWorks provides the following similar interface:
<PRE>
    STATUS taskActivate( int tid );
</PRE>

<P>
  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
the pointer to the WIND_TCB cast to an integer.
</UL>

<H3><a name="taskdelete">2.1.4 task_delete</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    STATUS task_delete( pid_t pid );
</PRE>

<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
zero signifies the calling task.
</UL>

<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)
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
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.
<P>
<B>POSIX Compatibility:</B> This is a NON-POSIX interface.
VxWorks provides the following similar interface:
<PRE>
    STATUS taskDelete( int tid );
</PRE>

<P>
  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
(because taskDeleteHookAdd() is not supported).
<LI>Deletion of self is not supported.  Use _exit();
</UL>

<H3><a name="exit">2.1.5 exit</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    void exit( int code );

    #include &lt;nuttx/unistd.h&gt;
    void _exit( int code );
</PRE>

<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>Returned Values:</B>  None.

<P>
<B>Assumptions/Limitations:</B> 

<P>
<B>POSIX Compatibility:</B> This is equivalent to the ANSI interface:
<PRE>
    void exit( int code );
</PRE>
And the unix interface:
<PRE>
    void _exit( int code );
</PRE>

<P>
  The NuttX exit() differs from ANSI exit() in the following ways:
</p>
<UL>
<LI>The <I>code</I> parameter is ignored.
</UL>

<H3><a name="taskrestart">2.1.6 task_restart</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    STATUS task_restart( pid_t pid );
</PRE>

<P>
<B>Description:</B> This function &quot;restarts&quot; 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
zero signifies the calling task.
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>
  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>
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>POSIX Compatibility:</B> This is a NON-POSIX interface.
VxWorks provides the following similar interface:
<PRE>
    STATUS taskRestart (int tid);
</PRE>

<P>
  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
the value that they had when the task was <I>terminated</I>.
</UL>

<H3><a name="getpid">2.1.7 getpid</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;unistd.h&gt;
    pid_t getpid( void );
</PRE>

<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>
Compatible with the POSIX interface of the same name.

<H2>2.2 <A NAME="Task_Schedule">Task Scheduling Interfaces</A></H2>

<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>

<H3><a name="schedsetparam">2.2.1 sched_setparam</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    int sched_setparam( pid_t pid, const struct sched_param *param );
</PRE>

<P>
<B>Description:</B> This function sets the priority of the task
specified by pid input parameter.
<P>
NOTE: Setting a task's priority to the same value has the similar
effect to sched_yield() -- The task will be moved to after all
other tasks with the same priority.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>pid</I>. The task ID of the task. If pid is zero, the
priority of the calling task is set.
<li><code>param<code>.</li> 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.
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>
  0 (OK) if successful, otherwise -1 (ERROR).
  This function can fail for the following reasons:
  (1) parm is NULL or parm->sched_priority is out of range.
  (2) pid does not correspond to any task.
</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:
<UL>
<LI>The range of priority values for the POSIX call is 0 to 255
</UL>

<H3><a name="schedgetparam">2.2.2 sched_getparam</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    int sched_getparam (pid_t pid, struct sched_param *param);
</PRE>

<P>
<B>Description:</B> This function gets the scheduling priority
of the task specified by pid.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>pid</I>. The task ID of the task. If pid is zero, the
priority of the calling task is returned.
<li><code>param<code>.</li> A structure whose member sched_priority is the
integer priority. The task's priority is copied to the sched_priority
element of this structure.
</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
interface of the same name.

<H3><a name="schedsetscheduler">2.2.3 sched_setscheduler</a></H3>
<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    int sched_setscheduler (pid_t pid, int policy, const struct sched_param *param);
</PRE>
<P>
  <B>Description:</B>
  <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
    priority of the calling task is set.
  <LI><I>policy</I>. Scheduling policy requested (either SCHED_FIFO
    or SCHED_RR).
  <li><code>param<code>.</li> 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.
</UL>
<P>
  <B>Returned Values:</B> 
  On success, <i>sched_setscheduler()</i> returns OK (zero).  On
  error, ERROR (-1) is returned, and errno 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>
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.

<H3><a name="setgetscheduler">2.2.4 sched_getscheduler</a></H3>
<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    int sched_getscheduler (pid_t pid);
</PRE>
<P>
  <B>Description:</B>
  <i>sched_getscheduler()</i> returns the scheduling policy
  currently applied to the task identified by pid. If
  pid equals zero, the policy of the calling process will
  be retrieved.
 *
 * Inputs:
 *
 * Return Value:

 This function returns the current scheduling
policy.
<P>
<B>Input Parameters:</B> 
<UL>
  <LI><I>pid</I>.
    The task ID of the task to query.
    If pid is zero, the calling task is queried.
  </LI>
</UL>
<P>
<B>Returned Values:</B> 
<UL>
  <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 errno 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:
<UL>
<LI>Does not report errors via <I>errno</I>.
</UL>

<H3><a name="sched_yield">2.2.5 sched_yield</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    int sched_yield( void );
</PRE>

<P>
<B>Description:</B> This function forces the calling task to give
up the CPU (only to other tasks at the same priority).
<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
interface of the same name.

<H3><a name="schedgetprioritymax">2.2.6 sched_get_priority_max</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    int sched_get_priority_max (int policy)
</PRE>

<P>
<B>Description:</B> This function returns the value of the highest
possible task priority for a specified scheduling policy.
<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
interface of the same name.

<H3><a name="schedgetprioritymin">2.2.7 sched_get_priority_min</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    int sched_get_priority_min (int policy);
</PRE>

<P>
<B>Description:</B> This function returns the value of the lowest
possible task priority for a specified scheduling policy.
<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
interface of the same name.

<H3><a name="schedgetrrinterval">2.2.8 sched_get_rr_interval</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    int sched_get_rr_interval (pid_t pid, struct timespec *interval);
</PRE>

<P>
  <B>Description:</B> 
  <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>
<P>
  <B>Input Parameters:</B> 
</p>
<UL>
<LI><I>pid</I>. The task ID of the task. If pid is zero, the
priority of the calling task is returned.
<LI><I>interval</I>. A structure used to return the time slice.
</UL>

<P>
  <B>Returned Values:</B> 
  On success, sched_rr_get_interval() returns OK (0).  On
  error, ERROR (-1) is returned, and errno is set to:
</p>
<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
  interface of the same name.
</P>

<H2>2.3 <A NAME="Task_Switch">Task Switching Interfaces</A></H2>

<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>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    STATUS sched_lock( void );
</PRE>

<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.
VxWorks provides the comparable interface:
<PRE>
    STATUS taskLock( void );
</PRE>

<H3><a name="schedunlock">2.3.2 sched_unlock</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    STATUS sched_unlock( void );
</PRE>

<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.
VxWorks provides the comparable interface:
<PRE>
    STATUS taskUnlock( void );
</PRE>

<H3><a name="schedlockcount">2.3.3 sched_lockcount</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;sched.h&gt;
    sint32 sched_lockcount( void )
</PRE>

<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.
<P>
<B>Input Parameters:</B> None.
<P>
<B>Returned Values:</B> 
<UL>
<LI>The current value of the lockCount.
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>  POSIX  Compatibility:</B> None.
<HR>

<H2>2.4 <A NAME="Message_Queue">Named Message Queue Interfaces</A></H2>

<p>
  NuttX supports POSIX named message queues for intertask communication.
  Any task may send or receive messages on named message queues.
  Interrupt handlers may send messages via named message queues.
</p>
<ul>
  <li><a href="#mqopen">2.4.1 mq_open</a></li>
  <li><a href="#mqclose">2.4.2 mq_close</a></li>
  <li><a href="#mqunlink">2.4.3 mq_unlink</a></li>
  <li><a href="#mqsend">2.4.4 mq_send</a></li>
  <li><a href="#mqreceive">2.4.5 mq_receive</a></li>
  <li><a href="#mqnotify">2.4.6 mq_notify</a></li>
  <li><a href="#mqsetattr">2.4.7 mq_setattr</a></li>
  <li><a href="#mqgetattr">2.4.8 mq_getattr</a></li>
</ul>

<H3><a name="mqopen">2.4.1 mq_open</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;mqueue.h&gt;
    mqd_t mq_open( const char *mqName, int oflags, ... );
</PRE>

<P>
<B>Description:</B> This function establish a connection between
a named message queue and the calling task. After a successful
call of mq_open(), the task can reference the message queue using
the address returned by the call. The message queue remains usable
until it is closed by a successful call to mq_close().
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>mqName</I>. Name of the queue to open
<LI><I>oflags</I>. Open flags. These may be any combination of:
<UL>
<LI><I>O_RDONLY</I>. Open for read access.
<LI><I>O_WRONLY</I>. Open for write access.
<LI><I>O_RDWR</I>. Open for both read &amp; write access.
<LI><I>O_CREAT</I>. Create message queue if it does not already
exist.
<LI><I>O_EXCL</I>. Name must not exist when opened.
<LI><I>O_NONBLOCK</I>. Don't wait for data.
</UL>

<LI><I>... Optional parameters</I>.
When the O_CREAT flag is specified, POSIX requires that a third
and fourth parameter be supplied:
<UL>
<LI><I>mode</I>.  The mode parameter is of type mode_t.  In the POSIX
specification, this mode value provides file permission bits for the
message queue.  This parameter is required but not used in the present
implementation.
<LI><I>attr</I>.  A pointer to an mq_attr that is provided to initialize.
the message queue.  If attr is NULL, then the messages queue is created
with implementation-defined default message queue attributes.  If attr is
non-NULL, then the message queue mq_maxmsg attribute is set to the
corresponding value when the queue is created.  The mq_maxmsg attribute
determines the maximum number of messages that can be queued before
addition attempts to send messages on the message queue fail or cause the
sender to block; the mq_msgsize attribute determines the maximum size of a
message that can be sent or received.  Other elements of attr are ignored
(i.e, set to default message queue attributes).
</UL>
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>A message queue descriptor or -1 (ERROR)
</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:
<UL>
<LI>The mq_msgsize attributes determines the maximum size of a message that
may be sent or received.  In the present implementation, this maximum
message size is limited at 22 bytes.
</UL>

<H3><a name="mqclose">2.4.2 mq_close</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;mqueue.h&gt;
    int mq_close( mqd_t mqdes );
</PRE>

<P>
<B>Description:</B> This function is used to indicate that the
calling task is finished with the specified message queued mqdes.
The mq_close() deallocates any system resources allocated by the
system for use by this task for its message queue.
<P>
If the calling task has attached a notification request to the message
queue via this <I>mqdes</I> (see mq_notify()), this attachment will be
removed and the message queue is available for another task to attach
for notification.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>mqdes</I>. Message queue descriptor.
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK) if the message queue is closed successfully, otherwise,
-1 (ERROR).
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<UL>
<LI>The behavior of a task that is blocked on either a mq_send() or
mq_receive() is undefined when mq_close() is called.
<LI>The result of using this message queue descriptor after successful
return from mq_close() is undefined.
</UL>
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX interface
of the same name.

<H3><a name="mqunlink">2.4.3 mq_unlink</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;mqueue.h&gt;
    int mq_unlink( const char *mqName );
</PRE>

<P>
<B>Description:</B> This function removes the message queue named
by &quot;mqName.&quot; If one or more tasks have the message queue
open when mq_unlink() is called, removal of the message queue
is postponed until all references to the message queue have been
closed.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>mqName</I>. Name of the message queue
</UL>

<P>
<B>Returned Values:</B> None.
<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.

<H3><a name="mqsend">2.4.4 mq_send</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;mqueue.h&gt;
    int mq_send( mqd_t mqdes, const void *msg, size_t msgLen, int msgPrio );
</PRE>

<P>
<B>Description:</B> This function adds the specified message (msg)
to the message queue (mqdes). The &quot;msgLen&quot; parameter
specifies the length of the message in bytes pointed to by &quot;msg.&quot;
This length must not exceed the maximum message length from the
mq_getattr().
<P>
If the message queue is not full, mq_send() will in the message
in the message queue at the position indicated by the &quot;msgPrio&quot;
argument. Messages with higher priority will be inserted before
lower priority messages. The value of &quot;msgPrio&quot; must
not exceed MQ_PRIO_MAX.
<P>
If the specified message queue is full and O_NONBLOCK is not
set in the message queue, then mq_send() will block until space
becomes available to the queue the message.
<P>
If the message queue is full and osNON_BLOCK is set, the message
is not queued and ERROR is returned.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>mqdes</I>. Message queue descriptor
<LI><I>msg</I>. Message to send
<LI><I>msgLen</I>. The length of the message in bytes
<LI><I>msgPrio</I>. The priority of the message
</UL>

<P>
<B>Returned Values:</B> None.
<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:
<UL>
<LI>Control is not returned if a signal is received.
</UL>

<H3><a name="mqreceive">2.4.5 mq_receive</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;mqueue.h&gt;
    int mq_receive( mqd_t mqdes, void *msg, size_t msgLen, int *msgPrio );
</PRE>

<P>
<B>Description:</B> This function receives the oldest of the highest
priority messages from the message queue specified by &quot;mqdes.&quot;
If the size of the buffer in bytes (msgLen) is less than the &quot;mq_msgsize&quot;
attribute of the message queue, mq_receive will return an error.
Otherwise, the select message is removed from the queue and copied
to &quot;msg.&quot;
<P>
If the message queue is empty and O_NONBLOCK was not set, mq_receive()
will block until a message is added to the message queue. If more
than one task is waiting to receive a message, only the task with
the highest priority that has waited the longest will be unblocked.
<P>
If the queue is empty and O_NONBLOCK is set, ERROR will be
returned.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>mqdes</I>. Message Queue Descriptor
<LI><I>msg</I>. Buffer to receive the message
<LI><I>msgLen</I>. Size of the buffer in bytes
<LI><I>msgPrio</I>. If not NULL, the location to store message
priority.
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>Length of the selected message in bytes, otherwise -1 (ERROR).
</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:
<UL>
<LI>Control is not returned if a signal is received.
</UL>

<H3><a name="mqnotify">2.4.6 mq_notify</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;mqueue.h&gt;
    int mq_notify( mqd_t mqdes, const struct sigevent *notification );
</PRE>

<P>
<B>Description:</B> If the &quot;notification&quot; input parameter
is not NULL, this function connects the task with the message queue such
that the specified signal will be sent to the task whenever the message
changes from empty to non-empty. One notification can be attached
to a message queue.
<P>
If &quot;notification&quot; is NULL, the attached notification
is detached (if it was held by the calling task) and the queue
is available to attach another notification.
<P>
When the notification is sent to the registered task, its registration
will be removed.  The message queue will then be available for
registration.
<P>
<B>Input Parameters:</B>
<UL>
<LI><I>mqdes</I>. Message queue descriptor
<LI><I>notification</I>. Real-time signal structure containing:
<UL>
<LI><I>sigev_notify</I>. Should be osSIGEV_SIGNAL (but actually
ignored)
<LI><I>sigev_signo</I>. The signo to use for the notification
<LI><I>sigev_value</I>. Value associated with the signal
</UL>

</UL>

<P>
<B>Returned Values:</B> None.
<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:
<UL>
<LI>The notification signal will be sent to the registered task even if
another task is waiting for the message queue to become non-empty.  This is
inconsistent with the POSIX specification which states, &quot;If a process
has registered for notification of message arrival at a message queue and
some process is blocked in <I>mq_receive</I> waiting to receive a message
when a message arrives at the queue, the arriving message shall satisfy the
appropriate <I>mq_receive()</I> ... The resulting behavior is as if the
message queue remains empty, and no notification shall be sent.&quot;
</UL>

<H3><a name="mqsetattr">2.4.7 mq_setattr</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;mqueue.h&gt;
    int mq_setattr( mqd_t mqdes, const struct mq_attr *mqStat,
                     struct mq_attr *oldMqStat);
</PRE>

<P>
<B>Description:</B> This function sets the attributes associated
with the specified message queue &quot;mqdes.&quot; Only the &quot;O_NONBLOCK&quot;
bit of the &quot;mq_flags&quot; can be changed.
<P>
If &quot;oldMqStat&quot; is non-null, mq_setattr() will store
the previous message queue attributes at that location (just as
would have been returned by mq_getattr()).
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>mqdes</I>. Message queue descriptor
<LI><I>mqStat</I>. New attributes
<LI><I>oldMqState</I>. Old attributes
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK) if attributes are set successfully, otherwise -1
(ERROR).
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.

<H3><a name="mqgetattr">2.4.8 mq_getattr</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;mqueue.h&gt;
    int mq_getattr( mqd_t mqdes, struct mq_attr *mqStat);
</PRE>

<P>
<B>Description:</B> This functions gets status information and
attributes associated with the specified message queue.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>mqdes</I>. Message queue descriptor
<LI><I>mqStat</I>. Buffer in which to return attributes. The returned
attributes include:
<UL>
<LI><I>mq_maxmsg</I>. Max number of messages in queue.
<LI><I>mq_msgsize</I>. Max message size.
<LI><I>mq_flags</I>. Queue flags.
<LI><I>mq_curmsgs</I>. Number of messages currently in queue.
</UL>

</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK) if attributes provided, -1 (ERROR) otherwise.
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.

<H2>2.5 <A NAME="Semaphores">Counting Semaphore Interfaces</A></H2>

<p>
  <b>Semaphores</b>.  Semaphores are the basis for
  synchronization and mutual exclusion in NuttX. NuttX supports
  POSIX semaphores.
</p>
<p>
  Semaphores are the preferred mechanism for gaining exclusive access to a
  resource.  sched_lock() and sched_unlock() can also be used for this purpose.
  However, sched_lock() and sched_unlock() have other undesirable side-affects
  in the operation of the system:  sched_lock() also prevents higher-priority
  tasks from running that do not depend upon the semaphore-managed resource
  and, as a result, can adversely affect system response times.
</p>
<p>
  <B>Priority Inversion</B>.  Proper use of semaphores avoids the issues of
  sched_lock().  However, consider the following example:
  <OL>
    <LI>Some low-priority task, <I>Task C</I>, acquires a semphore in order to
      get exclusive access to a protected resource.</li>
    <LI><I>Task C</I> is suspended to allow some high-priority task,</li>
      <I>Task A</I>, to execute.</li>
    <LI><I>Task A</I> attempts to acquire the semaphore held by <I>Task C</I> and
      gets blocked until <I>Task C</I> relinquishes the semaphore.</li>
    <LI><I>Task C</I> is allowed to execute again, but gets suspended by some
      medium-priority <I>Task B</I>.</li>
  </OL>
<p>
  At this point, the high-priority <I>Task A</I> cannot execute until
  <I>Task B</I> (and possibly other medium-priority tasks) completes and until
  <I>Task C</I> relinquishes the semaphore.  In effect, the high-priority task,
  <I>Task A</I> behaves as though it were lower in priority than the
  low-priority task, <I>Task C</I>!  This phenomenon is called <I>priority
  inversion</I>.
</p>
<p>
  Some operating systems avoid priority inversion by <I>automatically</I>
  increasing the priority of the low-priority <I>Task C</I> (the operable
  buzz-word for this behavior is <I>priority inheritance</I>).  NuttX does not
  support this behavior.  As a consequence, it is left to the designer to
  provide implementations that will not suffer from priority inversion.
  The designer may, as examples:
</p>
<UL>
  <LI>Implement all tasks that need the semphore-managed resources at the
    same priority level,</li>
  <LI>Boost the priority of the low-priority task before the semaphore is
    acquired, or</li>
  <LI>Use sched_lock() in the low-priority task.</li>
</UL>
<p>
  POSIX semaphore interfaces:
</p>
<ul>
  <li><a href="#seminit">2.5.1 sem_init</a></li>
  <li><a href="#semdestroy">2.5.2 sem_destroy</a></li>
  <li><a href="#semopen">2.5.3 sem_open</a></li>
  <li><a href="#semclose">2.5.4 sem_close</a></li>
  <li><a href="#semunlink">2.5.5 sem_unlink</a></li>
  <li><a href="#semwait">2.5.6 sem_wait</a></li>
  <li><a href="#semtrywait">2.5.7 sem_trywait</a></li>
  <li><a href="#sempost">2.5.8 sem_post</a></li>
  <li><a href="#semgetvalue">2.5.9 sem_getvalue</a></li>
</ul>

<H3><a name="seminit">2.5.1 sem_init</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;semaphore.h&gt;
    int sem_init ( sem_t *sem, int pshared, unsigned int value );
</PRE>

<P>
<B>Description:</B> This function initializes the UN-NAMED semaphore
sem. Following a successful call to sem_init(), the semaphore
may be used in subsequent calls to sem_wait(), sem_post(), and
sem_trywait(). The semaphore remains usable until it is destroyed.
<P>
Only <I>sem</I> itself may be used for performing synchronization.  The
result of referring to copies of <I>sem</I> in calls to <I>sem_wait()</I>,
<I>sem_trywait()</I>, <I>sem_post()</I>, and <I>sem_destroy()</I>, is
not defined.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>sem</I>. Semaphore to be initialized
<LI><I>pshared</I>. Process sharing (not used)
<LI><I>value</I>. Semaphore initialization value 
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK), or -1 (ERROR) if unsuccessful.
</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:
<UL>
<LI>pshared is not used.
</UL>

<H3><a name="semdestroy">2.5.2 sem_destroy</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;semaphore.h&gt;
    int sem_destroy ( sem_t *sem );
</PRE>

<P>
<B>Description:</B> This function is used to destroy the un-named semaphore
indicated by <I>sem</I>.  Only a semaphore that was created using
<I>sem_init()</I> may be destroyed using <I>sem_destroy()</I>.  The effect
of calling <I>sem_destroy()</I> with a named semaphore is undefined.  The
effect of subsequent use of the semaphore <I>sem</I> is undefined until
<I>sem</I> is re-initialized by another call to <I>sem_init()</I>.
<P>
The effect of destroying a semaphore upon which other tasks are currently
blocked is undefined.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>sem</I>. Semaphore to be destroyed.
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK), or -1 (ERROR) if unsuccessful.
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.

<H3><a name="semopen">2.5.3 sem_open</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;semaphore.h&gt;
    sem_t *sem_open ( const char *name, int oflag, ...);
</PRE>

<P>
<B>Description:</B> This function establishes a connection between
named semaphores and a task. Following a call to sem_open() with
the semaphore name, the task may reference the semaphore associated
with name using the address returned by this call. The semaphore
may be used in subsequent calls to sem_wait(), sem_trywait(),
and sem_post(). The semaphore remains usable until the semaphore
is closed by a successful call to sem_close().
<P>
If a task makes multiple calls to sem_open() with the same name,
then the same semaphore address is returned (provided there have
been no calls to sem_unlink()).
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>name</I>. Semaphore name
<LI><I>oflag</I>. Semaphore creation options. This may one of
the following bit settings:
<UL>
<LI><I>oflag</I> = 0: Connect to the semaphore only if it already
exists.
<LI><I>oflag</I> = O_CREAT: Connect to the semaphore if it exists,
otherwise create the semaphore.
<LI><I>oflag</I> = O_CREAT with O_EXCL (O_CREAT|O_EXCL): Create
a new semaphore unless one of this name already exists.
</UL>
<LI>... Optional parameters.
NOTE:  When the O_CREAT flag is specified, POSIX requires that a third
and fourth parameter be supplied:
<UL>
<LI><I>mode</I>.  The mode parameter is of type mode_t.  
This parameter is required but not used in the present
implementation.
<LI><I>value</I>.  The value parameter is type unsigned int.  The semaphore
is created with an initial value of <I>value</I>.  Valid initial values for
semaphores must be less than or equal to <I>SEM_VALUE_MAX</I> (defined in
<CODE>include/limits.h</CODE>).
</UL>
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>A pointer to sem_t or -1 (ERROR) if unsuccessful.
</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:
<UL>
<LI>Treatment of links/connections is highly simplified. It is
just a counting semaphore.
</UL>

<H3><a name="semclose">2.5.4 sem_close</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;semaphore.h&gt;
    int sem_close ( sem_t *sem );
</PRE>

<P>
<B>Description:</B> This function is called to indicate that the
calling task is finished with the specified named semaphore, sem.
The sem_close() deallocates any system resources allocated by
the system for this named semaphore.
<P>
If the semaphore has not been removed with a call to sem_unlink(),
then sem_close() has no effect on the named semaphore. However,
when the named semaphore has been fully unlinked, the semaphore
will vanish when the last task closes it.
<P>
Care must be taken to avoid risking the deletion of a semaphore
that another calling task has already locked.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>sem</I>. Semaphore descriptor
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK), or -1 (ERROR) if unsuccessful.
</UL>

<P>
<B>Assumptions/Limitations:</B>
<UL>
<LI>Care must be taken to avoid deletion of a semaphore that another task
has already locked.
<LI>sem_close() must not be called with an un-named semaphore.
</UL>
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.

<H3><a name="semunlink">2.5.5 sem_unlink</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;semaphore.h&gt;
    int sem_unlink ( const char *name );
</PRE>

<P>
<B>Description:</B> This function will remove the semaphore named by the
input name parameter.  If one or more tasks have the semaphore named by
name oepn when sem_unlink() is called, destruction of the semaphore will
be postponed until all references have been destroyed by calls to
sem_close().
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>name</I>. Semaphore name
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK), or -1 (ERROR) if unsuccessful.
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<UL>
<LI>Care must be taken to avoid deletion of a semaphore that another task
has already locked.
<LI>sem_unlink() must not be called with an un-named semaphore.
</UL>
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.
Differences from the full POSIX implementation include:
<UL>
<LI>Treatment of links/connections is highly simplified. It is
just a counting semaphore.
<LI>Calls to sem_open() to re-create or re-connect to the semaphore may
refer to the same semaphore; POSIX specifies that a new semaphore with the
same name should be created after sem_unlink() is called.
</UL>

<H3><a name="semwait">2.5.6 sem_wait</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;semaphore.h&gt;
    int sem_wait ( sem_t *sem );
</PRE>

<P>
<B>Description:</B> This function attempts to lock the semaphore
referenced by sem. If the semaphore as already locked by another
task, the calling task will not return until it either successfully acquires
the lock or the call is interrupted by a signal.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>sem</I>. Semaphore descriptor.
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK), or -1 (ERROR) is unsuccessful
</UL>
<P>
If <I>sem_wait</I> returns -1 (ERROR) then the cause of the failure
will be indicated by the thread-specific <I>errno</I> value (a pointer
to this value can be obtained using <I>get_errno_ptr()</I>).  The following
lists the possible values for <I>errno</I>:
<P>
<UL>
<LI><I>EINVAL</I>:  Indicates that the <I>sem</I> input parameter is
not valid.
<LI><I>EINTR</I>:  Indicates that the wait was interrupt by a signal
received by this task.  In this case, the semaphore has not be acquired.
</UL>
<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.

<H3><a name="semtrywait">2.5.7 sem_trywait</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;semaphore.h&gt;
    int sem_trywait ( sem_t *sem );
</PRE>

<P>
<B>Description:</B> This function locks the specified semaphore
only if the semaphore is currently not locked.  In any event, the call
returns without blocking.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>sem</I>. The semaphore descriptor
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK) or -1 (ERROR) if unsuccessful
</UL>
If <I>sem_wait</I> returns -1 (ERROR) then the cause of the failure
will be indicated by the thread-specific <I>errno</I> value (a pointer
to this value can be obtained using <I>get_errno_ptr()</I>).  The following
lists the possible values for <I>errno</I>:
<P>
<UL>
<LI><I>EINVAL</I>:  Indicates that the <I>sem</I> input parameter is
not valid.
<LI><I>EAGAIN</I>:  Indicates that the semaphore was not acquired.
</UL>
<P>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.

<H3><a name="sempost">2.5.8 sem_post</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;semaphore.h&gt;
    int sem_post ( sem_t *sem );
</PRE>

<P>
<B>Description:</B> When a task has finished with a semaphore,
it will call sem_post().  This function unlocks the semaphore referenced
by <I>sem</I> by performing the semaphore unlock operation.
<P>
If the semaphore value resulting from this operation is positive, then
no tasks were blocked waiting for the semaphore to become unlocked;
The semaphore value is simply incremented.
<P>
If the value of the semaphore resulting from this operation is zero, then
on of the tasks blocked waiting for the semaphore will be allowed to
return successfully from its call to <I>sem_wait()</I>.
<P>
<B>NOTE</B>:  <I>sem_post()</I> may be called from an interrupt handler.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>sem</I>. Semaphore descriptor
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK) or -1 (ERROR) if unsuccessful.
</UL>

<P>
<B>Assumptions/Limitations:</B> This function cannot be called
from an interrupt handler. It assumes the currently executing
task is the one that is performing the unlock.
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.

<H3><a name="semgetvalue">2.5.9 sem_getvalue</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;semaphore.h&gt;
    int sem_getvalue ( sem_t *sem, int *sval );
</PRE>

<P>
<B>Description:</B> This function updates the location referenced
by sval argument to have the value of the semaphore referenced
by sem without effecting the state of the semaphore. The updated
value represents the actual semaphore value that occurred at some
unspecified time during the call, but may not reflect the actual
value of the semaphore when it is returned to the calling task.
<P>
If sem is locked, the value return by sem_getvalue() will either
be zero or a negative number whose absolute value represents the
number of tasks waiting for the semaphore.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>sem</I>. Semaphore descriptor
<LI><I>sval</I>. Buffer by which the value is returned
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>0 (OK) or -1 (ERROR) if unsuccessful.
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>  POSIX  Compatibility:</B> Comparable to the POSIX
interface of the same name.

<HR>

<H2>2.6 <A NAME="Watchdogs">Watchdog Timer Interfaces</A></H2>

<P>
  NuttX provides a general watchdog timer facility.
  This facility allows the NuttX user to specify a watchdog timer function
  that will run after a specified delay.
  The watchdog timer function will run in the context of the timer interrupt handler.
  Because of this, a limited number of NuttX interfaces are available to he watchdog timer function.
  However, the watchdog timer function may use mq_send(), sigqueue(), or kill() to communicate with NuttX tasks.
</p>
<ul>
  <li><a href="#wdcreate">2.6.1 wd_create</a></li>
  <li><a href="#wddelete">2.6.2 wd_delete</a></li>
  <li><a href="#wdstart">2.6.3 wd_start</a></li>
  <li><a href="#wdcancel">2.6.4 wd_cancel</a></li>
  <li><a href="#wdgettime">2.6.5 wd_gettime</a></li>
</ul>

<H3><a name="wdcreate">2.6.1 wd_create</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;wdog.h&gt;
    WDOG_ID wd_create (void);
</PRE>

<P>
<B>Description:</B> The wd_create function will create a watchdog
by allocating the appropriate resources for the watchdog.
<P>
<B>Input Parameters:</B> None.
<P>
<B>Returned Values:</B> 
<UL>
<LI>Pointer to watchdog that may be used as a handle in subsequent
NuttX calls (i.e., the watchdog ID), or NULL if insufficient resources
are available to create the watchdogs.
</UL>

<P>
<B>Assumptions/Limitations:</B> 
<P>
<B>  POSIX  Compatibility:</B> This is a NON-POSIX interface.
VxWorks provides the following comparable interface:
<PRE>
    WDOG_ID wdCreate (void);
</PRE>

<P>
Differences from the VxWorks interface include:
<UL>
<LI>The number of available watchdogs is fixed (configured at
initialization time).
</UL>

<H3><a name="wddelete">2.6.2 wd_delete</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;wdog.h&gt;
    STATUS wd_delete (WDOG_ID wdog);
</PRE>

<P>
<B>Description:</B> The wd_delete function will deallocate a
watchdog. The watchdog will be removed from the timer queue if
has been started.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>wdog</I>. The watchdog ID to delete. This is actually a
pointer to a watchdog structure.
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>OK or ERROR
</UL>

<P>
<B>Assumptions/Limitations:</B> It is the responsibility of the
caller to assure that the watchdog is inactive before deleting
it.
<P>
<B>  POSIX  Compatibility:</B> This is a NON-POSIX interface.
VxWorks provides the following comparable interface:
<PRE>
    STATUS wdDelete (WDOG_ID wdog);
</PRE>

<P>
Differences from the VxWorks interface include:
<UL>
<LI>Does not make any checks to see if the watchdog is being used
before de-allocating it (i.e., never returns ERROR).
</UL>

<H3><a name="wdstart">2.6.3 wd_start</a></H3>

<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;wdog.h&gt;
    STATUS wd_start( WDOG_ID wdog, int delay, wdentry_t wdentry,
                     intt argc, ....);
</PRE>

<P>
<B>Description:</B> This function adds a watchdog to the timer
queue. The specified watchdog function will be called from the
interrupt level after the specified number of ticks has elapsed.
Watchdog timers may be started from the interrupt level.
<P>
Watchdog times execute in the context of the timer interrupt handler, but
with the PIC/PID address environment that was in place when wd_start()
was called.
<P>
Watchdog timers execute only once.
<P>
To replace either the timeout delay or the function to be executed,
call wd_start again with the same wdog; only the most recent
wd_start() on a given watchdog ID has any effect.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>wdog</I>. Watchdog ID
<LI><I>delay</I>. Delay count in clock ticks
<LI><I>wdentry</I>. Function to call on timeout
<LI><I>argc</I>.  The number of uint32 parameters to pass to wdentry.
<LI><I>...</I>. uint32 size parameters to pass to wdentry
</UL>

<P>
<B>Returned Values:</B> 
<UL>
<LI>OK or ERROR
</UL>

<P>
<B>Assumptions/Limitations:</B> The watchdog routine runs in the
context of the timer interrupt handler and is subject to all ISR
restrictions.
<P>
<B>  POSIX  Compatibility:</B> This is a NON-POSIX interface.
VxWorks provides the following comparable interface:
<PRE>
    STATUS wdStart (WDOG_ID wdog, int delay, FUNCPTR wdentry, int parameter);
</PRE>

<P>
Differences from the VxWorks interface include:
<UL>
<LI>The present implementation supports multiple parameters passed
to wdentry; VxWorks supports only a single parameter.  The maximum
number of parameters is determined by 
</UL>

<H3><a name="wdcancel">2.6.4 wd_cancel</a></H3>
<P>
<B>Function Prototype:</B> 
<PRE>
    #include &lt;wdog.h&gt;
    STATUS wd_cancel (WDOG_ID wdog);
</PRE>

<P>
<B>Description:</B> This function cancels a currently running
watchdog timer. Watchdog timers may be canceled from the interrupt
level.
<P>
<B>Input Parameters:</B> 
<UL>
<LI><I>wdog</I>. ID of the watchdog to cancel.
</UL>

<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.
VxWorks provides the following comparable interface:
<PRE>
    STATUS wdCancel (WDOG_ID wdog);
</PRE>

<h3><a name="wdgettime">2.6.5 wd_gettime</a></h3>
<p>
  <b>Function Prototype:</b>
</p>
<pre>
    #include &lt;wdog.h&gt;
    Sint wd_gettime(WDOG_ID wdog);
</pre>
<p>
  <b>Description:</b> 
   This function returns the time remaining before the the specified watchdog expires.
</p>
<p>
  <b>Input Parameters:</b>
  <ul>
    <li><code>wdog</code>. Identifies the watchdog that the request is for.</li>
  </ul>
</p>
<p>
  <b>Returned Value:</b> 
  The time in system ticks remaining until the watchdog time expires.  Zero
  means either that wdog is not valid or that the wdog has already expired.
</p>

<HR>

<H2><A NAME="ClocksNTimers">2.7 Clocks and Timers</A></H2>
<ul>
  <li><a href="#clocksettime">2.7.1 clock_settime</a></li>
  <li><a href="#clockgettime">2.7.2 clock_gettime</a></li>
  <li><a href="#clockgetres">2.7.3 clock_getres</a></li>
  <li><a href="#mktime">2.7.4 mktime</a></li>
  <li><a href="#gmtimer">2.7.5 gmtime_r</a></li>
  <li><a href="#localtimer">2.7.6 localtime_r</a></li>
  <li><a href="#timercreate">2.7.7 timer_create</a></li>
  <li><a href="#timerdelete">2.7.8 timer_delete</a></li>
  <li><a href="#timersettime">2.7.9 timer_settime</a></li>
  <li><a href="#timergettime">2.7.10 timer_gettime</a></li>
  <li><a href="#timergetoverrun">2.7.11 timer_getoverrun</a></li>
</ul>

<H3><a name="clocksettime">2.7.1 clock_settime</A></H3>
<p>
  <b>Function Prototype:</b>
</p>
<pre>
    #include &lt;time.h&gt;
    int clock_settime(clockid_t clockid, const struct timespec *tp);
</pre>
<p>
  <b>Description:</b>
</p>
<p>
  <b>Input Parameters:</b>
</p>
<ul>
  <li><code>parm</code>. </li>
</ul>
<p>
  <b>Returned Values:</b>
</p>
<p>
  If successful, the <I>clock_settime()</I> function will return zero (<I>OK</I>).
  Otherwise, an non-zero error number will be returned to indicate the error:
</p>
<ul>
  <li><code>Exxx</code>.</li>
</ul>

<H3><a name="clockgettime">2.7.2 clock_gettime</A></H3>
<p>
  <b>Function Prototype:</b>
</p>
<pre>
    #include &lt;time.h&gt;
    int clock_gettime(clockid_t clockid, struct timespec *tp);
</pre>
<p>
  <b>Description:</b>
</p>
<p>
  <b>Input Parameters:</b>
</p>
<ul>
  <li><code>parm</code>. </li>
</ul>
<p>
  <b>Returned Values:</b>
</p>
<p>
  If successful, the <I>clock_gettime()</I> function will return zero (<I>OK</I>).
  Otherwise, an non-zero error number will be returned to indicate the error:
</p>
<ul>
  <li><code>Exxx</code>.</li>
</ul>

<H3><a name="clockgetres">2.7.3 clock_getres</A></H3>
<p>
  <b>Function Prototype:</b>
</p>
<pre>
    #include &lt;time.h&gt;
    int clock_getres(clockid_t clockid, struct timespec *res);
</pre>
<p>
  <b>Description:</b>
</p>
<p>
  <b>Input Parameters:</b>
</p>
<ul>
  <li><code>parm</code>. </li>
</ul>
<p>
  <b>Returned Values:</b>
</p>
<p>
  If successful, the <I>clock_getres()</I> function will return zero (<I>OK</I>).
  Otherwise, an non-zero error number will be returned to indicate the error:
</p>
<ul>
  <li><code>Exxx</code>.</li>
</ul>

<H3><a name="mktime">2.7.4 mktime</A></H3>
<p>
  <b>Function Prototype:</b>
</p>
<pre>
    #include &lt;time.h&gt;
    time_t mktime(struct tm *tp);
</pre>
<p>
  <b>Description:</b>
</p>
<p>
  <b>Input Parameters:</b>
</p>
<ul>
  <li><code>parm</code>. </li>
</ul>
<p>
  <b>Returned Values:</b>
</p>
<p>
  If successful, the <I>mktime()</I> function will return zero (<I>OK</I>).
  Otherwise, an non-zero error number will be returned to indicate the error:
</p>
<ul>
  <li><code>Exxx</code>.</li>
</ul>

<H3><a name="gmtimer">2.7.5 gmtime_r</A></H3>
<p>
  <b>Function Prototype:</b>
</p>
<pre>
    #include &lt;time.h&gt;
    struct tm *gmtime_r(const time_t *clock, struct tm *result);
</pre>
<p>
  <b>Description:</b>
</p>
<p>
  <b>Input Parameters:</b>
</p>
<ul>
  <li><code>parm</code>. </li>
</ul>
<p>
  <b>Returned Values:</b>
</p>
<p>
  If successful, the <I>gmtime_r()</I> function will return zero (<I>OK</I>).
  Otherwise, an non-zero error number will be returned to indicate the error:
</p>
<ul>
  <li><code>Exxx</code>.</li>
</ul>