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

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

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

PR 1334/doc

  • user/, user/concepts.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: 12.1 KB
2@c  COPYRIGHT (c) 1988-2007.
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@subsection Object Names
48@cindex object name
49@findex rtems_object_name
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.
55@findex rtems_build_name
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. 
62The following example illustrates this:
64@ifset is-C
66rtems_object_name my_name;
68my_name = rtems_build_name( 'L', 'I', 'T', 'E' );
69@end example
70@end ifset
72@ifset is-Ada
74My_Name : RTEMS.Name;
76My_Name = RTEMS.Build_Name( 'L', 'I', 'T', 'E' );
77@end example
78@end ifset
80However, it is not required that the application use ASCII
81characters to build object names.  For example, if an
82application requires one-hundred tasks, it would be difficult to
83assign meaningful ASCII names to each task.  A more convenient
84approach would be to name them the binary values one through
85one-hundred, respectively.
87@ifset is-C
88@findex rtems_get_object_name
90RTEMS provides a helper routine, @code{@value{DIRPREFIX}get_object_name},
91which can be used to obtain the name of any RTEMS object using just
92its ID.  This routine attempts to convert the name into a printable string.
94The following example illustrates the use of this method to print
95an object name:
98#include <rtems.h>
99#include <rtems/bspIo.h>
101void print_name(rtems_id the_object)
103  char  buffer[10];   /* name assumed to be 10 characters or less */
104  char *result;
106  result = rtems_get_object_name( id, sizeof(buffer), buffer );
107  printk( "ID=0x%08x name=%s\n", id, ((result) ? result : "no name") );
109@end example
110@end ifset
113@subsection Object IDs
115@cindex object ID
116@cindex object ID composition
117@findex rtems_id
119@need 3000
121An object ID is a unique unsigned thirty-two bit
122entity composed of three parts: API, object class, node, and index.
123The data type @code{@value{DIRPREFIX}id} is used to store object IDs.
126@ifset use-ascii
129     31      27 26   24 23          16 15                             0
130     +---------+-------+--------------+-------------------------------+
131     |         |       |              |                               |
132     |  Class  |  API  |     Node     |             Index             |
133     |         |       |              |                               |
134     +---------+-------+--------------+-------------------------------+
135@end group
136@end example
137@end ifset
139@ifset use-tex
142@end ifset
144@ifset use-html
146<IMG SRC="ObjectId-16Bits.png" WIDTH=550 HEIGHT=400 ALT="32 Bit Object Id">
147@end html
148@end ifset
151The most significant five bits are the object class.  The next
152three bits indicate the API to which the object class belongs.
153The next eight bits (16-23) are the number of the node on which
154this object was created.  The node number is always one (1) in a single
155processor system.  The least significant sixteen bits form an
156identifier within a particular object type.  This identifier,
157called the object index, ranges in value from 1 to the maximum
158number of objects configured for this object type.
160The four components of an object ID make it possible
161to quickly locate any object in even the most complicated
162multiprocessor system.  Object ID's are associated with an
163object by RTEMS when the object is created and the corresponding
164ID is returned by the appropriate object create directive.  The
165object ID is required as input to all directives involving
166objects, except those which create an object or obtain the ID of
167an object.
169The object identification directives can be used to
170dynamically obtain a particular object's ID given its name.
171This mapping is accomplished by searching the name table
172associated with this object type.  If the name is non-unique,
173then the ID associated with the first occurrence of the name
174will be returned to the application.  Since object IDs are
175returned when the object is created, the object identification
176directives are not necessary in a properly designed single
177processor application.
179In addition, services are provided to portably examine the
180three subcomponents of an RTEMS ID.  These services are
181prototyped as follows:
183@cindex obtaining class from object ID
184@cindex obtaining node from object ID
185@cindex obtaining index from object ID
186@cindex get class from object ID
187@cindex get node from object ID
188@cindex get index from object ID
189@findex rtems_get_class
190@findex rtems_get_node
191@findex rtems_get_index
194uint32_t rtems_get_class( rtems_id );
195uint32_t rtems_get_node( rtems_id );
196uint32_t rtems_get_index( rtems_id );
197@end example
199An object control block is a data structure defined
200by RTEMS which contains the information necessary to manage a
201particular object type.  For efficiency reasons, the format of
202each object type's control block is different.  However, many of
203the fields are similar in function.  The number of each type of
204control block is application dependent and determined by the
205values specified in the user's Configuration Table.  An object
206control block is allocated at object create time and freed when
207the object is deleted.  With the exception of user extension
208routines, object control blocks are not directly manipulated by
209user applications.
211@section Communication and Synchronization
213@cindex communication and synchronization
215In real-time multitasking applications, the ability
216for cooperating execution threads to communicate and synchronize
217with each other is imperative.  A real-time executive should
218provide an application with the following capabilities:
220@itemize @bullet
221@item Data transfer between cooperating tasks
222@item Data transfer between tasks and ISRs
223@item Synchronization of cooperating tasks
224@item Synchronization of tasks and ISRs
225@end itemize
227Most RTEMS managers can be used to provide some form
228of communication and/or synchronization.  However, managers
229dedicated specifically to communication and synchronization
230provide well established mechanisms which directly map to the
231application's varying needs.  This level of flexibility allows
232the application designer to match the features of a particular
233manager with the complexity of communication and synchronization
234required.  The following managers were specifically designed for
235communication and synchronization:
237@itemize @bullet
238@item Semaphore
239@item Message Queue
240@item Event
241@item Signal
242@end itemize
244The semaphore manager supports mutual exclusion
245involving the synchronization of access to one or more shared
246user resources.  Binary semaphores may utilize the optional
247priority inheritance algorithm to avoid the problem of priority
248inversion.  The message manager supports both communication and
249synchronization, while the event manager primarily provides a
250high performance synchronization mechanism.  The signal manager
251supports only asynchronous communication and is typically used
252for exception handling.
254@section Time
256@cindex time
258The development of responsive real-time applications
259requires an understanding of how RTEMS maintains and supports
260time-related operations.  The basic unit of time in RTEMS is
261known as a tick.  The frequency of clock ticks is completely
262application dependent and determines the granularity and
263accuracy of all interval and calendar time operations.
265@findex rtems_interval
267By tracking time in units of ticks, RTEMS is capable
268of supporting interval timing functions such as task delays,
269timeouts, timeslicing, the delayed execution of timer service
270routines, and the rate monotonic scheduling of tasks.  An
271interval is defined as a number of ticks relative to the current
272time.  For example, when a task delays for an interval of ten
273ticks, it is implied that the task will not execute until ten
274clock ticks have occurred.
275All intervals are specified using data type
278A characteristic of interval timing is that the
279actual interval period may be a fraction of a tick less than the
280interval requested.  This occurs because the time at which the
281delay timer is set up occurs at some time between two clock
282ticks.  Therefore, the first countdown tick occurs in less than
283the complete time interval for a tick.  This can be a problem if
284the clock granularity is large.
286The rate monotonic scheduling algorithm is a hard
287real-time scheduling methodology.  This methodology provides
288rules which allows one to guarantee that a set of independent
289periodic tasks will always meet their deadlines -- even under
290transient overload conditions.  The rate monotonic manager
291provides directives built upon the Clock Manager's interval
292timer support routines.
294Interval timing is not sufficient for the many
295applications which require that time be kept in wall time or
296true calendar form.  Consequently, RTEMS maintains the current
297date and time.  This allows selected time operations to be
298scheduled at an actual calendar date and time.  For example, a
299task could request to delay until midnight on New Year's Eve
300before lowering the ball at Times Square.
301The data type @code{@value{DIRPREFIX}time_of_day} is used to specify
302calendar time in RTEMS services. 
303@xref{Clock Manager Time and Date Data Structures, , Time and Date Data Structures}.
304@findex rtems_time_of_day
306Obviously, the directives which use intervals or wall
307time cannot operate without some external mechanism which
308provides a periodic clock tick.  This clock tick is typically
309provided by a real time clock or counter/timer device.
311@section Memory Management
313@cindex memory management
315RTEMS memory management facilities can be grouped
316into two classes: dynamic memory allocation and address
317translation.  Dynamic memory allocation is required by
318applications whose memory requirements vary through the
319application's course of execution.  Address translation is
320needed by applications which share memory with another CPU or an
321intelligent Input/Output processor.  The following RTEMS
322managers provide facilities to manage memory:
324@itemize @bullet
325@item Region
327@item Partition
329@item Dual Ported Memory
330@end itemize
332RTEMS memory management features allow an application
333to create simple memory pools of fixed size buffers and/or more
334complex memory pools of variable size segments.  The partition
335manager provides directives to manage and maintain pools of
336fixed size entities such as resource control blocks.
337Alternatively, the region manager provides a more general
338purpose memory allocation scheme that supports variable size
339blocks of memory which are dynamically obtained and freed by the
340application.  The dual-ported memory manager provides executive
341support for address translation between internal and external
342dual-ported RAM address space.
Note: See TracBrowser for help on using the repository browser.