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 Configuring a System in the RTEMS Applications C User's Guide for more details.
Second, RTEMS applications may or may not start at
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 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 (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.
Init
- single Classic API Initialization Task
POSIX_Init
- single POSIX API Initialization Thread
ITRON_Init
- single ITRON API Initialization Task
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 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.
Copyright © 1988-2004 OAR Corporation