summaryrefslogtreecommitdiffstats
path: root/doc/started/nextstep.t
diff options
context:
space:
mode:
authorJoel Sherrill <joel.sherrill@OARcorp.com>2010-12-14 16:51:17 +0000
committerJoel Sherrill <joel.sherrill@OARcorp.com>2010-12-14 16:51:17 +0000
commitdf6311707e1c2016a73dce8b3525bc0c740c8bca (patch)
tree7145e81b566c2eab42012a9bb6250bb51ec9b199 /doc/started/nextstep.t
parentRegenerate. (diff)
downloadrtems-df6311707e1c2016a73dce8b3525bc0c740c8bca.tar.bz2
2010-12-14 Joel Sherrill <joel.sherrill@oarcorp.com>
* Makefile.am, configure.ac, common/cpright.texi, common/rtems.texi.in, cpu_supplement/.cvsignore, started/Makefile.am, started/binaries.t, started/buildc.t, started/buildrt.t, started/intro.t, started/nextstep.t, started/nt.t, started/require.t, started/sample.t, started/started.texi, started/version.texi: Major update which includes removal of references to specific tool versions and patches. * started/tversions.texi.in: Removed.
Diffstat (limited to 'doc/started/nextstep.t')
-rw-r--r--doc/started/nextstep.t159
1 files changed, 74 insertions, 85 deletions
diff --git a/doc/started/nextstep.t b/doc/started/nextstep.t
index 0d5a880dc3..b0e0f3c535 100644
--- a/doc/started/nextstep.t
+++ b/doc/started/nextstep.t
@@ -1,6 +1,5 @@
@c
-@c
-@c COPYRIGHT (c) 1988-2002.
+@c COPYRIGHT (c) 1988-2010.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -9,74 +8,70 @@
@chapter Where To Go From Here
-At this point, you should have successfully installed a
-GNU Cross Compilation Tools for RTEMS on your host system
-as well as the RTEMS OS for the target host. You should
-have successfully linked the "hello world" program. You
-may even have downloaded the executable to that target
-and run it. What do you do next?
-
-The answer is that it depends. You may be interested in
-writing an application that uses one of the multiple
-APIs supported by RTEMS. You may need to investigate the
-network or filesystem support in RTEMS. The common
-thread is that you are largely finished with this
-manual and ready to move on to others.
-
-Whether or not you decide to dive in now and write
-application code or read some documentation first,
-this chapter is for you. The first section provides
-a quick roadmap of some of the RTEMS documentation.
-The next section provides a brief overview of the
-RTEMS application structure.
+At this point, you should have successfully installed a GNU Cross
+Compilation Tools for RTEMS on your host system as well as the RTEMS OS
+for the target host. You should have successfully linked the "hello
+world" program. You may even have downloaded the executable to that
+target and run it. What do you do next?
+
+The answer is that it depends. You may be interested in writing an
+application that uses one of the multiple APIs supported by RTEMS.
+You may need to investigate the network or filesystem support in RTEMS.
+The common thread is that you are largely finished with this manual and
+ready to move on to others.
+
+Whether or not you decide to dive in now and write application code or
+read some documentation first, this chapter is for you. The first section
+provides a quick roadmap of some of the RTEMS documentation. The next
+section provides a brief overview of the RTEMS application structure.
@section Documentation Overview
-When writing RTEMS applications, you should find the
-following manuals useful because they define the
-calling interface to many of the services provided
-by RTEMS:
+When writing RTEMS applications, you should find the following manuals
+useful because they define the calling interface to many of the services
+provided by RTEMS:
@itemize @bullet
@item @b{RTEMS Applications C User's Guide} describes the
Classic RTEMS API based on the RTEID specification.
-@item @b{RTEMS POSIX API User's Guide} describes the
-RTEMS POSIX API that is based on the POSIX 1003.1b API.
+@item @b{RTEMS POSIX API User's Guide} describes the RTEMS POSIX API
+that is based on the POSIX 1003.1b API. If there is any place where
+this manual is thin or unclear, please refer to the OpenGroup Single
+UNIX Specification. RETEMS tracks that specification for future POSIX
+revisions.
-@item @b{RTEMS Network Supplement} provides information
-on the network services provided by RTEMS.
+@item @b{RTEMS Network Supplement} provides information on the network
+services provided by RTEMS. RTEMS provides a BSD sockets programming
+interface so any network programming book should be helpful.
@end itemize
-In addition, the following manuals from the GNU Cross
-Compilation Toolset include information on run-time services
-available.
+In addition, the following manuals from the GNU Cross Compilation Toolset
+include information on run-time services available.
@itemize @bullet
-@item @b{Cygnus C Support Library} describes the Standard
-C Library functionality provided by Newlib's libc.
+@item @b{Cygnus C Support Library} describes the Standard C Library
+functionality provided by Newlib's libc.
-@item @b{Cygnus C Math Library} describes the Standard
-C Math Library functionality provided by Newlib's libm.
+@item @b{Cygnus C Math Library} describes the Standard C Math Library
+functionality provided by Newlib's libm.
@end itemize
-Finally, the RTEMS FAQ and mailing list archives are available
-at @uref{@value{RTEMSHTTPURL}}.
+Finally, the RTEMS FAQ, Wiki, and mailing list archives are available
+at @uref{http://www.rtems.org, http://www.rtems.org}.
-There is a wealth of documentation available for RTEMS and
-the GNU tools supporting it. If you run into something
-that is not clear or missing, bring it to our attention.
+There is a wealth of documentation available for RTEMS and the GNU tools
+supporting it. If you run into something that is not clear or missing,
+bring it to our attention.
-Also, some of the RTEMS documentation is still under
-construction. If you would like to contribute to this
-effort, please contact the RTEMS Team at
-@uref{mailto:@value{RTEMSUSERS}, @value{RTEMSUSERS}}.
-If you are interested in sponsoring the development of a new
-feature, BSP, device driver, port of an existing library, etc.,
-please contact one of the RTEMS Service Providers listed
-at @uref{@value{RTEMSHTTPURL}/support.html,@value{RTEMSHTTPURL}/support.html}.
+Also, some of the RTEMS documentation is still under construction.
+If you would like to contribute to this effort, please contact the
+RTEMS Team at @uref{mailto:@value{RTEMSUSERS}, @value{RTEMSUSERS}}.
+If you are interested in sponsoring the development of a new feature,
+BSP, device driver, port of an existing library, etc., please contact
+@uref{mailto:sales@@oarcorp.com, sales@@oarcorp.com}.
@section Writing an Application
@@ -86,29 +81,25 @@ RTEMS provides a single process, multi-threaded run-time
environment. However there are two important things that are
different from a standard UNIX hosted program.
-First, the application developer must provide configuration
-information for RTEMS. This configuration information
-includes limits on the maximum number of various OS resources
-available and networking configuration among other things.
-See the @b{Configuring a System} in the
-@b{RTEMS Applications C User's Guide} for more details.
-
-Second, RTEMS applications may or may not start at
-@code{main()}. Applications begin execution at
-one or more user configurable application
-initialization tasks or threads. It is possible
-to configure an application to start with a
-single thread that whose entry point is @code{main()}.
-
-Each API supported by RTEMS (Internal, Classic, and POSIX)
-allows the user to configure a set of one or more tasks
-that are created and started automatically
-during RTEMS initialization. The RTEMS Automatic
-Configuration Generation (@code{confdefs.h}) scheme can be
-used to easily generate the configuration information for
-an application that starts with a single initialization task.
-By convention, unless overridden, the default name of the
-initialization task varies based up API.
+First, the application developer must provide configuration information
+for RTEMS. This configuration information includes limits on the maximum
+number of various OS resources available and networking configuration
+among other things. See the @b{Configuring a System} in the @b{RTEMS
+Applications C User's Guide} for more details.
+
+Second, RTEMS applications may or may not start at @code{main()}.
+Applications begin execution at one or more user configurable application
+initialization tasks or threads. It is possible to configure an
+application to start with a single thread that whose entry point is
+@code{main()}.
+
+Each API supported by RTEMS (Internal, Classic, and POSIX) allows
+the user to configure a set of one or more tasks that are created and
+started automatically during RTEMS initialization. The RTEMS Automatic
+Configuration Generation (@code{confdefs.h}) scheme can be used to easily
+generate the configuration information for an application that starts
+with a single initialization task. By convention, unless overridden,
+the default name of the initialization task varies based up API.
@itemize @bullet
@item @code{Init} - single Classic API Initialization Task
@@ -129,17 +120,15 @@ file @code{init.c} usually contains the initialization task. Although
not required, in most of the examples, the initialization task
completes by deleting itself.
-As you begin to write RTEMS application code, you may be confused
-by the range of alternatives. Supporting multiple tasking
-APIs can make the choices confusing. Many application groups
-writing new code choose one of the APIs as their primary API
-and only use services from the others if nothing comparable
-is in their preferred one. However, the support for multiple
-APIs is a powerful feature when integrating code from multiple
-sources. You can write new code using POSIX services and
-still use services written in terms of the other APIs.
-Moreover, by adding support for yet another API, one could
-provide the infrastructure required to migrate from a
-legacy RTOS with a non-standard API to an API like POSIX.
+As you begin to write RTEMS application code, you may be confused by the
+range of alternatives. Supporting multiple tasking APIs can make the
+choices confusing. Many application groups writing new code choose one
+of the APIs as their primary API and only use services from the others if
+nothing comparable is in their preferred one. However, the support for
+multiple APIs is a powerful feature when integrating code from multiple
+sources. You can write new code using POSIX services and still use
+services written in terms of the other APIs. Moreover, by adding support
+for yet another API, one could provide the infrastructure required to
+migrate from a legacy RTOS with a non-standard API to an API like POSIX.