source: rtems/doc/user/overview.t @ bd861cc6

Last change on this file since bd861cc6 was bd861cc6, checked in by Joel Sherrill <joel.sherrill@…>, on Nov 9, 2009 at 2:36:14 PM

2009-11-09 Joel Sherrill <joel.sherrill@…>

  • ada_user/, ada_user/ada_user.texi, user/, user/c_user.texi, user/concepts.t, user/overview.t, user/preface.texi, user/schedule.t, user/sem.t: Add table of figures. Add text and graphic of tree illustrating valid combinations of semaphore attributes.
  • user/semaphore_attributes.eps, user/semaphore_attributes.png: New files.
  • Property mode set to 100644
File size: 18.6 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@float Figure,fig:RTEMS-App-Arch
145@caption{RTEMS Application Architecture}
147@ifset use-ascii
150      +-----------------------------------------------------------+
151      |             Application Dependent Software                |
152      |        +----------------------------------------+         |
153      |        |    Standard Application Components     |         |
154      |        |                          +-------------+---+     |
155      |    +---+-----------+              |                 |     |
156      |    | Board Support |              |      RTEMS      |     |
157      |    |    Package    |              |                 |     |
158      +----+---------------+--------------+-----------------+-----|
159      |                      Target Hardware                      |
160      +-----------------------------------------------------------+
161@end group
162@end example
163@end ifset
165@ifset use-tex
166@sp 1
170\hbox to 0.50in{\enskip\hfil#\hfil}&
172\hbox to 0.50in{\enskip\hfil#\hfil}&
174\hbox to 0.75in{\enskip\hfil#\hfil}&
176\hbox to 0.75in{\enskip\hfil#\hfil}&
178\hbox to 0.75in{\enskip\hfil#\hfil}&
180\hbox to 0.75in{\enskip\hfil#\hfil}&
182\hbox to 0.50in{\enskip\hfil#\hfil}&
184\hbox to 0.50in{\enskip\hfil#\hfil}&
187% to force all columns to desired width
188& \enskip && \enskip && \enskip && \enskip &&
189    \enskip && \enskip &&\enskip &&\enskip &\cr
190% For debugging columns
191%& \enskip 0&& \enskip 1&& \enskip 2&& \enskip 3&&
192%    \enskip 4&& \enskip 5&&\enskip 6&&\enskip 7&\cr
194&\multispan{15}\hfil Application Dependent Software\hfil&\cr
196&\multispan{2}&&\multispan{8}\hrulefill &\multispan{2}&\cr
198&\multispan{2}&&&\multispan{7}\hfil Standard Application Components\hfil&
199    &\multispan{2}&&\cr
202\strut&&&\multispan{3}                  &&&&\multispan{5}&&&\cr
203&&&\multispan{3}\hfil Device\hfil&&&&\multispan{5}\hfil RTEMS\hfil&&&\cr
204&&&\multispan{3}\hfil Drivers\hfil&&&&\multispan{5}&&&\cr
205\strut&&&\multispan{3}                  &&&&\multispan{5}&&&\cr
208&\multispan{15}\hfil Target Hardware\hfil&\cr
212@end tex
213@end ifset
215@ifset use-html
217<IMG SRC="rtemsarc.png" WIDTH=500 HEIGHT=300 ALT="RTEMS Application Architecture">
218@end html
219@end ifset
220@end float
222The RTEMS I/O interface manager provides an efficient tool for incorporating
223these hardware dependencies into the system while simultaneously
224providing a general mechanism to the application code that
225accesses them.  A well designed real-time system can benefit
226from this architecture by building a rich library of standard
227application components which can be used repeatedly in other
228real-time projects.
230@section RTEMS Internal Architecture
232RTEMS can be viewed as a set of layered components that work in
233harmony to provide a set of services to a real-time application
234system.  The executive interface presented to the application is
235formed by grouping directives into logical sets called resource managers.
236Functions utilized by multiple managers such as scheduling,
237dispatching, and object management are provided in the executive
238core.  The executive core depends on a small set of CPU dependent routines.
239Together these components provide a powerful run time
240environment that promotes the development of efficient real-time
241application systems.  The following figure illustrates this organization:
243@float Figure,fig:rtems-layers
244@caption{RTEMS Layered Architecture}
246@ifset use-ascii
249           +-----------------------------------------------+
250           |          RTEMS Executive Interface            |
251           +-----------------------------------------------+
252           |                 RTEMS Core                    |
253           +-----------------------------------------------+
254           |              CPU Dependent Code               |
255           +-----------------------------------------------+
256@end group
257@end example
258@end ifset
260@ifset use-tex
261@center{@image{rtemspie,4in,3in, RTEMS Layered Architecture}}
263@end tex
264@end ifset
266@ifset use-html
268<IMG SRC="rtemspie.png" WIDTH=500 HEIGHT=300 ALT="RTEMS Layered Architecture">
269@end html
270@end ifset
271@end float
273Subsequent chapters present a detailed description of the capabilities
274provided by each of the following RTEMS managers:
276@itemize @bullet
277@item initialization
278@item task
279@item interrupt
280@item clock
281@item timer
282@item semaphore
283@item message
284@item event
285@item signal
286@item partition
287@item region
288@item dual ported memory
289@item I/O
290@item fatal error
291@item rate monotonic
292@item user extensions
293@item multiprocessing
294@end itemize
296@section User Customization and Extensibility
298As thirty-two bit microprocessors have decreased in
299cost, they have become increasingly common in a variety of
300embedded systems.  A wide range of custom and general-purpose
301processor boards are based on various thirty-two bit processors.
302RTEMS was designed to make no assumptions concerning the
303characteristics of individual microprocessor families or of
304specific support hardware.  In addition, RTEMS allows the system
305developer a high degree of freedom in customizing and extending
306its features.
308RTEMS assumes the existence of a supported
309microprocessor and sufficient memory for both RTEMS and the
310real-time application.  Board dependent components such as
311clocks, interrupt controllers, or I/O devices can be easily
312integrated with RTEMS.  The customization and extensibility
313features allow RTEMS to efficiently support as many environments
314as possible.
316@section Portability
318The issue of portability was the major factor in the
319creation of RTEMS.  Since RTEMS is designed to isolate the
320hardware dependencies in the specific board support packages,
321the real-time application should be easily ported to any other
322processor.  The use of RTEMS allows the development of real-time
323applications which can be completely independent of a particular
324microprocessor architecture.
326@section Memory Requirements
328Since memory is a critical resource in many real-time
329embedded systems, RTEMS was specifically designed to automatically
330leave out all services that are not required from the run-time
331environment.  Features such as networking, various fileystems,
332and many other features are completely optional.  This allows
333the application designer the flexibility to tailor RTEMS to most
334efficiently meet system requirements while still satisfying even
335the most stringent memory constraints.  As a result, the size
336of the RTEMS executive is application dependent.
338RTEMS requires RAM to manage each instance of an RTEMS object
339that is created.  Thus the more RTEMS objects an application
340needs, the more memory that must be reserved.  See
341@ref{Configuring a System Determining Memory Requirements} for
342more details.
344RTEMS utilizes memory for both code and data space.
345Although RTEMS' data space must be in RAM, its code space can be
346located in either ROM or RAM.
348@section Audience
350This manual was written for experienced real-time
351software developers.  Although some background is provided, it
352is assumed that the reader is familiar with the concepts of task
353management as well as intertask communication and
354synchronization.  Since directives, user related data
355structures, and examples are presented in @value{LANGUAGE}, a basic
356understanding of the @value{LANGUAGE} programming language
357is required to fully
358understand the material presented.  However, because of the
359similarity of the Ada and C RTEMS implementations, users will
360find that the use and behavior of the two implementations is
361very similar.  A working knowledge of the target processor is
362helpful in understanding some of RTEMS' features.  A thorough
363understanding of the executive cannot be obtained without
364studying the entire manual because many of RTEMS' concepts and
365features are interrelated.  Experienced RTEMS users will find
366that the manual organization facilitates its use as a reference
369@section Conventions
371The following conventions are used in this manual:
373@itemize @bullet
374@item Significant words or phrases as well as all directive
375names are printed in bold type.
377@item Items in bold capital letters are constants defined by
378RTEMS.  Each language interface provided by RTEMS includes a
379file containing the standard set of constants, data types, and
380@value{STRUCTURE} definitions which can be incorporated into the user
383@item A number of type definitions are provided by RTEMS and
384can be found in rtems.h.
386@item The characters "0x" preceding a number indicates that
387the number is in hexadecimal format.  Any other numbers are
388assumed to be in decimal format.
389@end itemize
391@section Manual Organization
393This first chapter has presented the introductory and
394background material for the RTEMS executive.  The remaining
395chapters of this manual present a detailed description of RTEMS
396and the environment, including run time behavior, it creates for
397the user.
399A chapter is dedicated to each manager and provides a
400detailed discussion of each RTEMS manager and the directives
401which it provides.  The presentation format for each directive
402includes the following sections:
404@itemize @bullet
405@item Calling sequence
406@item Directive status codes
407@item Description
408@item Notes
409@end itemize
411The following provides an overview of the remainder
412of this manual:
414@table @asis
415@item Chapter 2
416Key Concepts: presents an
417introduction to the ideas which are common across multiple RTEMS
420@item Chapter 3:
421RTEMS Data Types: describes the fundamental data types shared
422by the services in the RTEMS Classic API.
424@item Chapter 4:
425Initialization Manager: describes the functionality and directives
426provided by the Initialization Manager.
428@item Chapter 5:
429Task Manager: describes the functionality and directives provided
430by the Task Manager.
432@item Chapter 6:
433Interrupt Manager: describes the functionality and directives
434provided by the Interrupt Manager.
436@item Chapter 7:
437Clock Manager: describes the functionality and directives
438provided by the Clock Manager.
440@item Chapter 8:
441Timer Manager: describes the functionality and directives provided
442by the Timer Manager.
444@item Chapter 9:
445Semaphore Manager: describes the functionality and directives
446provided by the Semaphore Manager.
448@item Chapter 10:
449Message Manager: describes the functionality and directives
450provided by the Message Manager.
452@item Chapter 11:
453Event Manager: describes the
454functionality and directives provided by the Event Manager.
456@item Chapter 12:
457Signal Manager: describes the
458functionality and directives provided by the Signal Manager.
460@item Chapter 13:
461Partition Manager: describes the
462functionality and directives provided by the Partition Manager.
464@item Chapter 14:
465Region Manager: describes the
466functionality and directives provided by the Region Manager.
468@item Chapter 15:
469Dual-Ported Memory Manager: describes
470the functionality and directives provided by the Dual-Ported
471Memory Manager.
473@item Chapter 16:
474I/O Manager: describes the
475functionality and directives provided by the I/O Manager.
477@item Chapter 17:
478Fatal Error Manager: describes the functionality and directives
479provided by the Fatal Error Manager.
481@item Chapter 18:
482Scheduling Concepts: details the RTEMS scheduling algorithm and
483task state transitions.
485@item Chapter 19:
486Rate Monotonic Manager: describes the functionality and directives
487provided by the Rate Monotonic Manager.
489@item Chapter 20:
490Board Support Packages: defines the
491functionality required of user-supplied board support packages.
493@item Chapter 21:
494User Extensions: shows the user how to
495extend RTEMS to incorporate custom features.
497@item Chapter 22:
498Configuring a System: details the process by which one tailors RTEMS
499for a particular single-processor or multiprocessor application.
501@item Chapter 23:
502Multiprocessing Manager: presents a
503conceptual overview of the multiprocessing capabilities provided
504by RTEMS as well as describing the Multiprocessing
505Communications Interface Layer and Multiprocessing Manager
508@item Chapter 24:
509Directive Status Codes: provides a definition of each of the
510directive status codes referenced in this manual.
512@item Chapter 25:
513Example Application: provides a template for simple RTEMS applications.
515@item Chapter 26:
516Glossary: defines terms used throughout this manual.
518@end table
Note: See TracBrowser for help on using the repository browser.