forked from Imagelibrary/rtems
11be37d1e3
* Makefile.am, configure.ac, index.html.in, develenv/direct.t, posix_users/gen_size_report, started/nextstep.t, started_ada/buildada.t, user/conf.t, user/object.t: Remove ITRON API. * itron3.0/.cvsignore, itron3.0/Makefile.am, itron3.0/config.t, itron3.0/eventflags.t, itron3.0/fixedblock.t, itron3.0/gen_all, itron3.0/gen_section, itron3.0/gen_status_shell, itron3.0/interrupt.t, itron3.0/itron.texi, itron3.0/mailbox.t, itron3.0/memorypool.t, itron3.0/msgbuffer.t, itron3.0/network.t, itron3.0/preface.texi, itron3.0/rendezvous.t, itron3.0/semaphore.t, itron3.0/stamp-vti, itron3.0/status.t, itron3.0/task.t, itron3.0/tasksync.t, itron3.0/time.t, itron3.0/version.texi: Removed.
146 lines
5.7 KiB
Perl
146 lines
5.7 KiB
Perl
@c
|
|
@c
|
|
@c COPYRIGHT (c) 1988-2002.
|
|
@c On-Line Applications Research Corporation (OAR).
|
|
@c All rights reserved.
|
|
@c
|
|
@c $Id$
|
|
@c
|
|
|
|
@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.
|
|
|
|
@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:
|
|
|
|
@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 Network Supplement} provides information
|
|
on the network services provided by RTEMS.
|
|
|
|
@end itemize
|
|
|
|
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 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}}.
|
|
|
|
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}.
|
|
|
|
@section Writing an Application
|
|
|
|
From an application author's perspective, the structure of
|
|
an RTEMS application is very familiar. In POSIX language,
|
|
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.
|
|
|
|
@itemize @bullet
|
|
@item @code{Init} - single Classic API Initialization Task
|
|
|
|
@item @code{POSIX_Init} - single POSIX API Initialization Thread
|
|
@end itemize
|
|
|
|
Regardless of the API used, when the initialization task executes,
|
|
all non-networking device drivers are normally initialized,
|
|
processor interrupts are enabled, and any C++ global constructors
|
|
have been run. The initialization task then goes about its
|
|
business of performing application specific initialization which
|
|
will include initializing the networking subsystem if it is to be
|
|
used. The application initialization may also involve creating
|
|
tasks and other system resources such as semaphores or message queues
|
|
and allocating memory. In the RTEMS examples and tests, the
|
|
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.
|
|
|
|
|