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

4.104.115
Last change on this file since c8c466e was c8c466e, checked in by Joel Sherrill <joel.sherrill@…>, on Oct 14, 2009 at 3:29:55 PM

2009-10-14 Joel Sherrill <joel.sherrill@…>

  • user/preface.texi: Remove UNIX and update port list.
  • Property mode set to 100644
File size: 8.9 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 Altera NIOS II
155@item Analog Devices Blackfin
156@item Atmel AVR
157@item ARM
158@item Freescale (formerly Motorola) MC68xxx
159@item Freescale (formerly Motorola) MC683xx
160@item Freescale (formerly Motorola) ColdFire
161@item Intel i386 and above
162@item Lattice Semiconductor LM32
163@item MIPS
164@item PowerPC
165@item Renesas (formerly Hitachi) SuperH
166@item Renesas (formerly Hitachi) H8/300
167@item Renesas M32C
168@item Renesas M32R
169@item SPARC
170@item Texas Instruments C3x/C4x
171@end itemize
172
173Support for other processor families, including RISC, CISC, and DSP, is
174planned.  Since almost all of RTEMS is written in a high level language,
175ports to additional processor families require minimal effort.
176
177RTEMS multiprocessor support is capable of handling
178either homogeneous or heterogeneous systems.  The kernel
179automatically compensates for architectural differences (byte
180swapping, etc.) between processors.  This allows a much easier
181transition from one processor family to another without a major
182system redesign.
183
184Since the proposed standards are still in draft form,
185RTEMS cannot and does not claim compliance.  However, the status
186of the standard is being carefully monitored to guarantee that
187RTEMS provides the functionality specified in the standard.
188Once approved, RTEMS will be made compliant.
189
190This document is a detailed users guide for a
191functionally compliant real-time multiprocessor executive.  It
192describes the user interface and run-time behavior of Release
193@value{VERSION} of the @value{LANGUAGE} interface
194to RTEMS.
195
Note: See TracBrowser for help on using the repository browser.