From df6311707e1c2016a73dce8b3525bc0c740c8bca Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Tue, 14 Dec 2010 16:51:17 +0000 Subject: 2010-12-14 Joel Sherrill * 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. --- doc/started/nextstep.t | 159 +++++++++++++++++++++++-------------------------- 1 file changed, 74 insertions(+), 85 deletions(-) (limited to 'doc/started/nextstep.t') 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. -- cgit v1.2.3