1 |
1026 |
ivang |
@c
|
2 |
|
|
@c COPYRIGHT (c) 1988-2002.
|
3 |
|
|
@c On-Line Applications Research Corporation (OAR).
|
4 |
|
|
@c All rights reserved.
|
5 |
|
|
@c
|
6 |
|
|
@c preface.texi,v 1.11 2002/01/17 21:47:47 joel Exp
|
7 |
|
|
@c
|
8 |
|
|
|
9 |
|
|
@ifinfo
|
10 |
|
|
@node Preface, Overview, Top, Top
|
11 |
|
|
@end ifinfo
|
12 |
|
|
@unnumbered Preface
|
13 |
|
|
|
14 |
|
|
In recent years, the cost required to develop a
|
15 |
|
|
software product has increased significantly while the target
|
16 |
|
|
hardware costs have decreased. Now a larger portion of money is
|
17 |
|
|
expended in developing, using, and maintaining software. The
|
18 |
|
|
trend in computing costs is the complete dominance of software
|
19 |
|
|
over hardware costs. Because of this, it is necessary that
|
20 |
|
|
formal disciplines be established to increase the probability
|
21 |
|
|
that software is characterized by a high degree of correctness,
|
22 |
|
|
maintainability, and portability. In addition, these
|
23 |
|
|
disciplines must promote practices that aid in the consistent
|
24 |
|
|
and orderly development of a software system within schedule and
|
25 |
|
|
budgetary constraints. To be effective, these disciplines must
|
26 |
|
|
adopt standards which channel individual software efforts toward
|
27 |
|
|
a common goal.
|
28 |
|
|
|
29 |
|
|
The push for standards in the software development
|
30 |
|
|
field has been met with various degrees of success. The
|
31 |
|
|
Microprocessor Operating Systems Interfaces (MOSI) effort has
|
32 |
|
|
experienced only limited success. As popular as the UNIX
|
33 |
|
|
operating system has grown, the attempt to develop a standard
|
34 |
|
|
interface definition to allow portable application development
|
35 |
|
|
has only recently begun to produce the results needed in this
|
36 |
|
|
area. Unfortunately, very little effort has been expended to
|
37 |
|
|
provide standards addressing the needs of the real-time
|
38 |
|
|
community. Several organizations have addressed this need
|
39 |
|
|
during recent years.
|
40 |
|
|
|
41 |
|
|
The Real Time Executive Interface Definition (RTEID)
|
42 |
|
|
was developed by Motorola with technical input from Software
|
43 |
|
|
Components Group. RTEID was adopted by the VMEbus International
|
44 |
|
|
Trade Association (VITA) as a baseline draft for their proposed
|
45 |
|
|
standard multiprocessor, real-time executive interface, Open
|
46 |
|
|
Real-Time Kernel Interface Definition (ORKID). These two groups
|
47 |
|
|
are currently working together with the IEEE P1003.4 committee
|
48 |
|
|
to insure that the functionality of their proposed standards is
|
49 |
|
|
adopted as the real-time extensions to POSIX.
|
50 |
|
|
|
51 |
|
|
This emerging standard defines an interface for the
|
52 |
|
|
development of real-time software to ease the writing of
|
53 |
|
|
real-time application programs that are directly portable across
|
54 |
|
|
multiple real-time executive implementations. This interface
|
55 |
|
|
includes both the source code interfaces and run-time behavior
|
56 |
|
|
as seen by a real-time application. It does not include the
|
57 |
|
|
details of how a kernel implements these functions. The
|
58 |
|
|
standard's goal is to serve as a complete definition of external
|
59 |
|
|
interfaces so that application code that conforms to these
|
60 |
|
|
interfaces will execute properly in all real-time executive
|
61 |
|
|
environments. With the use of a standards compliant executive,
|
62 |
|
|
routines that acquire memory blocks, create and manage message
|
63 |
|
|
queues, establish and use semaphores, and send and receive
|
64 |
|
|
signals need not be redeveloped for a different real-time
|
65 |
|
|
environment as long as the new environment is compliant with the
|
66 |
|
|
standard. Software developers need only concentrate on the
|
67 |
|
|
hardware dependencies of the real-time system. Furthermore,
|
68 |
|
|
most hardware dependencies for real-time applications can be
|
69 |
|
|
localized to the device drivers.
|
70 |
|
|
|
71 |
|
|
A compliant executive provides simple and flexible
|
72 |
|
|
real-time multiprocessing. It easily lends itself to both
|
73 |
|
|
tightly-coupled and loosely-coupled configurations (depending on
|
74 |
|
|
the system hardware configuration). Objects such as tasks,
|
75 |
|
|
queues, events, signals, semaphores, and memory blocks can be
|
76 |
|
|
designated as global objects and accessed by any task regardless
|
77 |
|
|
of which processor the object and the accessing task reside.
|
78 |
|
|
|
79 |
|
|
The acceptance of a standard for real-time executives
|
80 |
|
|
will produce the same advantages enjoyed from the push for UNIX
|
81 |
|
|
standardization by AT&T's System V Interface Definition and
|
82 |
|
|
IEEE's POSIX efforts. A compliant multiprocessing executive
|
83 |
|
|
will allow close coupling between UNIX systems and real-time
|
84 |
|
|
executives to provide the many benefits of the UNIX development
|
85 |
|
|
environment to be applied to real-time software development.
|
86 |
|
|
Together they provide the necessary laboratory environment to
|
87 |
|
|
implement real-time, distributed, embedded systems using a wide
|
88 |
|
|
variety of computer architectures.
|
89 |
|
|
|
90 |
|
|
A study was completed in 1988, within the Research,
|
91 |
|
|
Development, and Engineering Center, U.S. Army Missile Command,
|
92 |
|
|
which compared the various aspects of the Ada programming
|
93 |
|
|
language as they related to the application of Ada code in
|
94 |
|
|
distributed and/or multiple processing systems. Several
|
95 |
|
|
critical conclusions were derived from the study. These
|
96 |
|
|
conclusions have a major impact on the way the Army develops
|
97 |
|
|
application software for embedded applications. These impacts
|
98 |
|
|
apply to both in-house software development and contractor
|
99 |
|
|
developed software.
|
100 |
|
|
|
101 |
|
|
A conclusion of the analysis, which has been
|
102 |
|
|
previously recognized by other agencies attempting to utilize
|
103 |
|
|
Ada in a distributed or multiprocessing environment, is that the
|
104 |
|
|
Ada programming language does not adequately support
|
105 |
|
|
multiprocessing. Ada does provide a mechanism for
|
106 |
|
|
multi-tasking, however, this capability exists only for a single
|
107 |
|
|
processor system. The language also does not have inherent
|
108 |
|
|
capabilities to access global named variables, flags or program
|
109 |
|
|
code. These critical features are essential in order for data
|
110 |
|
|
to be shared between processors. However, these drawbacks do
|
111 |
|
|
have workarounds which are sometimes awkward and defeat the
|
112 |
|
|
intent of software maintainability and portability goals.
|
113 |
|
|
|
114 |
|
|
Another conclusion drawn from the analysis, was that
|
115 |
|
|
the run time executives being delivered with the Ada compilers
|
116 |
|
|
were too slow and inefficient to be used in modern missile
|
117 |
|
|
systems. A run time executive is the core part of the run time
|
118 |
|
|
system code, or operating system code, that controls task
|
119 |
|
|
scheduling, input/output management and memory management.
|
120 |
|
|
Traditionally, whenever efficient executive (also known as
|
121 |
|
|
kernel) code was required by the application, the user developed
|
122 |
|
|
in-house software. This software was usually written in
|
123 |
|
|
assembly language for optimization.
|
124 |
|
|
|
125 |
|
|
Because of this shortcoming in the Ada programming
|
126 |
|
|
language, software developers in research and development and
|
127 |
|
|
contractors for project managed systems, are mandated by
|
128 |
|
|
technology to purchase and utilize off-the-shelf third party
|
129 |
|
|
kernel code. The contractor, and eventually the Government,
|
130 |
|
|
must pay a licensing fee for every copy of the kernel code used
|
131 |
|
|
in an embedded system.
|
132 |
|
|
|
133 |
|
|
The main drawback to this development environment is
|
134 |
|
|
that the Government does not own, nor has the right to modify
|
135 |
|
|
code contained within the kernel. V&V techniques in this
|
136 |
|
|
situation are more difficult than if the complete source code
|
137 |
|
|
were available. Responsibility for system failures due to faulty
|
138 |
|
|
software is yet another area to be resolved under this
|
139 |
|
|
environment.
|
140 |
|
|
|
141 |
|
|
The Guidance and Control Directorate began a software
|
142 |
|
|
development effort to address these problems. A project to
|
143 |
|
|
develop an experimental run time kernel was begun that will
|
144 |
|
|
eliminate the major drawbacks of the Ada programming language
|
145 |
|
|
mentioned above. The Real Time Executive for Multiprocessor Systems
|
146 |
|
|
(RTEMS) provides full capabilities for management of tasks,
|
147 |
|
|
interrupts, time, and multiple processors in addition to those
|
148 |
|
|
features typical of generic operating systems. The code is
|
149 |
|
|
Government owned, so no licensing fees are necessary. RTEMS has
|
150 |
|
|
been implemented in both the Ada and C programming languages.
|
151 |
|
|
It has been ported to the following processor families:
|
152 |
|
|
|
153 |
|
|
@itemize @bullet
|
154 |
|
|
@item Intel i80386 and above
|
155 |
|
|
@item Intel i80960
|
156 |
|
|
@item Motorola MC68xxx
|
157 |
|
|
@item Motorola MC683xx
|
158 |
|
|
@item MIPS
|
159 |
|
|
@item PowerPC
|
160 |
|
|
@item SPARC
|
161 |
|
|
@item Hewlett Packard PA-RISC
|
162 |
|
|
@item Hitachi SH
|
163 |
|
|
@item AMD A29K
|
164 |
|
|
@item UNIX
|
165 |
|
|
@end itemize
|
166 |
|
|
|
167 |
|
|
Support for other processor families, including RISC, CISC, and DSP, is
|
168 |
|
|
planned. Since almost all of RTEMS is written in a high level language,
|
169 |
|
|
ports to additional processor families require minimal effort.
|
170 |
|
|
|
171 |
|
|
RTEMS multiprocessor support is capable of handling
|
172 |
|
|
either homogeneous or heterogeneous systems. The kernel
|
173 |
|
|
automatically compensates for architectural differences (byte
|
174 |
|
|
swapping, etc.) between processors. This allows a much easier
|
175 |
|
|
transition from one processor family to another without a major
|
176 |
|
|
system redesign.
|
177 |
|
|
|
178 |
|
|
Since the proposed standards are still in draft form,
|
179 |
|
|
RTEMS cannot and does not claim compliance. However, the status
|
180 |
|
|
of the standard is being carefully monitored to guarantee that
|
181 |
|
|
RTEMS provides the functionality specified in the standard.
|
182 |
|
|
Once approved, RTEMS will be made compliant.
|
183 |
|
|
|
184 |
|
|
This document is a detailed users guide for a
|
185 |
|
|
functionally compliant real-time multiprocessor executive. It
|
186 |
|
|
describes the user interface and run-time behavior of Release
|
187 |
|
|
@value{VERSION} of the @value{LANGUAGE} interface
|
188 |
|
|
to RTEMS.
|
189 |
|
|
|