Added more information to the "next step" chapter. The new information

tries to give a pointer about how to approach writing an application.

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 "" $<
 

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.