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