mirror of
https://gitlab.rtems.org/rtems/rtos/rtems.git
synced 2025-12-06 15:43:15 +00:00
6449498bc7
* SUPPORT, LICENSE: New files. * Numerous files touched as part of merging the 4.5 branch onto the mainline development trunk and ensuring that the script that cuts snapshots and releases works on the documentation.
190 lines
8.6 KiB
Plaintext
190 lines
8.6 KiB
Plaintext
@c
|
|
@c COPYRIGHT (c) 1988-2002.
|
|
@c On-Line Applications Research Corporation (OAR).
|
|
@c All rights reserved.
|
|
@c
|
|
@c $Id$
|
|
@c
|
|
|
|
@ifinfo
|
|
@node Preface, Overview, Top, Top
|
|
@end ifinfo
|
|
@unnumbered Preface
|
|
|
|
In recent years, the cost required to develop a
|
|
software product has increased significantly while the target
|
|
hardware costs have decreased. Now a larger portion of money is
|
|
expended in developing, using, and maintaining software. The
|
|
trend in computing costs is the complete dominance of software
|
|
over hardware costs. Because of this, it is necessary that
|
|
formal disciplines be established to increase the probability
|
|
that software is characterized by a high degree of correctness,
|
|
maintainability, and portability. In addition, these
|
|
disciplines must promote practices that aid in the consistent
|
|
and orderly development of a software system within schedule and
|
|
budgetary constraints. To be effective, these disciplines must
|
|
adopt standards which channel individual software efforts toward
|
|
a common goal.
|
|
|
|
The push for standards in the software development
|
|
field has been met with various degrees of success. The
|
|
Microprocessor Operating Systems Interfaces (MOSI) effort has
|
|
experienced only limited success. As popular as the UNIX
|
|
operating system has grown, the attempt to develop a standard
|
|
interface definition to allow portable application development
|
|
has only recently begun to produce the results needed in this
|
|
area. Unfortunately, very little effort has been expended to
|
|
provide standards addressing the needs of the real-time
|
|
community. Several organizations have addressed this need
|
|
during recent years.
|
|
|
|
The Real Time Executive Interface Definition (RTEID)
|
|
was developed by Motorola with technical input from Software
|
|
Components Group. RTEID was adopted by the VMEbus International
|
|
Trade Association (VITA) as a baseline draft for their proposed
|
|
standard multiprocessor, real-time executive interface, Open
|
|
Real-Time Kernel Interface Definition (ORKID). These two groups
|
|
are currently working together with the IEEE P1003.4 committee
|
|
to insure that the functionality of their proposed standards is
|
|
adopted as the real-time extensions to POSIX.
|
|
|
|
This emerging standard defines an interface for the
|
|
development of real-time software to ease the writing of
|
|
real-time application programs that are directly portable across
|
|
multiple real-time executive implementations. This interface
|
|
includes both the source code interfaces and run-time behavior
|
|
as seen by a real-time application. It does not include the
|
|
details of how a kernel implements these functions. The
|
|
standard's goal is to serve as a complete definition of external
|
|
interfaces so that application code that conforms to these
|
|
interfaces will execute properly in all real-time executive
|
|
environments. With the use of a standards compliant executive,
|
|
routines that acquire memory blocks, create and manage message
|
|
queues, establish and use semaphores, and send and receive
|
|
signals need not be redeveloped for a different real-time
|
|
environment as long as the new environment is compliant with the
|
|
standard. Software developers need only concentrate on the
|
|
hardware dependencies of the real-time system. Furthermore,
|
|
most hardware dependencies for real-time applications can be
|
|
localized to the device drivers.
|
|
|
|
A compliant executive provides simple and flexible
|
|
real-time multiprocessing. It easily lends itself to both
|
|
tightly-coupled and loosely-coupled configurations (depending on
|
|
the system hardware configuration). Objects such as tasks,
|
|
queues, events, signals, semaphores, and memory blocks can be
|
|
designated as global objects and accessed by any task regardless
|
|
of which processor the object and the accessing task reside.
|
|
|
|
The acceptance of a standard for real-time executives
|
|
will produce the same advantages enjoyed from the push for UNIX
|
|
standardization by AT&T's System V Interface Definition and
|
|
IEEE's POSIX efforts. A compliant multiprocessing executive
|
|
will allow close coupling between UNIX systems and real-time
|
|
executives to provide the many benefits of the UNIX development
|
|
environment to be applied to real-time software development.
|
|
Together they provide the necessary laboratory environment to
|
|
implement real-time, distributed, embedded systems using a wide
|
|
variety of computer architectures.
|
|
|
|
A study was completed in 1988, within the Research,
|
|
Development, and Engineering Center, U.S. Army Missile Command,
|
|
which compared the various aspects of the Ada programming
|
|
language as they related to the application of Ada code in
|
|
distributed and/or multiple processing systems. Several
|
|
critical conclusions were derived from the study. These
|
|
conclusions have a major impact on the way the Army develops
|
|
application software for embedded applications. These impacts
|
|
apply to both in-house software development and contractor
|
|
developed software.
|
|
|
|
A conclusion of the analysis, which has been
|
|
previously recognized by other agencies attempting to utilize
|
|
Ada in a distributed or multiprocessing environment, is that the
|
|
Ada programming language does not adequately support
|
|
multiprocessing. Ada does provide a mechanism for
|
|
multi-tasking, however, this capability exists only for a single
|
|
processor system. The language also does not have inherent
|
|
capabilities to access global named variables, flags or program
|
|
code. These critical features are essential in order for data
|
|
to be shared between processors. However, these drawbacks do
|
|
have workarounds which are sometimes awkward and defeat the
|
|
intent of software maintainability and portability goals.
|
|
|
|
Another conclusion drawn from the analysis, was that
|
|
the run time executives being delivered with the Ada compilers
|
|
were too slow and inefficient to be used in modern missile
|
|
systems. A run time executive is the core part of the run time
|
|
system code, or operating system code, that controls task
|
|
scheduling, input/output management and memory management.
|
|
Traditionally, whenever efficient executive (also known as
|
|
kernel) code was required by the application, the user developed
|
|
in-house software. This software was usually written in
|
|
assembly language for optimization.
|
|
|
|
Because of this shortcoming in the Ada programming
|
|
language, software developers in research and development and
|
|
contractors for project managed systems, are mandated by
|
|
technology to purchase and utilize off-the-shelf third party
|
|
kernel code. The contractor, and eventually the Government,
|
|
must pay a licensing fee for every copy of the kernel code used
|
|
in an embedded system.
|
|
|
|
The main drawback to this development environment is
|
|
that the Government does not own, nor has the right to modify
|
|
code contained within the kernel. V&V techniques in this
|
|
situation are more difficult than if the complete source code
|
|
were available. Responsibility for system failures due to faulty
|
|
software is yet another area to be resolved under this
|
|
environment.
|
|
|
|
The Guidance and Control Directorate began a software
|
|
development effort to address these problems. A project to
|
|
develop an experimental run time kernel was begun that will
|
|
eliminate the major drawbacks of the Ada programming language
|
|
mentioned above. The Real Time Executive for Multiprocessor Systems
|
|
(RTEMS) provides full capabilities for management of tasks,
|
|
interrupts, time, and multiple processors in addition to those
|
|
features typical of generic operating systems. The code is
|
|
Government owned, so no licensing fees are necessary. RTEMS has
|
|
been implemented in both the Ada and C programming languages.
|
|
It has been ported to the following processor families:
|
|
|
|
@itemize @bullet
|
|
@item Intel i80386 and above
|
|
@item Intel i80960
|
|
@item Motorola MC68xxx
|
|
@item Motorola MC683xx
|
|
@item MIPS
|
|
@item PowerPC
|
|
@item SPARC
|
|
@item Hewlett Packard PA-RISC
|
|
@item Hitachi SH
|
|
@item AMD A29K
|
|
@item UNIX
|
|
@end itemize
|
|
|
|
Support for other processor families, including RISC, CISC, and DSP, is
|
|
planned. Since almost all of RTEMS is written in a high level language,
|
|
ports to additional processor families require minimal effort.
|
|
|
|
RTEMS multiprocessor support is capable of handling
|
|
either homogeneous or heterogeneous systems. The kernel
|
|
automatically compensates for architectural differences (byte
|
|
swapping, etc.) between processors. This allows a much easier
|
|
transition from one processor family to another without a major
|
|
system redesign.
|
|
|
|
Since the proposed standards are still in draft form,
|
|
RTEMS cannot and does not claim compliance. However, the status
|
|
of the standard is being carefully monitored to guarantee that
|
|
RTEMS provides the functionality specified in the standard.
|
|
Once approved, RTEMS will be made compliant.
|
|
|
|
This document is a detailed users guide for a
|
|
functionally compliant real-time multiprocessor executive. It
|
|
describes the user interface and run-time behavior of Release
|
|
@value{VERSION} of the @value{LANGUAGE} interface
|
|
to RTEMS.
|
|
|