forked from Imagelibrary/rtems
2010-12-16 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: Major update which includes removal of references to specific tool versions and patches. * started/tversions.texi.in: Removed.
This commit is contained in:
Joel Sherrill
@@ -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,77 +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?
|
||||
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.
|
||||
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.
|
||||
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 ITRON 3.0 API User's Guide} describes
|
||||
the RTEMS implementation of the ITRON 3.0 API.
|
||||
|
||||
@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
|
||||
|
||||
@@ -89,36 +81,30 @@ 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.
|
||||
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()}.
|
||||
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 (Classic, POSIX, and ITRON)
|
||||
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.
|
||||
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
|
||||
|
||||
@item @code{POSIX_Init} - single POSIX API Initialization Thread
|
||||
|
||||
@item @code{ITRON_Init} - single ITRON API Initialization Task
|
||||
@end itemize
|
||||
|
||||
Regardless of the API used, when the initialization task executes,
|
||||
@@ -134,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.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user