source: rtems/doc/user/bsp.t @ 1e524995

4.104.114.84.95
Last change on this file since 1e524995 was 1e524995, checked in by Joel Sherrill <joel.sherrill@…>, on Feb 6, 1998 at 2:14:30 PM

Updated copyrights

  • Property mode set to 100644
File size: 15.3 KB
Line 
1@c
2@c  COPYRIGHT (c) 1988-1998.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5@c
6@c  $Id$
7@c
8
9@ifinfo
10@node Board Support Packages, Board Support Packages Introduction, RATE_MONOTONIC_GET_STATUS - Obtain status information on period, Top
11@end ifinfo
12@chapter Board Support Packages
13@ifinfo
14@menu
15* Board Support Packages Introduction::
16* Board Support Packages Reset and Initialization::
17* Board Support Packages Device Drivers::
18* Board Support Packages User Extensions::
19* Board Support Packages Multiprocessor Communications Interface (MPCI)::
20@end menu
21@end ifinfo
22
23@ifinfo
24@node Board Support Packages Introduction, Board Support Packages Reset and Initialization, Board Support Packages, Board Support Packages
25@end ifinfo
26@section Introduction
27
28A board support package (BSP) is a collection of
29user-provided facilities which interface RTEMS and an
30application with a specific hardware platform.  These facilities
31may  include hardware initialization, device drivers, user
32extensions, and a Multiprocessor Communications Interface
33(MPCI).  However, a minimal BSP need only support processor
34reset and initialization and, if needed, a clock tick.
35
36@ifinfo
37@node Board Support Packages Reset and Initialization, Interrupt Stack Requirements, Board Support Packages Introduction, Board Support Packages
38@end ifinfo
39@section Reset and Initialization
40@ifinfo
41@menu
42* Interrupt Stack Requirements::
43* Processors with a Separate Interrupt Stack::
44* Processors without a Separate Interrupt Stack::
45@end menu
46@end ifinfo
47
48An RTEMS based application is initiated or
49re-initiated when the processor is reset.  This initialization
50code is responsible for preparing the target platform for the
51RTEMS application.  Although the exact actions performed by the
52initialization code are highly processor and target dependent,
53the logical functionality of these actions are similar across a
54variety of processors and target platforms.
55
56Normally, the application's initialization is
57performed at two separate times:  before the call to
58initialize_executive (reset application initialization) and
59after initialize_executive in the user's initialization tasks
60(local and global application initialization).  The order of the
61startup procedure is as follows:
62
63@enumerate
64@item Reset application initialization.
65@item Call to initialize_executive
66@item Local and global application initialization.
67@end enumerate
68
69The reset application initialization code is executed
70first when the processor is reset.  All of the hardware must be
71initialized to a quiescent state by this software before
72initializing RTEMS.  When in quiescent state, devices do not
73generate any interrupts or require any servicing by the
74application.  Some of the hardware components may be initialized
75in this code as well as any application initialization that does
76not involve calls to RTEMS directives.
77
78The processor's Interrupt Vector Table which will be
79used by the application may need to be set to the required value
80by the reset application initialization code.  Because
81interrupts are enabled automatically by RTEMS as part of the
82initialize_executive directive, the Interrupt Vector Table MUST
83be set before this directive is invoked to insure correct
84interrupt vectoring.  The processor's Interrupt Vector Table
85must be accessible by RTEMS as it will be modified by the
86interrupt_catch directive.  On some CPUs, RTEMS installs it's
87own Interrupt Vector Table as part of initialization and thus
88these requirements are met automatically.  The reset code which
89is executed before the call to initialize_executive has the
90following requirements:
91
92@itemize @bullet
93@item Must not make any RTEMS directive calls.
94
95@item If the processor supports multiple privilege levels,
96must leave the processor in the most privileged, or supervisory,
97state.
98
99@item Must allocate a stack of at least @code{MINIMUM_STACK_SIZE}
100bytes and initialize the stack pointer for the
101initialize_executive directive.
102
103@item Must initialize the processor's Interrupt Vector Table.
104
105@item Must disable all maskable interrupts.
106
107@item If the processor supports a separate interrupt stack,
108must allocate the interrupt stack and initialize the interrupt
109stack pointer.
110@end itemize
111
112The initialize_executive directive does not return to
113the initialization code, but causes the highest priority
114initialization task to begin execution.  Initialization tasks
115are used to perform both local and global application
116initialization which is dependent on RTEMS facilities.  The user
117initialization task facility is typically used to create the
118application's set of tasks.
119
120@ifinfo
121@node Interrupt Stack Requirements, Processors with a Separate Interrupt Stack, Board Support Packages Reset and Initialization, Board Support Packages Reset and Initialization
122@end ifinfo
123@subsection Interrupt Stack Requirements
124
125The worst-case stack usage by interrupt service
126routines must be taken into account when designing an
127application.  If the processor supports interrupt nesting, the
128stack usage must include the deepest nest level.  The worst-case
129stack usage must account for the following requirements:
130
131@itemize @bullet
132@item Processor's interrupt stack frame
133
134@item Processor's subroutine call stack frame
135
136@item RTEMS system calls
137
138@item Registers saved on stack
139
140@item Application subroutine calls
141@end itemize
142
143The size of the interrupt stack must be greater than
144or equal to the constant @code{MINIMUM_STACK_SIZE}.
145
146@ifinfo
147@node Processors with a Separate Interrupt Stack, Processors without a Separate Interrupt Stack, Interrupt Stack Requirements, Board Support Packages Reset and Initialization
148@end ifinfo
149@subsection Processors with a Separate Interrupt Stack
150
151Some processors support a separate stack for
152interrupts.  When an interrupt is vectored and the interrupt is
153not nested, the processor will automatically switch from the
154current stack to the interrupt stack.  The size of this stack is
155based solely on the worst-case stack usage by interrupt service
156routines.
157
158The dedicated interrupt stack for the entire
159application is supplied and initialized by the reset and
160initialization code of the user's board support package.  Since
161all ISRs use this stack, the stack size must take into account
162the worst case stack usage by any combination of nested ISRs.
163
164@ifinfo
165@node Processors without a Separate Interrupt Stack, Board Support Packages Device Drivers, Processors with a Separate Interrupt Stack, Board Support Packages Reset and Initialization
166@end ifinfo
167@subsection Processors without a Separate Interrupt Stack
168
169Some processors do not support a separate stack for
170interrupts.  In this case, without special assistance every
171task's stack must include enough space to handle the task's
172worst-case stack usage as well as the worst-case interrupt stack
173usage.  This is necessary because the worst-case interrupt
174nesting could occur while any task is executing.
175
176On many processors without dedicated hardware managed
177interrupt stacks, RTEMS manages a dedicated interrupt stack in
178software.  If this capability is supported on a CPU, then it is
179logically equivalent to the processor supporting a separate
180interrupt stack in hardware.
181
182@ifinfo
183@node Board Support Packages Device Drivers, Clock Tick Device Driver, Processors without a Separate Interrupt Stack, Board Support Packages
184@end ifinfo
185@section Device Drivers
186@ifinfo
187@menu
188* Clock Tick Device Driver::
189@end menu
190@end ifinfo
191
192Device drivers consist of control software for
193special peripheral devices and provide a logical interface for
194the application developer.  The RTEMS I/O manager provides
195directives which allow applications to access these device
196drivers in a consistent fashion.  A Board Support Package may
197include device drivers to access the hardware on the target
198platform.  These devices typically include serial and parallel
199ports, counter/timer peripherals, real-time clocks, disk
200interfaces, and network controllers.
201
202For more information on device drivers, refer to the
203I/O Manager chapter.
204
205@ifinfo
206@node Clock Tick Device Driver, Board Support Packages User Extensions, Board Support Packages Device Drivers, Board Support Packages Device Drivers
207@end ifinfo
208@subsection Clock Tick Device Driver
209
210Most RTEMS applications will include a clock tick
211device driver which invokes the clock_tick directive at regular
212intervals.  The clock tick is necessary if the application is to
213utilize timeslicing, the clock manager, the timer manager, the
214rate monotonic manager, or the timeout option on blocking
215directives.
216
217The clock tick is usually provided as an interrupt
218from a counter/timer or a real-time clock device.  When a
219counter/timer is used to provide the clock tick, the device is
220typically programmed to operate in continuous mode.  This mode
221selection causes the device to automatically reload the initial
222count and continue the countdown without programmer
223intervention.  This reduces the overhead required to manipulate
224the counter/timer in the clock tick ISR and increases the
225accuracy of tick occurrences.  The initial count can be based on
226the microseconds_per_tick field in the RTEMS Configuration
227Table.  An alternate approach is to set the initial count for a
228fixed time period (such as one millisecond) and have the ISR
229invoke clock_tick on the microseconds_per_tick boundaries.
230Obviously, this can induce some error if the configured
231microseconds_per_tick is not evenly divisible by the chosen
232clock interrupt quantum.
233
234It is important to note that the interval between
235clock ticks directly impacts the granularity of RTEMS timing
236operations.  In addition, the frequency of clock ticks is an
237important factor in the overall level of system overhead.  A
238high clock tick frequency results in less processor time being
239available for task execution due to the increased number of
240clock tick ISRs.
241
242@ifinfo
243@node Board Support Packages User Extensions, Board Support Packages Multiprocessor Communications Interface (MPCI), Clock Tick Device Driver, Board Support Packages
244@end ifinfo
245@section User Extensions
246
247RTEMS allows the application developer to augment
248selected features by invoking user-supplied extension routines
249when the following system events occur:
250
251@itemize @bullet
252@item Task creation
253@item Task initiation
254@item Task reinitiation
255@item Task deletion
256@item Task context switch
257@item Post task context switch
258@item Task begin
259@item Task exits
260@item Fatal error detection
261@end itemize
262
263User extensions can be used to implement a wide variety of
264functions including execution profiling, non-standard
265coprocessor support, debug support, and error detection and
266recovery.  For example, the context of a non-standard numeric
267coprocessor may be maintained via the user extensions.  In this
268example, the task creation and deletion extensions are
269responsible for allocating and deallocating the context area,
270the task initiation and reinitiation extensions would be
271responsible for priming the context area, and the task context
272switch extension would save and restore the context of the
273device.
274
275For more information on user extensions, refer to the
276User Extensions chapter.
277
278@ifinfo
279@node Board Support Packages Multiprocessor Communications Interface (MPCI), Tightly-Coupled Systems, Board Support Packages User Extensions, Board Support Packages
280@end ifinfo
281@section Multiprocessor Communications Interface (MPCI)
282@ifinfo
283@menu
284* Tightly-Coupled Systems::
285* Loosely-Coupled Systems::
286* Systems with Mixed Coupling::
287* Heterogeneous Systems::
288@end menu
289@end ifinfo
290
291RTEMS requires that an MPCI layer be provided when a
292multiple node application is developed.  This MPCI layer must
293provide an efficient and reliable communications mechanism
294between the multiple nodes.  Tasks on different nodes
295communicate and synchronize with one another via the MPCI.  Each
296MPCI layer must be tailored to support the architecture of the
297target platform.
298
299For more information on the MPCI, refer to the
300Multiprocessing Manager chapter.
301
302@ifinfo
303@node Tightly-Coupled Systems, Loosely-Coupled Systems, Board Support Packages Multiprocessor Communications Interface (MPCI), Board Support Packages Multiprocessor Communications Interface (MPCI)
304@end ifinfo
305@subsection Tightly-Coupled Systems
306
307A tightly-coupled system is a multiprocessor
308configuration in which the processors communicate solely via
309shared global memory.  The MPCI can simply place the RTEMS
310packets in the shared memory space.  The two primary
311considerations when designing an MPCI for a tightly-coupled
312system are data consistency and informing another node of a
313packet.
314
315The data consistency problem may be solved using
316atomic "test and set" operations to provide a "lock" in the
317shared memory.  It is important to minimize the length of time
318any particular processor locks a shared data structure.
319
320The problem of informing another node of a packet can
321be addressed using one of two techniques.  The first technique
322is to use an interprocessor interrupt capability to cause an
323interrupt on the receiving node.  This technique requires that
324special support hardware be provided by either the processor
325itself or the target platform.  The second technique is to have
326a node poll for arrival of packets.  The drawback to this
327technique is the overhead associated with polling.
328
329@ifinfo
330@node Loosely-Coupled Systems, Systems with Mixed Coupling, Tightly-Coupled Systems, Board Support Packages Multiprocessor Communications Interface (MPCI)
331@end ifinfo
332@subsection Loosely-Coupled Systems
333
334A loosely-coupled system is a multiprocessor
335configuration in which the processors communicate via some type
336of communications link which is not shared global memory.  The
337MPCI sends the RTEMS packets across the communications link to
338the destination node.  The characteristics of the communications
339link vary widely and have a significant impact on the MPCI
340layer.  For example, the bandwidth of the communications link
341has an obvious impact on the maximum MPCI throughput.
342
343The characteristics of a shared network, such as
344Ethernet, lend themselves to supporting an MPCI layer.  These
345networks provide both the point-to-point and broadcast
346capabilities which are expected by RTEMS.
347
348@ifinfo
349@node Systems with Mixed Coupling, Heterogeneous Systems, Loosely-Coupled Systems, Board Support Packages Multiprocessor Communications Interface (MPCI)
350@end ifinfo
351@subsection Systems with Mixed Coupling
352
353A mixed-coupling system is a multiprocessor
354configuration in which the processors communicate via both
355shared memory and communications links.  A unique characteristic
356of mixed-coupling systems is that a node may not have access to
357all communication methods.  There may be multiple shared memory
358areas and communication links.  Therefore, one of the primary
359functions of the MPCI layer is to efficiently route RTEMS
360packets between nodes.  This routing may be based on numerous
361algorithms. In addition, the router may provide alternate
362communications paths in the event of an overload or a partial
363failure.
364
365@ifinfo
366@node Heterogeneous Systems, User Extensions Manager, Systems with Mixed Coupling, Board Support Packages Multiprocessor Communications Interface (MPCI)
367@end ifinfo
368@subsection Heterogeneous Systems
369
370Designing an MPCI layer for a heterogeneous system
371requires special considerations by the developer.  RTEMS is
372designed to eliminate many of the problems associated with
373sharing data in a heterogeneous environment.  The MPCI layer
374need only address the representation of thirty-two (32) bit
375unsigned quantities.
376
377For more information on supporting a heterogeneous
378system, refer the Supporting Heterogeneous Environments in the
379Multiprocessing Manager chapter.
Note: See TracBrowser for help on using the repository browser.