source: rtems/doc/user/concepts.t @ adee5979

4.104.114.84.95
Last change on this file since adee5979 was adee5979, checked in by Joel Sherrill <joel.sherrill@…>, on 05/04/00 at 19:45:17

Numerous changes based on comments from Stephan Wilms <Stephan.Wilms@…>
including a new section in the Getting Started called "Where to
Go From Here", lots of index entries added, and more configuration
table information.

  • Property mode set to 100644
File size: 12.5 KB
Line 
1@c
2@c  COPYRIGHT (c) 1988-1999.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5@c
6@c  $Id$
7@c
8
9@c
10@c  The following figure was replaced with an ASCII equivalent.
11@c    Figure 2-1 Object ID Composition
12@c
13
14@chapter Key Concepts
15
16@section Introduction
17
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.
23
24@section Objects
25
26@cindex objects
27
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.
35
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.
45
46@subsection Object Names
47
48@cindex object name
49@findex rtems_object_name
50
51An object name is an unsigned thirty-two bit entity
52associated with the object by the user.  The data type
53@code{@value{DIRPREFIX}name} is used to store object names.
54
55@findex rtems_build_name
56
57Although not required by RTEMS, object names are often
58composed of four ASCII characters which help identify that object.
59For example, a task which causes a light to blink might be
60called "LITE".  The @code{@value{DIRPREFIX}build_name} routine
61is provided to build an object name from four ASCII characters. 
62@ifset is-C
63The following example illustrates this:
64
65@example
66rtems_object_name my_name;
67
68my_name = rtems_build_name( 'L', 'I', 'T', 'E' );
69@end example
70@end ifset
71
72However, it is not required that the application use ASCII
73characters to build object names.  For example, if an
74application requires one-hundred tasks, it would be difficult to
75assign meaningful ASCII names to each task.  A more convenient
76approach would be to name them the binary values one through
77one-hundred, respectively.
78
79@subsection Object IDs
80
81@cindex object ID
82@cindex object ID composition
83@findex rtems_id
84
85@need 3000
86
87An object ID is a unique unsigned thirty-two bit
88entity composed of three parts: object class, node, and index.
89The data type @code{@value{DIRPREFIX}id} is used to store object IDs.
90
91
92@ifset use-ascii
93@example
94@group
95     31        26 25              16 15                             0
96     +-----------+------------------+-------------------------------+
97     |           |                  |                               |
98     |   Class   |       Node       |             Index             |
99     |           |                  |                               |
100     +-----------+------------------+-------------------------------+
101@end group
102@end example
103@end ifset
104
105@ifset use-tex
106@sp 1
107@tex
108\centerline{\vbox{\offinterlineskip\halign{
109\strut#&
110\hbox to 0.50in{\enskip#}&
111\hbox to 0.50in{\enskip#}&
112#&
113\hbox to 0.50in{\enskip#}&
114\hbox to 0.50in{\enskip#}&
115#&
116\hbox to 1.00in{\enskip#}&
117\hbox to 1.00in{\enskip#}&
118#\cr
119\multispan{9}\cr
120\multispan{2}31\hfil&\multispan{2}\hfil26\enskip&
121 \multispan{1}\enskip25\hfil&\multispan{2}\hfil16\enskip&
122 \multispan{1}\enskip15\hfil&\multispan{2}\hfil0\cr
123&&&&&&&&&\cr
124}}\hfil}
125\centerline{\vbox{\offinterlineskip\halign{
126\strut\vrule#&
127\hbox to 0.50in{\enskip#}&
128\hbox to 0.50in{\enskip#}&
129\vrule#&
130\hbox to 0.50in{\enskip#}&
131\hbox to 0.50in{\enskip#}&
132\vrule#&
133\hbox to 0.50in{\enskip#}&
134\hbox to 0.50in{\enskip#}&
135\vrule#\cr
136\multispan{9}\cr
137\noalign{\hrule}
138&&&&&&&&&\cr
139&\multispan{2}\hfil Class\hfil&&
140 \multispan{2}\hfil Node\hfil&&
141 \multispan{2}\hfil Index\hfil&\cr
142&&&&&&&&&\cr
143\noalign{\hrule}
144}}\hfil}
145@end tex
146@end ifset
147
148@ifset use-html
149@html
150<CENTER>
151  <TABLE COLS=6 WIDTH="60%" BORDER=0>
152<TR><TD ALIGN=left><STRONG>31</STRONG></TD>
153    <TD ALIGN=right><STRONG>26</STRONG></TD>
154    <TD ALIGN=left><STRONG>25</STRONG></TD>
155    <TD ALIGN=right><STRONG>16</STRONG></TD>
156    <TD ALIGN=left><STRONG>15</STRONG></TD>
157    <TD ALIGN=right><STRONG>0</STRONG></TD></TR>
158  </TABLE>
159</CENTER>
160<CENTER>
161  <TABLE COLS=6 WIDTH="60%" BORDER=2>
162<TR><TD ALIGN=center COLSPAN=2>Class</TD>
163    <TD ALIGN=center COLSPAN=2>Node</TD>
164    <TD ALIGN=center COLSPAN=2>Index</TD></TD>
165  </TABLE>
166</CENTER>
167@end html
168@end ifset
169
170The most significant six bits are the object class.  The next
171ten bits are the number of the node on which this object was
172created.  The node number is always one (1) in a single
173processor system.  The least significant sixteen bits form an
174identifier within a particular object type.  This identifier,
175called the object index, ranges in value from 1 to the maximum
176number of objects configured for this object type.
177
178
179The three components of an object ID make it possible
180to quickly locate any object in even the most complicated
181multiprocessor system.  Object ID's are associated with an
182object by RTEMS when the object is created and the corresponding
183ID is returned by the appropriate object create directive.  The
184object ID is required as input to all directives involving
185objects, except those which create an object or obtain the ID of
186an object.
187
188The object identification directives can be used to
189dynamically obtain a particular object's ID given its name.
190This mapping is accomplished by searching the name table
191associated with this object type.  If the name is non-unique,
192then the ID associated with the first occurrence of the name
193will be returned to the application.  Since object IDs are
194returned when the object is created, the object identification
195directives are not necessary in a properly designed single
196processor application.
197
198In addition, services are provided to portably examine the
199three subcomponents of an RTEMS ID.  These services are
200prototyped as follows:
201
202@cindex obtaining class from object ID
203@cindex obtaining node from object ID
204@cindex obtaining index from object ID
205@cindex get class from object ID
206@cindex get node from object ID
207@cindex get index from object ID
208@findex rtems_get_class
209@findex rtems_get_node
210@findex rtems_get_index
211
212@example
213rtems_unsigned32 rtems_get_class( rtems_id );
214rtems_unsigned32 rtems_get_node( rtems_id );
215rtems_unsigned32 rtems_get_index( rtems_id );
216@end example
217
218An object control block is a data structure defined
219by RTEMS which contains the information necessary to manage a
220particular object type.  For efficiency reasons, the format of
221each object type's control block is different.  However, many of
222the fields are similar in function.  The number of each type of
223control block is application dependent and determined by the
224values specified in the user's Configuration Table.  An object
225control block is allocated at object create time and freed when
226the object is deleted.  With the exception of user extension
227routines, object control blocks are not directly manipulated by
228user applications.
229
230@section Communication and Synchronization
231
232@cindex communication and synchronization
233
234In real-time multitasking applications, the ability
235for cooperating execution threads to communicate and synchronize
236with each other is imperative.  A real-time executive should
237provide an application with the following capabilities:
238
239@itemize @bullet
240@item Data transfer between cooperating tasks
241@item Data transfer between tasks and ISRs
242@item Synchronization of cooperating tasks
243@item Synchronization of tasks and ISRs
244@end itemize
245
246Most RTEMS managers can be used to provide some form
247of communication and/or synchronization.  However, managers
248dedicated specifically to communication and synchronization
249provide well established mechanisms which directly map to the
250application's varying needs.  This level of flexibility allows
251the application designer to match the features of a particular
252manager with the complexity of communication and synchronization
253required.  The following managers were specifically designed for
254communication and synchronization:
255
256@itemize @bullet
257@item Semaphore
258@item Message Queue
259@item Event
260@item Signal
261@end itemize
262
263The semaphore manager supports mutual exclusion
264involving the synchronization of access to one or more shared
265user resources.  Binary semaphores may utilize the optional
266priority inheritance algorithm to avoid the problem of priority
267inversion.  The message manager supports both communication and
268synchronization, while the event manager primarily provides a
269high performance synchronization mechanism.  The signal manager
270supports only asynchronous communication and is typically used
271for exception handling.
272
273@section Time
274
275@cindex time
276
277The development of responsive real-time applications
278requires an understanding of how RTEMS maintains and supports
279time-related operations.  The basic unit of time in RTEMS is
280known as a tick.  The frequency of clock ticks is completely
281application dependent and determines the granularity and
282accuracy of all interval and calendar time operations.
283
284@findex rtems_interval
285
286By tracking time in units of ticks, RTEMS is capable
287of supporting interval timing functions such as task delays,
288timeouts, timeslicing, the delayed execution of timer service
289routines, and the rate monotonic scheduling of tasks.  An
290interval is defined as a number of ticks relative to the current
291time.  For example, when a task delays for an interval of ten
292ticks, it is implied that the task will not execute until ten
293clock ticks have occurred.
294All intervals are specified using data type
295@code{@value{DIRPREFIX}interval}.
296
297A characteristic of interval timing is that the
298actual interval period may be a fraction of a tick less than the
299interval requested.  This occurs because the time at which the
300delay timer is set up occurs at some time between two clock
301ticks.  Therefore, the first countdown tick occurs in less than
302the complete time interval for a tick.  This can be a problem if
303the clock granularity is large.
304
305The rate monotonic scheduling algorithm is a hard
306real-time scheduling methodology.  This methodology provides
307rules which allows one to guarantee that a set of independent
308periodic tasks will always meet their deadlines -- even under
309transient overload conditions.  The rate monotonic manager
310provides directives built upon the Clock Manager's interval
311timer support routines.
312
313Interval timing is not sufficient for the many
314applications which require that time be kept in wall time or
315true calendar form.  Consequently, RTEMS maintains the current
316date and time.  This allows selected time operations to be
317scheduled at an actual calendar date and time.  For example, a
318task could request to delay until midnight on New Year's Eve
319before lowering the ball at Times Square.
320The data type @code{@value{DIRPREFIX}time_of_day} is used to specify
321calendar time in RTEMS services. 
322@xref{Clock Manager Time and Date Data Structures, , Time and Date Data Structures}.
323@findex rtems_time_of_day
324
325Obviously, the directives which use intervals or wall
326time cannot operate without some external mechanism which
327provides a periodic clock tick.  This clock tick is typically
328provided by a real time clock or counter/timer device.
329
330@section Memory Management
331
332@cindex memory management
333
334RTEMS memory management facilities can be grouped
335into two classes: dynamic memory allocation and address
336translation.  Dynamic memory allocation is required by
337applications whose memory requirements vary through the
338application's course of execution.  Address translation is
339needed by applications which share memory with another CPU or an
340intelligent Input/Output processor.  The following RTEMS
341managers provide facilities to manage memory:
342
343@itemize @bullet
344@item Region
345
346@item Partition
347
348@item Dual Ported Memory
349@end itemize
350
351RTEMS memory management features allow an application
352to create simple memory pools of fixed size buffers and/or more
353complex memory pools of variable size segments.  The partition
354manager provides directives to manage and maintain pools of
355fixed size entities such as resource control blocks.
356Alternatively, the region manager provides a more general
357purpose memory allocation scheme that supports variable size
358blocks of memory which are dynamically obtained and freed by the
359application.  The dual-ported memory manager provides executive
360support for address translation between internal and external
361dual-ported RAM address space.
Note: See TracBrowser for help on using the repository browser.