Newer
Older
<body background="backgd.gif">
<hr>
<hr>
<center><h1><i>Under Construction</i></h1></center>
<hr>
<hr>
NuttX Operating System
<P>
User's Manual
</B></BIG>
<P>
<SMALL>by</SMALL>
<P>
Gregory Nutt
<P>
<SMALL>Last Update: January 28, 2007</SMALL>
</CENTER>
<H1>1.0 <A NAME="Introduction">Introduction</A></H1>
<P>
This user's manual is divided into three sections:
<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="#Signals">Signal Interfaces</A>
<LI>Paragraph 2.8 <A HREF="#Pthread">Pthread 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.
</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
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 "processes"
NuttX only supports simple threads running within the same address space.
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
However, the programming model makes a distinction between "tasks"
and pthreads:
<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.
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>
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.
<H3>2.1.1 task_create</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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 "main"
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.
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
</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
<LI>Interface name
<LI>Various differences in types of arguments
<LI>A variable number of parameters can be passed to a task (VxWorks supports ten).
</UL>
<H3>2.1.2 task_init</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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.
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
</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
<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).
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
</UL>
<H3>2.1.3 task_activate</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
following ways:
<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>2.1.4 task_delete</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
the following ways:
<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>2.1.5 exit</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
void exit( int code );
#include <nuttx/unistd.h>
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
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
the following ways:
<UL>
<LI>The <I>code</I> parameter is ignored.
</UL>
<H3>2.1.6 task_restart</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
STATUS task_restart( pid_t pid );
</PRE>
<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
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
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
the following ways:
<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>2.1.7 getpid</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <unistd.h>
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>
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>
The OS interfaces described in the following paragraphs provide
a POSIX- compliant interface to the NuttX scheduler. However, these
than those provided by the NuttX scheduler. As a result, many of
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
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
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
these POSIX interfaces are little more than stubs.
<H3>2.2.1 sched_setparam</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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><I>param</I>. 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>2.2.2 sched_getparam</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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><I>param</I>. 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>2.2.3 sched_setscheduler</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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><I>param</I>. 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>2.2.4 sched_getscheduler</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
int sched_getscheduler (pid_t pid);
</PRE>
<P>
<B>Description:</B>
<i>sched_getscheduler()</i> returns the scheduling policy
currently applied to the process 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>2.2.5 sched_yield</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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>2.2.6 sched_get_priority_max</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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>2.2.7 sched_get_priority_min</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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>2.2.8 sched_get_rr_interval</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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>
<H3>2.3.1 sched_lock</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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>2.3.2 sched_unlock</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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>2.3.3 sched_lockcount</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <sched.h>
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>
The NuttX supports POSIX named message queues for intertask communication.
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Any task may send or receive messages on named message queues.
Interrupt handlers may send messages via named message queues.
<H3>2.4.1 mq_open</H3>
<P>
<B>Function Prototype:</B>
<PRE>
#include <mqueue.h>
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 & 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>