source: rtems-docs/porting/cpu_model_variations.rst @ 4886d60

5
Last change on this file since 4886d60 was 4886d60, checked in by Sebastian Huber <sebastian.huber@…>, on 01/09/19 at 15:14:04

Use standard format for copyright lines

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