source: rtems/doc/user/concepts.t @ 71689d44
Last change on this file since 71689d44 was 71689d44, checked in by Joel Sherrill <joel.sherrill@…>, on 11/16/99 at 18:40:25

Added reference to rtems_get_class, rtems_get_node, and rtems_get_index
so users know they are part of the public API.

  • Property mode set to 100644
File size: 11.8 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
63@cindex object ID composition
65@need 3000
67An object ID is a unique unsigned thirty-two bit
68entity composed of three parts: object class, node, and index.
70@ifset use-ascii
73     31        26 25              16 15                             0
74     +-----------+------------------+-------------------------------+
75     |           |                  |                               |
76     |   Class   |       Node       |             Index             |
77     |           |                  |                               |
78     +-----------+------------------+-------------------------------+
79@end group
80@end example
81@end ifset
83@ifset use-tex
84@sp 1
88\hbox to 0.50in{\enskip#}&
89\hbox to 0.50in{\enskip#}&
91\hbox to 0.50in{\enskip#}&
92\hbox to 0.50in{\enskip#}&
94\hbox to 1.00in{\enskip#}&
95\hbox to 1.00in{\enskip#}&
99 \multispan{1}\enskip25\hfil&\multispan{2}\hfil16\enskip&
100 \multispan{1}\enskip15\hfil&\multispan{2}\hfil0\cr
105\hbox to 0.50in{\enskip#}&
106\hbox to 0.50in{\enskip#}&
108\hbox to 0.50in{\enskip#}&
109\hbox to 0.50in{\enskip#}&
111\hbox to 0.50in{\enskip#}&
112\hbox to 0.50in{\enskip#}&
117&\multispan{2}\hfil Class\hfil&&
118 \multispan{2}\hfil Node\hfil&&
119 \multispan{2}\hfil Index\hfil&\cr
123@end tex
124@end ifset
126@ifset use-html
129  <TABLE COLS=6 WIDTH="60%" BORDER=0>
130<TR><TD ALIGN=left><STRONG>31</STRONG></TD>
131    <TD ALIGN=right><STRONG>26</STRONG></TD>
132    <TD ALIGN=left><STRONG>25</STRONG></TD>
133    <TD ALIGN=right><STRONG>16</STRONG></TD>
134    <TD ALIGN=left><STRONG>15</STRONG></TD>
135    <TD ALIGN=right><STRONG>0</STRONG></TD></TR>
136  </TABLE>
139  <TABLE COLS=6 WIDTH="60%" BORDER=2>
140<TR><TD ALIGN=center COLSPAN=2>Class</TD>
141    <TD ALIGN=center COLSPAN=2>Node</TD>
142    <TD ALIGN=center COLSPAN=2>Index</TD></TD>
143  </TABLE>
145@end html
146@end ifset
148The most significant six bits are the object class.  The next
149ten bits are the number of the node on which this object was
150created.  The node number is always one (1) in a single
151processor system.  The least significant sixteen bits form an
152identifier within a particular object type.  This identifier,
153called the object index, ranges in value from 1 to the maximum
154number of objects configured for this object type.
157The three components of an object ID make it possible
158to quickly locate any object in even the most complicated
159multiprocessor system.  Object ID's are associated with an
160object by RTEMS when the object is created and the corresponding
161ID is returned by the appropriate object create directive.  The
162object ID is required as input to all directives involving
163objects, except those which create an object or obtain the ID of
164an object.
166The object identification directives can be used to
167dynamically obtain a particular object's ID given its name.
168This mapping is accomplished by searching the name table
169associated with this object type.  If the name is non-unique,
170then the ID associated with the first occurrence of the name
171will be returned to the application.  Since object IDs are
172returned when the object is created, the object identification
173directives are not necessary in a properly designed single
174processor application.
176In addition, services are provided to portably examine the
177three subcomponents of an RTEMS ID.  These services are
178prototyped as follows:
180@cindex obtaining class from object ID
181@cindex obtaining node from object ID
182@cindex obtaining index from object ID
183@cindex get class from object ID
184@cindex get node from object ID
185@cindex get index from object ID
186@findex rtems_get_class
187@findex rtems_get_node
188@findex rtems_get_index
191rtems_unsigned32 rtems_get_class( rtems_id );
192rtems_unsigned32 rtems_get_node( rtems_id );
193rtems_unsigned32 rtems_get_index( rtems_id );
194@end example
196An object control block is a data structure defined
197by RTEMS which contains the information necessary to manage a
198particular object type.  For efficiency reasons, the format of
199each object type's control block is different.  However, many of
200the fields are similar in function.  The number of each type of
201control block is application dependent and determined by the
202values specified in the user's Configuration Table.  An object
203control block is allocated at object create time and freed when
204the object is deleted.  With the exception of user extension
205routines, object control blocks are not directly manipulated by
206user applications.
208@section Communication and Synchronization
210@cindex communication and synchronization
212In real-time multitasking applications, the ability
213for cooperating execution threads to communicate and synchronize
214with each other is imperative.  A real-time executive should
215provide an application with the following capabilities:
217@itemize @bullet
218@item Data transfer between cooperating tasks
219@item Data transfer between tasks and ISRs
220@item Synchronization of cooperating tasks
221@item Synchronization of tasks and ISRs
222@end itemize
224Most RTEMS managers can be used to provide some form
225of communication and/or synchronization.  However, managers
226dedicated specifically to communication and synchronization
227provide well established mechanisms which directly map to the
228application's varying needs.  This level of flexibility allows
229the application designer to match the features of a particular
230manager with the complexity of communication and synchronization
231required.  The following managers were specifically designed for
232communication and synchronization:
234@itemize @bullet
235@item Semaphore
236@item Message Queue
237@item Event
238@item Signal
239@end itemize
241The semaphore manager supports mutual exclusion
242involving the synchronization of access to one or more shared
243user resources.  Binary semaphores may utilize the optional
244priority inheritance algorithm to avoid the problem of priority
245inversion.  The message manager supports both communication and
246synchronization, while the event manager primarily provides a
247high performance synchronization mechanism.  The signal manager
248supports only asynchronous communication and is typically used
249for exception handling.
251@section Time
253@cindex time
255The development of responsive real-time applications
256requires an understanding of how RTEMS maintains and supports
257time-related operations.  The basic unit of time in RTEMS is
258known as a tick.  The frequency of clock ticks is completely
259application dependent and determines the granularity and
260accuracy of all interval and calendar time operations.
262By tracking time in units of ticks, RTEMS is capable
263of supporting interval timing functions such as task delays,
264timeouts, timeslicing, the delayed execution of timer service
265routines, and the rate monotonic scheduling of tasks.  An
266interval is defined as a number of ticks relative to the current
267time.  For example, when a task delays for an interval of ten
268ticks, it is implied that the task will not execute until ten
269clock ticks have occurred.
271A characteristic of interval timing is that the
272actual interval period may be a fraction of a tick less than the
273interval requested.  This occurs because the time at which the
274delay timer is set up occurs at some time between two clock
275ticks.  Therefore, the first countdown tick occurs in less than
276the complete time interval for a tick.  This can be a problem if
277the clock granularity is large.
279The rate monotonic scheduling algorithm is a hard
280real-time scheduling methodology.  This methodology provides
281rules which allows one to guarantee that a set of independent
282periodic tasks will always meet their deadlines -- even under
283transient overload conditions.  The rate monotonic manager
284provides directives built upon the Clock Manager's interval
285timer support routines.
287Interval timing is not sufficient for the many
288applications which require that time be kept in wall time or
289true calendar form.  Consequently, RTEMS maintains the current
290date and time.  This allows selected time operations to be
291scheduled at an actual calendar date and time.  For example, a
292task could request to delay until midnight on New Year's Eve
293before lowering the ball at Times Square.
295Obviously, the directives which use intervals or wall
296time cannot operate without some external mechanism which
297provides a periodic clock tick.  This clock tick is typically
298provided by a real time clock or counter/timer device.
300@section Memory Management
302@cindex memory management
304RTEMS memory management facilities can be grouped
305into two classes: dynamic memory allocation and address
306translation.  Dynamic memory allocation is required by
307applications whose memory requirements vary through the
308application's course of execution.  Address translation is
309needed by applications which share memory with another CPU or an
310intelligent Input/Output processor.  The following RTEMS
311managers provide facilities to manage memory:
313@itemize @bullet
314@item Region
316@item Partition
318@item Dual Ported Memory
319@end itemize
321RTEMS memory management features allow an application
322to create simple memory pools of fixed size buffers and/or more
323complex memory pools of variable size segments.  The partition
324manager provides directives to manage and maintain pools of
325fixed size entities such as resource control blocks.
326Alternatively, the region manager provides a more general
327purpose memory allocation scheme that supports variable size
328blocks of memory which are dynamically obtained and freed by the
329application.  The dual-ported memory manager provides executive
330support for address translation between internal and external
331dual-ported RAM address space.
Note: See TracBrowser for help on using the repository browser.