source: rtems/doc/user/preface.texi @ 8197135

4.104.114.84.95
Last change on this file since 8197135 was 8197135, checked in by Joel Sherrill <joel.sherrill@…>, on Sep 29, 2004 at 8:22:30 PM

2004-09-29 Joel Sherrill <joel@…>

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