source: rtems/doc/user/overview.t @ 1fa78236

Last change on this file since 1fa78236 was 1fa78236, checked in by Joel Sherrill <joel.sherrill@…>, on Nov 7, 2008 at 3:02:55 PM

2008-11-07 Joel Sherrill <joel.sherrill@…>

PR 1334/doc

  • user/, user/concepts.t, user/init.t, user/overview.t, user/part.t, user/task.t: Correct typos and correctly document 4 parts of 32-bit object id.
  • user/ObjectId-32Bits.eps, user/ObjectId-32Bits.png: New files.
  • Property mode set to 100644
File size: 18.9 KB
2@c  COPYRIGHT (c) 1988-2008.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
6@c  $Id$
10@c  This chapter is missing the following figures:
12@c     Figure 1-1  RTEMS Application Architecture
13@c     Figure 1-2  RTEMS Internal Architecture
16@chapter Overview
18@section Introduction
20RTEMS, Real-Time Executive for Multiprocessor Systems, is a
21real-time executive (kernel) which provides a high performance
22environment for embedded military applications including the
23following features:
25@itemize @bullet
26@item multitasking capabilities
27@item homogeneous and heterogeneous multiprocessor systems
28@item event-driven, priority-based, preemptive scheduling
29@item optional rate monotonic scheduling
30@item intertask communication and synchronization
31@item priority inheritance
32@item responsive interrupt management
33@item dynamic memory allocation
34@item high level of user configurability
35@end itemize
37This manual describes the usage of RTEMS for
38applications written in the @value{LANGUAGE} programming language.  Those
39implementation details that are processor dependent are provided
40in the Applications Supplement documents.  A supplement
41document which addresses specific architectural issues that
42affect RTEMS is provided for each processor type that is
45@section Real-time Application Systems
47Real-time application systems are a special class of
48computer applications.  They have a complex set of
49characteristics that distinguish them from other software
50problems.  Generally, they must adhere to more rigorous
51requirements.  The correctness of the system depends not only on
52the results of computations, but also on the time at which the
53results are produced.  The most important and complex
54characteristic of real-time application systems is that they
55must receive and respond to a set of external stimuli within
56rigid and critical time constraints referred to as deadlines.
57Systems can be buried by an avalanche of interdependent,
58asynchronous or cyclical event streams.
60Deadlines can be further characterized as either hard
61or soft based upon the value of the results when produced after
62the deadline has passed.  A deadline is hard if the results have
63no value or if their use will result in a catastrophic event.
64In contrast, results which are produced after a soft deadline
65may have some value.
67Another distinguishing requirement of real-time
68application systems is the ability to coordinate or manage a
69large number of concurrent activities. Since software is a
70synchronous entity, this presents special problems.  One
71instruction follows another in a repeating synchronous cycle.
72Even though mechanisms have been developed to allow for the
73processing of external asynchronous events, the software design
74efforts required to process and manage these events and tasks
75are growing more complicated.
77The design process is complicated further by
78spreading this activity over a set of processors instead of a
79single processor. The challenges associated with designing and
80building real-time application systems become very complex when
81multiple processors are involved.  New requirements such as
82interprocessor communication channels and global resources that
83must be shared between competing processors are introduced.  The
84ramifications of multiple processors complicate each and every
85characteristic of a real-time system.
87@section Real-time Executive
89Fortunately, real-time operating systems or real-time
90executives serve as a cornerstone on which to build the
91application system.  A real-time multitasking executive allows
92an application to be cast into a set of logical, autonomous
93processes or tasks which become quite manageable.  Each task is
94internally synchronous, but different tasks execute
95independently, resulting in an asynchronous processing stream.
96Tasks can be dynamically paused for many reasons resulting in a
97different task being allowed to execute for a period of time.
98The executive also provides an interface to other system
99components such as interrupt handlers and device drivers.
100System components may request the executive to allocate and
101coordinate resources, and to wait for and trigger synchronizing
102conditions.  The executive system calls effectively extend the
103CPU instruction set to support efficient multitasking.  By
104causing tasks to travel through well-defined state transitions,
105system calls permit an application to demand-switch between
106tasks in response to real-time events.
108By proper grouping of responses to stimuli into
109separate tasks, a system can now asynchronously switch between
110independent streams of execution, directly responding to
111external stimuli as they occur.  This allows the system design
112to meet critical performance specifications which are typically
113measured by guaranteed response time and transaction throughput.
114The multiprocessor extensions of RTEMS provide the features
115necessary to manage the extra requirements introduced by a
116system distributed across several processors.  It removes the
117physical barriers of processor boundaries from the world of the
118system designer, enabling more critical aspects of the system to
119receive the required attention. Such a system, based on an
120efficient real-time, multiprocessor executive, is a more
121realistic model of the outside world or environment for which it
122is designed.  As a result, the system will always be more
123logical, efficient, and reliable.
125By using the directives provided by RTEMS, the
126real-time applications developer is freed from the problem of
127controlling and synchronizing multiple tasks and processors.  In
128addition, one need not develop, test, debug, and document
129routines to manage memory, pass messages, or provide mutual
130exclusion.  The developer is then able to concentrate solely on
131the application.  By using standard software components, the
132time and cost required to develop sophisticated real-time
133applications is significantly reduced.
135@section RTEMS Application Architecture
137One important design goal of RTEMS was to provide a
138bridge between two critical layers of typical real-time systems.
139As shown in the following figure, RTEMS serves as a buffer between the
140project dependent application code and the target hardware.
141Most hardware dependencies for real-time applications can be
142localized to the low level device drivers.
144@ifset use-ascii
147      +-----------------------------------------------------------+
148      |             Application Dependent Software                |
149      |        +----------------------------------------+         |
150      |        |    Standard Application Components     |         |
151      |        |                          +-------------+---+     |
152      |    +---+-----------+              |                 |     |
153      |    | Board Support |              |      RTEMS      |     |
154      |    |    Package    |              |                 |     |
155      +----+---------------+--------------+-----------------+-----|
156      |                      Target Hardware                      |
157      +-----------------------------------------------------------+
158@end group
159@end example
160@end ifset
162@ifset use-tex
163@sp 1
167\hbox to 0.50in{\enskip\hfil#\hfil}&
169\hbox to 0.50in{\enskip\hfil#\hfil}&
171\hbox to 0.75in{\enskip\hfil#\hfil}&
173\hbox to 0.75in{\enskip\hfil#\hfil}&
175\hbox to 0.75in{\enskip\hfil#\hfil}&
177\hbox to 0.75in{\enskip\hfil#\hfil}&
179\hbox to 0.50in{\enskip\hfil#\hfil}&
181\hbox to 0.50in{\enskip\hfil#\hfil}&
184% to force all columns to desired width
185& \enskip && \enskip && \enskip && \enskip &&
186    \enskip && \enskip &&\enskip &&\enskip &\cr
187% For debugging columns
188%& \enskip 0&& \enskip 1&& \enskip 2&& \enskip 3&&
189%    \enskip 4&& \enskip 5&&\enskip 6&&\enskip 7&\cr
191&\multispan{15}\hfil Application Dependent Software\hfil&\cr
193&\multispan{2}&&\multispan{8}\hrulefill &\multispan{2}&\cr
195&\multispan{2}&&&\multispan{7}\hfil Standard Application Components\hfil&
196    &\multispan{2}&&\cr
199\strut&&&\multispan{3}                  &&&&\multispan{5}&&&\cr
200&&&\multispan{3}\hfil Device\hfil&&&&\multispan{5}\hfil RTEMS\hfil&&&\cr
201&&&\multispan{3}\hfil Drivers\hfil&&&&\multispan{5}&&&\cr
202\strut&&&\multispan{3}                  &&&&\multispan{5}&&&\cr
205&\multispan{15}\hfil Target Hardware\hfil&\cr
209@end tex
210@end ifset
212@ifset use-html
214<IMG SRC="rtemsarc.png" WIDTH=500 HEIGHT=300 ALT="RTEMS Application Architecture">
215@end html
216@end ifset
218The RTEMS I/O interface manager provides an efficient tool for incorporating
219these hardware dependencies into the system while simultaneously
220providing a general mechanism to the application code that
221accesses them.  A well designed real-time system can benefit
222from this architecture by building a rich library of standard
223application components which can be used repeatedly in other
224real-time projects.
226@section RTEMS Internal Architecture
228RTEMS can be viewed as a set of layered components that work in
229harmony to provide a set of services to a real-time application
230system.  The executive interface presented to the application is
231formed by grouping directives into logical sets called resource managers.
232Functions utilized by multiple managers such as scheduling,
233dispatching, and object management are provided in the executive
234core.  The executive core depends on a small set of CPU dependent routines.
235Together these components provide a powerful run time
236environment that promotes the development of efficient real-time
237application systems.  The following figure illustrates this organization:
239@ifset use-ascii
242           +-----------------------------------------------+
243           |          RTEMS Executive Interface            |
244           +-----------------------------------------------+
245           |                 RTEMS Core                    |
246           +-----------------------------------------------+
247           |              CPU Dependent Code               |
248           +-----------------------------------------------+
249@end group
250@end example
251@end ifset
253@ifset use-tex
254@c for now use the ascii version
255@c @example
256@c @group
257@c            +-----------------------------------------------+
258@c            |          RTEMS Executive Interface            |
259@c            +-----------------------------------------------+
260@c            |                 RTEMS Core                    |
261@c            +-----------------------------------------------+
262@c            |              CPU Dependent Code               |
263@c            +-----------------------------------------------+
264@c @end group
265@c @end example
268@end tex
269@end ifset
271@ifset use-html
273<IMG SRC="rtemspie.png" WIDTH=500 HEIGHT=300 ALT="RTEMS Architecture">
274@end html
275@end ifset
276Subsequent chapters present a detailed description of the capabilities
277provided by each of the following RTEMS managers:
279@itemize @bullet
280@item initialization
281@item task
282@item interrupt
283@item clock
284@item timer
285@item semaphore
286@item message
287@item event
288@item signal
289@item partition
290@item region
291@item dual ported memory
292@item I/O
293@item fatal error
294@item rate monotonic
295@item user extensions
296@item multiprocessing
297@end itemize
299@section User Customization and Extensibility
301As thirty-two bit microprocessors have decreased in
302cost, they have become increasingly common in a variety of
303embedded systems.  A wide range of custom and general-purpose
304processor boards are based on various thirty-two bit processors.
305RTEMS was designed to make no assumptions concerning the
306characteristics of individual microprocessor families or of
307specific support hardware.  In addition, RTEMS allows the system
308developer a high degree of freedom in customizing and extending
309its features.
311RTEMS assumes the existence of a supported
312microprocessor and sufficient memory for both RTEMS and the
313real-time application.  Board dependent components such as
314clocks, interrupt controllers, or I/O devices can be easily
315integrated with RTEMS.  The customization and extensibility
316features allow RTEMS to efficiently support as many environments
317as possible.
319@section Portability
321The issue of portability was the major factor in the
322creation of RTEMS.  Since RTEMS is designed to isolate the
323hardware dependencies in the specific board support packages,
324the real-time application should be easily ported to any other
325processor.  The use of RTEMS allows the development of real-time
326applications which can be completely independent of a particular
327microprocessor architecture.
329@section Memory Requirements
331Since memory is a critical resource in many real-time
332embedded systems, RTEMS was specifically designed to automatically
333leave out all services that are not required from the run-time
334environment.  Features such as networking, various fileystems,
335and many other features are completely optional.  This allows
336the application designer the flexibility to tailor RTEMS to most
337efficiently meet system requirements while still satisfying even
338the most stringent memory constraints.  As a result, the size
339of the RTEMS executive is application dependent.
341RTEMS requires RAM to manage each instance of an RTEMS object
342that is created.  Thus the more RTEMS objects an application
343needs, the more memory that must be reserved.  See
344@ref{Configuring a System Determining Memory Requirements} for
345more details.
347RTEMS utilizes memory for both code and data space.
348Although RTEMS' data space must be in RAM, its code space can be
349located in either ROM or RAM.
351@section Audience
353This manual was written for experienced real-time
354software developers.  Although some background is provided, it
355is assumed that the reader is familiar with the concepts of task
356management as well as intertask communication and
357synchronization.  Since directives, user related data
358structures, and examples are presented in @value{LANGUAGE}, a basic
359understanding of the @value{LANGUAGE} programming language
360is required to fully
361understand the material presented.  However, because of the
362similarity of the Ada and C RTEMS implementations, users will
363find that the use and behavior of the two implementations is
364very similar.  A working knowledge of the target processor is
365helpful in understanding some of RTEMS' features.  A thorough
366understanding of the executive cannot be obtained without
367studying the entire manual because many of RTEMS' concepts and
368features are interrelated.  Experienced RTEMS users will find
369that the manual organization facilitates its use as a reference
372@section Conventions
374The following conventions are used in this manual:
376@itemize @bullet
377@item Significant words or phrases as well as all directive
378names are printed in bold type.
380@item Items in bold capital letters are constants defined by
381RTEMS.  Each language interface provided by RTEMS includes a
382file containing the standard set of constants, data types, and
383@value{STRUCTURE} definitions which can be incorporated into the user
386@item A number of type definitions are provided by RTEMS and
387can be found in rtems.h.
389@item The characters "0x" preceding a number indicates that
390the number is in hexadecimal format.  Any other numbers are
391assumed to be in decimal format.
392@end itemize
394@section Manual Organization
396This first chapter has presented the introductory and
397background material for the RTEMS executive.  The remaining
398chapters of this manual present a detailed description of RTEMS
399and the environment, including run time behavior, it creates for
400the user.
402A chapter is dedicated to each manager and provides a
403detailed discussion of each RTEMS manager and the directives
404which it provides.  The presentation format for each directive
405includes the following sections:
407@itemize @bullet
408@item Calling sequence
409@item Directive status codes
410@item Description
411@item Notes
412@end itemize
414The following provides an overview of the remainder
415of this manual:
417@table @asis
418@item Chapter 2
419Key Concepts: presents an
420introduction to the ideas which are common across multiple RTEMS
423@item Chapter 3:
424RTEMS Data Types: describes the fundamental data types shared
425by the services in the RTEMS Classic API.
427@item Chapter 4:
428Initialization Manager: describes the functionality and directives
429provided by the Initialization Manager.
431@item Chapter 5:
432Task Manager: describes the functionality and directives provided
433by the Task Manager.
435@item Chapter 6:
436Interrupt Manager: describes the functionality and directives
437provided by the Interrupt Manager.
439@item Chapter 7:
440Clock Manager: describes the functionality and directives
441provided by the Clock Manager.
443@item Chapter 8:
444Timer Manager: describes the functionality and directives provided
445by the Timer Manager.
447@item Chapter 9:
448Semaphore Manager: describes the functionality and directives
449provided by the Semaphore Manager.
451@item Chapter 10:
452Message Manager: describes the functionality and directives
453provided by the Message Manager.
455@item Chapter 11:
456Event Manager: describes the
457functionality and directives provided by the Event Manager.
459@item Chapter 12:
460Signal Manager: describes the
461functionality and directives provided by the Signal Manager.
463@item Chapter 13:
464Partition Manager: describes the
465functionality and directives provided by the Partition Manager.
467@item Chapter 14:
468Region Manager: describes the
469functionality and directives provided by the Region Manager.
471@item Chapter 15:
472Dual-Ported Memory Manager: describes
473the functionality and directives provided by the Dual-Ported
474Memory Manager.
476@item Chapter 16:
477I/O Manager: describes the
478functionality and directives provided by the I/O Manager.
480@item Chapter 17:
481Fatal Error Manager: describes the functionality and directives
482provided by the Fatal Error Manager.
484@item Chapter 18:
485Scheduling Concepts: details the RTEMS scheduling algorithm and
486task state transitions.
488@item Chapter 19:
489Rate Monotonic Manager: describes the functionality and directives
490provided by the Rate Monotonic Manager.
492@item Chapter 20:
493Board Support Packages: defines the
494functionality required of user-supplied board support packages.
496@item Chapter 21:
497User Extensions: shows the user how to
498extend RTEMS to incorporate custom features.
500@item Chapter 22:
501Configuring a System: details the process by which one tailors RTEMS
502for a particular single-processor or multiprocessor application.
504@item Chapter 23:
505Multiprocessing Manager: presents a
506conceptual overview of the multiprocessing capabilities provided
507by RTEMS as well as describing the Multiprocessing
508Communications Interface Layer and Multiprocessing Manager
511@item Chapter 24:
512Directive Status Codes: provides a definition of each of the
513directive status codes referenced in this manual.
515@item Chapter 25:
516Example Application: provides a template for simple RTEMS applications.
518@item Chapter 26:
519Glossary: defines terms used throughout this manual.
521@end table
Note: See TracBrowser for help on using the repository browser.