source: rtems/doc/user/concepts.t @ 169502e
Last change on this file since 169502e was 169502e, checked in by Joel Sherrill <joel.sherrill@…>, on 10/11/99 at 19:03:05

Turned on concept and function name indexing.

  • Property mode set to 100644
File size: 11.2 KB
2@c  COPYRIGHT (c) 1988-1998.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
6@c  $Id$
10@c  The following figure was replaced with an ASCII equivalent.
11@c    Figure 2-1 Object ID Composition
14@chapter Key Concepts
16@section Introduction
18The facilities provided by RTEMS are built upon a
19foundation of very powerful concepts.  These concepts must be
20understood before the application developer can efficiently
21utilize RTEMS.  The purpose of this chapter is to familiarize
22one with these concepts.
24@section Objects
26@cindex objects
28RTEMS provides directives which can be used to
29dynamically create, delete, and manipulate a set of predefined
30object types.  These types include tasks, message queues,
31semaphores, memory regions, memory partitions, timers, ports,
32and rate monotonic periods.  The object-oriented nature of RTEMS
33encourages the creation of modular applications built upon
34re-usable "building block" routines.
36All objects are created on the local node as required
37by the application and have an RTEMS assigned ID.  All objects
38have a user-assigned name.  Although a relationship exists
39between an object's name and its RTEMS assigned ID, the name and
40ID are not identical.  Object names are completely arbitrary and
41selected by the user as a meaningful "tag" which may commonly
42reflect the object's use in the application.  Conversely, object
43IDs are designed to facilitate efficient object manipulation by
44the executive.
46@cindex object name
48An object name is an unsigned thirty-two bit entity
49associated with the object by the user.  Although not required
50by RTEMS, object names are typically composed of four ASCII
51characters which help identify that object.  For example, a task
52which causes a light to blink might be called "LITE".  Utilities
53are provided to build an object name from four ASCII characters
54and to decompose an object name into four ASCII characters.
55However, it is not required that the application use ASCII
56characters to build object names.  For example, if an
57application requires one-hundred tasks, it would be difficult to
58assign meaningful ASCII names to each task.  A more convenient
59approach would be to name them the binary values one through
60one-hundred, respectively.
62@cindex object ID
64@need 3000
66An object ID is a unique unsigned thirty-two bit
67entity composed of three parts: object class, node, and index.
68The most significant six bits are the object class.  The next
69ten bits are the number of the node on which this object was
70created.  The node number is always one (1) in a single
71processor system.  The least significant sixteen bits form an
72identifier within a particular object type.  This identifier,
73called the object index, ranges in value from 1 to the maximum
74number of objects configured for this object type.
76@ifset use-ascii
79     31        26 25              16 15                             0
80     +-----------+------------------+-------------------------------+
81     |           |                  |                               |
82     |   Class   |       Node       |             Index             |
83     |           |                  |                               |
84     +-----------+------------------+-------------------------------+
85@end group
86@end example
87@end ifset
89@ifset use-tex
90@sp 1
94\hbox to 0.50in{\enskip#}&
95\hbox to 0.50in{\enskip#}&
97\hbox to 0.50in{\enskip#}&
98\hbox to 0.50in{\enskip#}&
100\hbox to 1.00in{\enskip#}&
101\hbox to 1.00in{\enskip#}&
105 \multispan{1}\enskip25\hfil&\multispan{2}\hfil16\enskip&
106 \multispan{1}\enskip15\hfil&\multispan{2}\hfil0\cr
111\hbox to 0.50in{\enskip#}&
112\hbox to 0.50in{\enskip#}&
114\hbox to 0.50in{\enskip#}&
115\hbox to 0.50in{\enskip#}&
117\hbox to 0.50in{\enskip#}&
118\hbox to 0.50in{\enskip#}&
123&\multispan{2}\hfil Class\hfil&&
124 \multispan{2}\hfil Node\hfil&&
125 \multispan{2}\hfil Index\hfil&\cr
129@end tex
130@end ifset
132@ifset use-html
135  <TABLE COLS=6 WIDTH="60%" BORDER=0>
136<TR><TD ALIGN=left><STRONG>31</STRONG></TD>
137    <TD ALIGN=right><STRONG>26</STRONG></TD>
138    <TD ALIGN=left><STRONG>25</STRONG></TD>
139    <TD ALIGN=right><STRONG>16</STRONG></TD>
140    <TD ALIGN=left><STRONG>15</STRONG></TD>
141    <TD ALIGN=right><STRONG>0</STRONG></TD></TR>
142  </TABLE>
145  <TABLE COLS=6 WIDTH="60%" BORDER=2>
146<TR><TD ALIGN=center COLSPAN=2>Class</TD>
147    <TD ALIGN=center COLSPAN=2>Node</TD>
148    <TD ALIGN=center COLSPAN=2>Index</TD></TD>
149  </TABLE>
151@end html
152@end ifset
155The three components of an object ID make it possible
156to quickly locate any object in even the most complicated
157multiprocessor system.  Object ID's are associated with an
158object by RTEMS when the object is created and the corresponding
159ID is returned by the appropriate object create directive.  The
160object ID is required as input to all directives involving
161objects, except those which create an object or obtain the ID of
162an object.
164The object identification directives can be used to
165dynamically obtain a particular object's ID given its name.
166This mapping is accomplished by searching the name table
167associated with this object type.  If the name is non-unique,
168then the ID associated with the first occurrence of the name
169will be returned to the application.  Since object IDs are
170returned when the object is created, the object identification
171directives are not necessary in a properly designed single
172processor application.
174An object control block is a data structure defined
175by RTEMS which contains the information necessary to manage a
176particular object type.  For efficiency reasons, the format of
177each object type's control block is different.  However, many of
178the fields are similar in function.  The number of each type of
179control block is application dependent and determined by the
180values specified in the user's Configuration Table.  An object
181control block is allocated at object create time and freed when
182the object is deleted.  With the exception of user extension
183routines, object control blocks are not directly manipulated by
184user applications.
186@section Communication and Synchronization
188@cindex communication and synchronization
190In real-time multitasking applications, the ability
191for cooperating execution threads to communicate and synchronize
192with each other is imperative.  A real-time executive should
193provide an application with the following capabilities:
195@itemize @bullet
196@item Data transfer between cooperating tasks
197@item Data transfer between tasks and ISRs
198@item Synchronization of cooperating tasks
199@item Synchronization of tasks and ISRs
200@end itemize
202Most RTEMS managers can be used to provide some form
203of communication and/or synchronization.  However, managers
204dedicated specifically to communication and synchronization
205provide well established mechanisms which directly map to the
206application's varying needs.  This level of flexibility allows
207the application designer to match the features of a particular
208manager with the complexity of communication and synchronization
209required.  The following managers were specifically designed for
210communication and synchronization:
212@itemize @bullet
213@item Semaphore
214@item Message Queue
215@item Event
216@item Signal
217@end itemize
219The semaphore manager supports mutual exclusion
220involving the synchronization of access to one or more shared
221user resources.  Binary semaphores may utilize the optional
222priority inheritance algorithm to avoid the problem of priority
223inversion.  The message manager supports both communication and
224synchronization, while the event manager primarily provides a
225high performance synchronization mechanism.  The signal manager
226supports only asynchronous communication and is typically used
227for exception handling.
229@section Time
231@cindex time
233The development of responsive real-time applications
234requires an understanding of how RTEMS maintains and supports
235time-related operations.  The basic unit of time in RTEMS is
236known as a tick.  The frequency of clock ticks is completely
237application dependent and determines the granularity and
238accuracy of all interval and calendar time operations.
240By tracking time in units of ticks, RTEMS is capable
241of supporting interval timing functions such as task delays,
242timeouts, timeslicing, the delayed execution of timer service
243routines, and the rate monotonic scheduling of tasks.  An
244interval is defined as a number of ticks relative to the current
245time.  For example, when a task delays for an interval of ten
246ticks, it is implied that the task will not execute until ten
247clock ticks have occurred.
249A characteristic of interval timing is that the
250actual interval period may be a fraction of a tick less than the
251interval requested.  This occurs because the time at which the
252delay timer is set up occurs at some time between two clock
253ticks.  Therefore, the first countdown tick occurs in less than
254the complete time interval for a tick.  This can be a problem if
255the clock granularity is large.
257The rate monotonic scheduling algorithm is a hard
258real-time scheduling methodology.  This methodology provides
259rules which allows one to guarantee that a set of independent
260periodic tasks will always meet their deadlines -- even under
261transient overload conditions.  The rate monotonic manager
262provides directives built upon the Clock Manager's interval
263timer support routines.
265Interval timing is not sufficient for the many
266applications which require that time be kept in wall time or
267true calendar form.  Consequently, RTEMS maintains the current
268date and time.  This allows selected time operations to be
269scheduled at an actual calendar date and time.  For example, a
270task could request to delay until midnight on New Year's Eve
271before lowering the ball at Times Square.
273Obviously, the directives which use intervals or wall
274time cannot operate without some external mechanism which
275provides a periodic clock tick.  This clock tick is typically
276provided by a real time clock or counter/timer device.
278@section Memory Management
280@cindex memory management
282RTEMS memory management facilities can be grouped
283into two classes: dynamic memory allocation and address
284translation.  Dynamic memory allocation is required by
285applications whose memory requirements vary through the
286application's course of execution.  Address translation is
287needed by applications which share memory with another CPU or an
288intelligent Input/Output processor.  The following RTEMS
289managers provide facilities to manage memory:
291@itemize @bullet
292@item Region
294@item Partition
296@item Dual Ported Memory
297@end itemize
299RTEMS memory management features allow an application
300to create simple memory pools of fixed size buffers and/or more
301complex memory pools of variable size segments.  The partition
302manager provides directives to manage and maintain pools of
303fixed size entities such as resource control blocks.
304Alternatively, the region manager provides a more general
305purpose memory allocation scheme that supports variable size
306blocks of memory which are dynamically obtained and freed by the
307application.  The dual-ported memory manager provides executive
308support for address translation between internal and external
309dual-ported RAM address space.
Note: See TracBrowser for help on using the repository browser.