1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-2002. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | @c |
---|
6 | @c $Id$ |
---|
7 | @c |
---|
8 | |
---|
9 | @chapter CPU Model Variations |
---|
10 | |
---|
11 | XXX enhance using portability presentation from CS595 class. See |
---|
12 | general/portability.ppt. |
---|
13 | |
---|
14 | Since the text in the next section was written, RTEMS view of |
---|
15 | portability has grown to distinguish totally portable, CPU |
---|
16 | family dependent, CPU model dependent, peripheral chip dependent |
---|
17 | and board dependent. This text was part of a larger paper that |
---|
18 | did not even cover portability completely as it existed when this |
---|
19 | was written and certainly is out of date now. :) |
---|
20 | |
---|
21 | |
---|
22 | @section Overview of RTEMS Portability |
---|
23 | |
---|
24 | RTEMS was designed to be a highly portable, reusable software component. |
---|
25 | This reflects the fundamental nature of embedded systems in which hardware |
---|
26 | components, ranging from boards to peripherals to even the processor |
---|
27 | itself, are selected specifically to meet the requirements of a particular |
---|
28 | project. |
---|
29 | |
---|
30 | @subsection Processor Families |
---|
31 | |
---|
32 | Since there are a wide variety of embedded systems, there are a wide |
---|
33 | variety of processors targeting embedded systems. RTEMS alleviates some of |
---|
34 | the burden on the embedded systems programmer by providing a consistent, |
---|
35 | high-performance environment regardless of the target processor. RTEMS |
---|
36 | has been ported to a variety of microprocessor families including: |
---|
37 | |
---|
38 | @itemize @bullet |
---|
39 | |
---|
40 | @item Motorola ColdFire |
---|
41 | @item Motorola MC68xxx |
---|
42 | @item Motorola MC683xx |
---|
43 | @item Intel ix86 (i386, i486, Pentium and above) |
---|
44 | @item Intel i960 |
---|
45 | @item ARM |
---|
46 | @item MIPS |
---|
47 | @item PowerPC 4xx, 5xx, 6xx, 7xx, 8xx, and 84xx |
---|
48 | @item SPARC |
---|
49 | @item Hewlett-Packard PA-RISC |
---|
50 | @item Hitachi H8/300 |
---|
51 | @item Hitachi SH |
---|
52 | @item OpenCores OR32 |
---|
53 | @item Texas Instruments C3x/C4x |
---|
54 | |
---|
55 | @end itemize |
---|
56 | |
---|
57 | |
---|
58 | In addition, there is a port of RTEMS to UNIX that uses standard UNIX |
---|
59 | services to simulate the embedded environment. |
---|
60 | |
---|
61 | Each RTEMS port supplies a well-defined set of services that are the |
---|
62 | foundation for the highly portable RTEMS and POSIX API implementations. |
---|
63 | When porting to a new processor family, one must provide the processor |
---|
64 | dependent implementation of these services. This set of processor |
---|
65 | dependent core services includes software to perform interrupt |
---|
66 | dispatching, context switches, and manipulate task register sets. |
---|
67 | |
---|
68 | The RTEMS approach to handling varying processor models reflects the |
---|
69 | approach taken by the designers of the processors themselves. In each |
---|
70 | processor family, there is a core architecture that must be implemented on |
---|
71 | all processor models within the family to provide any level of |
---|
72 | compatibility. Many of the modern RISC architectures refer to this as the |
---|
73 | Architectural Definition. The Architectural Definition is intended to be |
---|
74 | independent of any particular implementation. Additionally, there is a |
---|
75 | feature set which is allowed to vary in a defined way amongst the |
---|
76 | processor models. These feature sets may be defined as Optional in the |
---|
77 | Architectural Definition, be left as implementation defined |
---|
78 | characteristics, or be processor model specific extensions. Support for |
---|
79 | floating point, virtual memory, and low power mode are common Optional |
---|
80 | features included in an Architectural Definition. |
---|
81 | |
---|
82 | The processor family dependent software in RTEMS includes a definition of |
---|
83 | which features are present in each supported processor model. This often |
---|
84 | makes adding support for a new processor model within a supported family |
---|
85 | as simple as determining which features are present in the new processor |
---|
86 | implementation. If the new processor model varies in a way previously |
---|
87 | unaccounted for, then this must be addressed. This could be the result of |
---|
88 | a new Optional feature set being added to the Architectural Definition. |
---|
89 | Alternatively, this particular processor model could have a new and |
---|
90 | different implementation of a feature left as undefined in the |
---|
91 | Architectural Definition. This would require software to be written to |
---|
92 | utilize that feature. |
---|
93 | |
---|
94 | There is a relatively small set of features that may vary in a processor |
---|
95 | family. As the number of processor models in the family grow, the |
---|
96 | addition of each new model only requires adding an entry for the new model |
---|
97 | to the single feature table. It does not require searching for every |
---|
98 | conditional based on processor model and adding the new model in the |
---|
99 | appropriate place. This significantly eases the burden of adding a new |
---|
100 | processor model as it centralizes and logically simplifies the process. |
---|
101 | |
---|
102 | @subsection Boards |
---|
103 | |
---|
104 | Being portable both between models within a processor family and across |
---|
105 | processor families is not enough to address the needs of embedded systems |
---|
106 | developers. Custom board development is the norm for embedded systems. |
---|
107 | Each of these boards is optimized for a particular project. The processor |
---|
108 | and peripheral set have been chosen to meet a particular set of system |
---|
109 | requirements. The tools in the embedded systems developers toolbox must |
---|
110 | support their projects unique board. RTEMS addresses this issue via the |
---|
111 | Board Support Package. |
---|
112 | |
---|
113 | RTEMS segregates board specific code to make it possible for the embedded |
---|
114 | systems developer to easily replace and customize this software. A |
---|
115 | minimal Board Support Package includes device drivers for a clock tick, |
---|
116 | console I/O, and a benchmark timer (optional) as well as startup and |
---|
117 | miscellaneous support code. The Board Support Package for a project may |
---|
118 | be extended to include the device drivers for any peripherals on the |
---|
119 | custom board. |
---|
120 | |
---|
121 | @subsection Applications |
---|
122 | |
---|
123 | One important design goal of RTEMS was to provide a bridge between the |
---|
124 | application software and the target hardware. Most hardware dependencies |
---|
125 | for real-time applications can be localized to the low level device |
---|
126 | drivers which provide an abstracted view of the hardware. The RTEMS I/O |
---|
127 | interface manager provides an efficient tool for incorporating these |
---|
128 | hardware dependencies into the system while simultaneously providing a |
---|
129 | general mechanism to the application code that accesses them. A well |
---|
130 | designed real-time system can benefit from this architecture by building a |
---|
131 | rich library of standard application components which can be used |
---|
132 | repeatedly in other real-time projects. The following figure illustrates |
---|
133 | how RTEMS serves as a buffer between the project dependent application |
---|
134 | code and the target hardware. |
---|
135 | |
---|
136 | @section Coding Issues |
---|
137 | |
---|
138 | XXX deal with this as it applies to score/cpu. Section name may |
---|
139 | be bad. |
---|