summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorJoel Sherrill <joel.sherrill@OARcorp.com>2000-05-08 16:53:25 +0000
committerJoel Sherrill <joel.sherrill@OARcorp.com>2000-05-08 16:53:25 +0000
commit12cc4c6abb4c3d900dc6b70783ce518d7587c00c (patch)
tree978dda2876418d5bf1d2b99de28c4320b9a511e6 /doc
parent92d528b7143fddb3c53043fb79291670bbdbb482 (diff)
downloadrtems-12cc4c6abb4c3d900dc6b70783ce518d7587c00c.tar.bz2
Added more information to the "next step" chapter. The new information
tries to give a pointer about how to approach writing an application.
Diffstat (limited to 'doc')
-rw-r--r--doc/started/Makefile.am2
-rw-r--r--doc/started/nextstep.t57
2 files changed, 58 insertions, 1 deletions
diff --git a/doc/started/Makefile.am b/doc/started/Makefile.am
index 2237ee0c2d..561bbf8e41 100644
--- a/doc/started/Makefile.am
+++ b/doc/started/Makefile.am
@@ -65,7 +65,7 @@ nextstep.texi: nextstep.t tversions.texi
-n "Using MS-Windows as a Development Host" $<
nt.texi: nt.t tversions.texi
- $(BMENU) -c -p "Where To Go From Here" \
+ $(BMENU) -c -p "Writing an Application" \
-u "Top" \
-n "" $<
diff --git a/doc/started/nextstep.t b/doc/started/nextstep.t
index 56e4dcdeac..22d16279ed 100644
--- a/doc/started/nextstep.t
+++ b/doc/started/nextstep.t
@@ -23,6 +23,15 @@ 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
@@ -67,6 +76,54 @@ Also, some of the RTEMS documentation is still under
construction. If you would like to contribute to this
effort, please contact the RTEMS Team.
+@section Writing an Application
+
+From an application author's perspective, RTEMS applications do not
+start at @code{main()}. They begin execution at one or more
+application initialization task or thread and @code{main()} is
+owned by the Board Support Package. Each API supported
+by RTEMS (Classic, POSIX, and ITRON) allows the user to configure
+a set of 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
+See the Configuring a System chapter in the C User's Guide for
+more details.
+
+Regardless of the API used, when the initialization task executes,
+all non-networking device drivers are normally initialized and
+processor interrupts are enabled. The initialization task then
+goes about its business of performing application specific
+initialization. This often involves 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 plethora 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.