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 | |
---|
18 | The facilities provided by RTEMS are built upon a |
---|
19 | foundation of very powerful concepts. These concepts must be |
---|
20 | understood before the application developer can efficiently |
---|
21 | utilize RTEMS. The purpose of this chapter is to familiarize |
---|
22 | one with these concepts. |
---|
23 | |
---|
24 | @section Objects |
---|
25 | |
---|
26 | @cindex objects |
---|
27 | |
---|
28 | RTEMS provides directives which can be used to |
---|
29 | dynamically create, delete, and manipulate a set of predefined |
---|
30 | object types. These types include tasks, message queues, |
---|
31 | semaphores, memory regions, memory partitions, timers, ports, |
---|
32 | and rate monotonic periods. The object-oriented nature of RTEMS |
---|
33 | encourages the creation of modular applications built upon |
---|
34 | re-usable "building block" routines. |
---|
35 | |
---|
36 | All objects are created on the local node as required |
---|
37 | by the application and have an RTEMS assigned ID. All objects |
---|
38 | have a user-assigned name. Although a relationship exists |
---|
39 | between an object's name and its RTEMS assigned ID, the name and |
---|
40 | ID are not identical. Object names are completely arbitrary and |
---|
41 | selected by the user as a meaningful "tag" which may commonly |
---|
42 | reflect the object's use in the application. Conversely, object |
---|
43 | IDs are designed to facilitate efficient object manipulation by |
---|
44 | the executive. |
---|
45 | |
---|
46 | @subsection Object Names |
---|
47 | |
---|
48 | @cindex object name |
---|
49 | @findex rtems_object_name |
---|
50 | |
---|
51 | An object name is an unsigned thirty-two bit entity |
---|
52 | associated 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 | |
---|
57 | Although not required by RTEMS, object names are often |
---|
58 | composed of four ASCII characters which help identify that object. |
---|
59 | For example, a task which causes a light to blink might be |
---|
60 | called "LITE". The @code{@value{DIRPREFIX}build_name} routine |
---|
61 | is provided to build an object name from four ASCII characters. |
---|
62 | @ifset is-C |
---|
63 | The following example illustrates this: |
---|
64 | |
---|
65 | @example |
---|
66 | rtems_object_name my_name; |
---|
67 | |
---|
68 | my_name = rtems_build_name( 'L', 'I', 'T', 'E' ); |
---|
69 | @end example |
---|
70 | @end ifset |
---|
71 | |
---|
72 | However, it is not required that the application use ASCII |
---|
73 | characters to build object names. For example, if an |
---|
74 | application requires one-hundred tasks, it would be difficult to |
---|
75 | assign meaningful ASCII names to each task. A more convenient |
---|
76 | approach would be to name them the binary values one through |
---|
77 | one-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 | |
---|
87 | An object ID is a unique unsigned thirty-two bit |
---|
88 | entity composed of three parts: object class, node, and index. |
---|
89 | The 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 | |
---|
170 | The most significant six bits are the object class. The next |
---|
171 | ten bits are the number of the node on which this object was |
---|
172 | created. The node number is always one (1) in a single |
---|
173 | processor system. The least significant sixteen bits form an |
---|
174 | identifier within a particular object type. This identifier, |
---|
175 | called the object index, ranges in value from 1 to the maximum |
---|
176 | number of objects configured for this object type. |
---|
177 | |
---|
178 | |
---|
179 | The three components of an object ID make it possible |
---|
180 | to quickly locate any object in even the most complicated |
---|
181 | multiprocessor system. Object ID's are associated with an |
---|
182 | object by RTEMS when the object is created and the corresponding |
---|
183 | ID is returned by the appropriate object create directive. The |
---|
184 | object ID is required as input to all directives involving |
---|
185 | objects, except those which create an object or obtain the ID of |
---|
186 | an object. |
---|
187 | |
---|
188 | The object identification directives can be used to |
---|
189 | dynamically obtain a particular object's ID given its name. |
---|
190 | This mapping is accomplished by searching the name table |
---|
191 | associated with this object type. If the name is non-unique, |
---|
192 | then the ID associated with the first occurrence of the name |
---|
193 | will be returned to the application. Since object IDs are |
---|
194 | returned when the object is created, the object identification |
---|
195 | directives are not necessary in a properly designed single |
---|
196 | processor application. |
---|
197 | |
---|
198 | In addition, services are provided to portably examine the |
---|
199 | three subcomponents of an RTEMS ID. These services are |
---|
200 | prototyped 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 |
---|
213 | rtems_unsigned32 rtems_get_class( rtems_id ); |
---|
214 | rtems_unsigned32 rtems_get_node( rtems_id ); |
---|
215 | rtems_unsigned32 rtems_get_index( rtems_id ); |
---|
216 | @end example |
---|
217 | |
---|
218 | An object control block is a data structure defined |
---|
219 | by RTEMS which contains the information necessary to manage a |
---|
220 | particular object type. For efficiency reasons, the format of |
---|
221 | each object type's control block is different. However, many of |
---|
222 | the fields are similar in function. The number of each type of |
---|
223 | control block is application dependent and determined by the |
---|
224 | values specified in the user's Configuration Table. An object |
---|
225 | control block is allocated at object create time and freed when |
---|
226 | the object is deleted. With the exception of user extension |
---|
227 | routines, object control blocks are not directly manipulated by |
---|
228 | user applications. |
---|
229 | |
---|
230 | @section Communication and Synchronization |
---|
231 | |
---|
232 | @cindex communication and synchronization |
---|
233 | |
---|
234 | In real-time multitasking applications, the ability |
---|
235 | for cooperating execution threads to communicate and synchronize |
---|
236 | with each other is imperative. A real-time executive should |
---|
237 | provide 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 | |
---|
246 | Most RTEMS managers can be used to provide some form |
---|
247 | of communication and/or synchronization. However, managers |
---|
248 | dedicated specifically to communication and synchronization |
---|
249 | provide well established mechanisms which directly map to the |
---|
250 | application's varying needs. This level of flexibility allows |
---|
251 | the application designer to match the features of a particular |
---|
252 | manager with the complexity of communication and synchronization |
---|
253 | required. The following managers were specifically designed for |
---|
254 | communication and synchronization: |
---|
255 | |
---|
256 | @itemize @bullet |
---|
257 | @item Semaphore |
---|
258 | @item Message Queue |
---|
259 | @item Event |
---|
260 | @item Signal |
---|
261 | @end itemize |
---|
262 | |
---|
263 | The semaphore manager supports mutual exclusion |
---|
264 | involving the synchronization of access to one or more shared |
---|
265 | user resources. Binary semaphores may utilize the optional |
---|
266 | priority inheritance algorithm to avoid the problem of priority |
---|
267 | inversion. The message manager supports both communication and |
---|
268 | synchronization, while the event manager primarily provides a |
---|
269 | high performance synchronization mechanism. The signal manager |
---|
270 | supports only asynchronous communication and is typically used |
---|
271 | for exception handling. |
---|
272 | |
---|
273 | @section Time |
---|
274 | |
---|
275 | @cindex time |
---|
276 | |
---|
277 | The development of responsive real-time applications |
---|
278 | requires an understanding of how RTEMS maintains and supports |
---|
279 | time-related operations. The basic unit of time in RTEMS is |
---|
280 | known as a tick. The frequency of clock ticks is completely |
---|
281 | application dependent and determines the granularity and |
---|
282 | accuracy of all interval and calendar time operations. |
---|
283 | |
---|
284 | @findex rtems_interval |
---|
285 | |
---|
286 | By tracking time in units of ticks, RTEMS is capable |
---|
287 | of supporting interval timing functions such as task delays, |
---|
288 | timeouts, timeslicing, the delayed execution of timer service |
---|
289 | routines, and the rate monotonic scheduling of tasks. An |
---|
290 | interval is defined as a number of ticks relative to the current |
---|
291 | time. For example, when a task delays for an interval of ten |
---|
292 | ticks, it is implied that the task will not execute until ten |
---|
293 | clock ticks have occurred. |
---|
294 | All intervals are specified using data type |
---|
295 | @code{@value{DIRPREFIX}interval}. |
---|
296 | |
---|
297 | A characteristic of interval timing is that the |
---|
298 | actual interval period may be a fraction of a tick less than the |
---|
299 | interval requested. This occurs because the time at which the |
---|
300 | delay timer is set up occurs at some time between two clock |
---|
301 | ticks. Therefore, the first countdown tick occurs in less than |
---|
302 | the complete time interval for a tick. This can be a problem if |
---|
303 | the clock granularity is large. |
---|
304 | |
---|
305 | The rate monotonic scheduling algorithm is a hard |
---|
306 | real-time scheduling methodology. This methodology provides |
---|
307 | rules which allows one to guarantee that a set of independent |
---|
308 | periodic tasks will always meet their deadlines -- even under |
---|
309 | transient overload conditions. The rate monotonic manager |
---|
310 | provides directives built upon the Clock Manager's interval |
---|
311 | timer support routines. |
---|
312 | |
---|
313 | Interval timing is not sufficient for the many |
---|
314 | applications which require that time be kept in wall time or |
---|
315 | true calendar form. Consequently, RTEMS maintains the current |
---|
316 | date and time. This allows selected time operations to be |
---|
317 | scheduled at an actual calendar date and time. For example, a |
---|
318 | task could request to delay until midnight on New Year's Eve |
---|
319 | before lowering the ball at Times Square. |
---|
320 | The data type @code{@value{DIRPREFIX}time_of_day} is used to specify |
---|
321 | calendar 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 | |
---|
325 | Obviously, the directives which use intervals or wall |
---|
326 | time cannot operate without some external mechanism which |
---|
327 | provides a periodic clock tick. This clock tick is typically |
---|
328 | provided by a real time clock or counter/timer device. |
---|
329 | |
---|
330 | @section Memory Management |
---|
331 | |
---|
332 | @cindex memory management |
---|
333 | |
---|
334 | RTEMS memory management facilities can be grouped |
---|
335 | into two classes: dynamic memory allocation and address |
---|
336 | translation. Dynamic memory allocation is required by |
---|
337 | applications whose memory requirements vary through the |
---|
338 | application's course of execution. Address translation is |
---|
339 | needed by applications which share memory with another CPU or an |
---|
340 | intelligent Input/Output processor. The following RTEMS |
---|
341 | managers 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 | |
---|
351 | RTEMS memory management features allow an application |
---|
352 | to create simple memory pools of fixed size buffers and/or more |
---|
353 | complex memory pools of variable size segments. The partition |
---|
354 | manager provides directives to manage and maintain pools of |
---|
355 | fixed size entities such as resource control blocks. |
---|
356 | Alternatively, the region manager provides a more general |
---|
357 | purpose memory allocation scheme that supports variable size |
---|
358 | blocks of memory which are dynamically obtained and freed by the |
---|
359 | application. The dual-ported memory manager provides executive |
---|
360 | support for address translation between internal and external |
---|
361 | dual-ported RAM address space. |
---|