OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [rtems-20020807/] [doc/] [user/] [preface.texi] - Blame information for rev 1771

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
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
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.