source: rtems/doc/started/nextstep.t @ 48cd0b8e
Last change on this file since 48cd0b8e was 48cd0b8e, checked in by Joel Sherrill <joel.sherrill@…>, on Oct 2, 2003 at 6:01:48 PM

2003-10-02 Joel Sherrill <joel@…>

  •, binaries.t, buildc.t, intro.t, nextstep.t, require.t, sample.t, started.texi: General improvements and merge enough Ada information to justify dropping the Ada specific manual. There is likely still Ada specific information to merge though.
  • Property mode set to 100644
File size: 5.8 KB
3@c  COPYRIGHT (c) 1988-2002.
4@c  On-Line Applications Research Corporation (OAR).
5@c  All rights reserved.
7@c  $Id$
10@chapter Where To Go From Here
12At this point, you should have successfully installed a
13GNU Cross Compilation Tools for RTEMS on your host system
14as well as the RTEMS OS for the target host.  You should
15have successfully linked the "hello world" program. You
16may even have downloaded the executable to that target
17and run it.  What do you do next?
19The answer is that it depends.  You may be interested in
20writing an application that uses one of the multiple
21APIs supported by RTEMS.  You may need to investigate the
22network or filesystem support in RTEMS.  The common
23thread is that you are largely finished with this
24manual and ready to move on to others.
26Whether or not you decide to dive in now and write
27application code or read some documentation first,
28this chapter is for you.  The first section provides
29a quick roadmap of some of the RTEMS documentation.
30The next section provides a brief overview of the
31RTEMS application structure.
33@section Documentation Overview
35When writing RTEMS applications, you should find the
36following manuals useful because they define the
37calling interface to many of the services provided
38by RTEMS:
40@itemize @bullet
41@item @b{RTEMS Applications C User's Guide} describes the
42Classic RTEMS API based on the RTEID specification.
44@item @b{RTEMS POSIX API User's Guide} describes the
45RTEMS POSIX API that is based on the POSIX 1003.1b API.
47@item @b{RTEMS ITRON 3.0 API User's Guide} describes
48the RTEMS implementation of the ITRON 3.0 API.
50@item @b{RTEMS Network Supplement} provides information
51on the network services provided by RTEMS.
53@end itemize
55In addition, the following manuals from the GNU Cross
56Compilation Toolset include information on run-time services
59@itemize @bullet
60@item @b{Cygnus C Support Library} describes the Standard
61C Library functionality provided by Newlib's libc.
63@item @b{Cygnus C Math Library} describes the Standard
64C Math Library functionality provided by Newlib's libm.
66@end itemize
68Finally, the RTEMS FAQ and mailing list archives are available
69at @uref{@value{RTEMSHTTPURL}}.
71There is a wealth of documentation available for RTEMS and
72the GNU tools supporting it.  If you run into something
73that is not clear or missing, bring it to our attention.
75Also, some of the RTEMS documentation is still under
76construction.  If you would like to contribute to this
77effort, please contact the RTEMS Team at
78@uref{mailto:@value{RTEMSUSERS}, @value{RTEMSUSERS}}.
79If you are interested in sponsoring the development of a new
80feature, BSP, device driver, port of an existing library, etc.,
81please contact one of the RTEMS Service Providers listed
82at @uref{@value{RTEMSHTTPURL}/support.html,@value{RTEMSHTTPURL}/support.html}.
84@section Writing an Application
86From an application author's perspective, the structure of
87an RTEMS application is very familiar.  In POSIX language,
88RTEMS provides a single process, multi-threaded run-time
89environment.  However there are two important things that are
90different from a standard UNIX hosted program.
92First, the application developer must provide configuration
93information for RTEMS.  This configuration information
94includes limits on the maximum number of various OS resources
95available and networking configuration among other things.
96See the @b{Configuring a System} in the
97@b{RTEMS Applications C User's Guide} for more details.
99Second, RTEMS applications may or may not start at
100@code{main()}.  Applications begin execution at
101one or more user configurable application
102initialization tasks or threads.  It is possible
103to configure an application to start with a
104single thread that whose entry point is @code{main()}.
106Each API supported by RTEMS (Classic, POSIX, and ITRON)
107allows the user to configure a set of one or more tasks
108that are created and started automatically
109during RTEMS initialization.  The RTEMS Automatic
110Configuration Generation (@code{confdefs.h}) scheme can be
111used to easily generate the configuration information for
112an application that starts with a single initialization task. 
113By convention, unless overridden, the default name of the
114initialization task varies based up API.
116@itemize @bullet
117@item @code{Init} - single Classic API Initialization Task
119@item @code{POSIX_Init} - single POSIX API Initialization Thread
121@item @code{ITRON_Init} - single ITRON API Initialization Task
122@end itemize
124Regardless of the API used, when the initialization task executes,
125all non-networking device drivers are normally initialized,
126processor interrupts are enabled, and any C++ global constructors
127have been run.  The initialization task then goes about its
128business of performing application specific initialization which
129will include initializing the networking subsystem if it is to be
130used.  The application initialization may also involve creating
131tasks and other system resources such as semaphores or message queues
132and allocating memory.  In the RTEMS examples and tests, the
133file @code{init.c} usually contains the initialization task.  Although
134not required, in most of the examples, the initialization task
135completes by deleting itself.
137As you begin to write RTEMS application code, you may be confused
138by the range of alternatives.  Supporting multiple tasking
139APIs can make the choices confusing.  Many application groups
140writing new code choose one of the APIs as their primary API
141and only use services from the others if nothing comparable
142is in their preferred one.  However, the support for multiple
143APIs is a powerful feature when integrating code from multiple
144sources.  You can write new code using POSIX services and
145still use services written in terms of the other APIs.
146Moreover, by adding support for yet another API, one could
147provide the infrastructure required to migrate from a
148legacy RTOS with a non-standard API to an API like POSIX.
Note: See TracBrowser for help on using the repository browser.