From 12cc4c6abb4c3d900dc6b70783ce518d7587c00c Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Mon, 8 May 2000 16:53:25 +0000 Subject: 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 | 2 +- doc/started/nextstep.t | 57 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 58 insertions(+), 1 deletion(-) (limited to 'doc') 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. -- cgit v1.2.3