source: rtems/doc/started/intro.t @ 9b4422a2

4.115
Last change on this file since 9b4422a2 was 9b4422a2, checked in by Joel Sherrill <joel.sherrill@…>, on 05/03/12 at 15:09:24

Remove All CVS Id Strings Possible Using a Script

Script does what is expected and tries to do it as
smartly as possible.

+ remove occurrences of two blank comment lines

next to each other after Id string line removed.

+ remove entire comment blocks which only exited to

contain CVS Ids

+ If the processing left a blank line at the top of

a file, it was removed.

  • Property mode set to 100644
File size: 8.6 KB
Line 
1@c
2@c  COPYRIGHT (c) 1988-2010.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5
6@chapter Introduction
7
8The purpose of this document is to guide you through the process of
9installing a GNU cross development environment to use with RTEMS.
10
11If you are already familiar with the concepts behind a cross compiler and
12have a background in Unix, these instructions should provide the bare
13essentials for performing a setup of the following items:
14
15@itemize @bullet
16@item GNU Cross Compilation Tools for RTEMS on your build-host system
17@item RTEMS OS for the target
18@item GNU Debugger (GDB)
19@end itemize
20
21The remainder of this chapter provides background information on real-time
22embedded systems and cross development and an overview of other
23resources of interest on the Internet.  If you are not familiar with
24real-time embedded systems or the other areas, please read those sections. 
25These sections will help familiarize you with the
26types of systems RTEMS is designed to be used in and the cross development
27process used when developing RTEMS applications.
28
29@section Real-Time Embedded Systems
30
31Real-time embedded systems are found in practically every facet of our
32everyday lives.  Today's systems range from the common telephone, automobile
33control systems, and kitchen appliances to complex air traffic control
34systems, military weapon systems, and production line control including
35robotics and automation. However, in the current climate of rapidly changing
36technology, it is difficult to reach a consensus on the definition of a
37real-time embedded system. Hardware costs are continuing to rapidly decline
38while at the same time the hardware is increasing in power and functionality.
39As a result, embedded systems that were not considered viable two years ago
40are suddenly a cost effective solution. In this domain, it is not uncommon
41for a single hardware configuration to employ a variety of architectures and
42technologies. Therefore, we shall define an embedded system as any computer
43system that is built into a larger system consisting of multiple technologies
44such as digital and analog electronics,  mechanical devices, and sensors.
45
46Even as hardware platforms become more powerful, most embedded systems are
47critically dependent on the real-time software embedded in the systems
48themselves.  Regardless of how efficiently the hardware operates, the
49performance of the embedded real-time software determines the success of the
50system.  As the complexity of the embedded hardware platform grows, so does
51the size and complexity of the embedded software. Software systems must
52routinely perform activities which were only dreamed of a short time ago.
53These large, complex, real-time embedded applications now commonly contain
54one million lines of code or more.
55
56Real-time embedded systems have a complex set of characteristics that
57distinguish them from other software applications.  Real-time embedded
58systems are driven by and must respond to real world events while adhering to
59rigorous requirements imposed by the environment with which they interact.
60The correctness of the system depends not only on the results of
61computations, but also on the time at which the results are produced.  The
62most important and complex characteristic of real-time application systems is
63that they must receive and respond to a set of external stimuli within rigid
64and critical time constraints.
65
66A single real-time application can be composed of both soft and hard
67real-time components. A typical example of a hard real-time system is a
68nuclear reactor control system that must not only detect failures, but must
69also respond quickly enough to prevent a meltdown. This application also has
70soft real-time requirements because it may involve a man-machine interface.
71Providing an interactive input to the control system is not as critical as
72setting off an alarm to indicate a failure condition. However, the
73interactive system component must respond within an acceptable time limit to
74allow the operator to interact efficiently with the control system.
75
76@section Cross Development
77
78Today almost all real-time embedded software systems are developed in a
79@b{cross development} environment using cross development tools. In the cross
80development environment, software development activities are typically
81performed on one computer system, the @b{build-host} system, while the result of the
82development effort (produced by the cross tools) is a software system that
83executes on the @b{target} platform. The requirements for the target platform are
84usually incompatible and quite often in direct conflict with the requirements
85for the build-host.  Moreover, the target hardware is often custom designed for a
86particular project.  This means that the cross development toolset must allow
87the developer to customize the tools to address target specific run-time
88issues.  The toolset must have provisions for board dependent initialization
89code, device drivers, and error handling code.
90
91The build-host computer is optimized to support the code development cycle with
92support for code editors, compilers, and linkers requiring large disk drives,
93user development windows, and multiple developer connections.  Thus the build-host
94computer is typically a traditional UNIX workstation such as those available
95from SUN or Silicon Graphics, or a PC running either a version of MS-Windows
96or UNIX.  The build-host system may also be required to execute
97office productivity applications to allow the software developer
98to write  documentation, make presentations, or track the project's
99progress using a project management tool.  This necessitates that the
100build-host computer be general purpose with resources such as a
101thirty-two or sixty-four bit processor, large amounts of
102RAM, a  monitor, mouse, keyboard, hard and floppy disk drives, CD-ROM drive,
103and a graphics card.  It is likely that the system will be multimedia capable
104and have some networking capability.
105
106Conversely, the target platform generally has limited traditional computer
107resources.  The hardware is designed for the particular functionality and
108requirements of the embedded system and optimized to perform those tasks
109effectively.  Instead of hard drives and keyboards, it is composed of
110sensors, relays, and stepper motors. The per-unit cost of the target platform
111is typically a critical concern.  No hardware component is included without
112being cost justified.  As a result, the processor of the target system is
113often from a different processor family than that of the build-host system and
114usually has lower performance.  In addition to the processor families
115designed only for use in embedded systems, there are versions of nearly every
116general-purpose processor specifically tailored for real-time embedded
117systems.  For example, many of the processors targeting the embedded market
118do not include hardware floating point units, but do include peripherals such
119as timers, serial controllers, or network interfaces.
120
121@section Resources on the Internet
122
123This section describes various resources on the Internet which are of
124use to RTEMS users.
125
126@c
127@c  Online Tool Documentation
128@c
129
130@subsection Online Tool Documentation
131
132Each of the tools in the GNU development suite comes with documentation.
133It is in the reader's and tool maintainers' interest that one read the
134documentation before posting a problem to a mailing list or news group.
135The RTEMS Project provides formatted documentation for the primary
136tools in the cross development toolset including BINUTILS, GCC,
137NEWLIB, and GDB with the pre-built versions of those tools.
138
139Much of the documentation is available at other sites on the Internet.
140The following is a list of URLs where one can find HTML versions of
141the GNU manuals:
142
143@table @b
144
145@item Free Software Foundation
146@uref{http://www.gnu.org/manual/manual.html,
147http://www.gnu.org/manual/manual.html}
148
149@item Delorie Software
150@uref{http://www.delorie.com/gnu/docs, http://www.delorie.com/gnu/docs}
151
152@end table
153
154
155@subsection RTEMS Mailing List
156
157@uref{mailto:@value{RTEMSUSERS},@value{RTEMSUSERS}}
158
159This is the primary  mailing list for the discussion of issues
160related to RTEMS, including GNAT/RTEMS.  If you have questions
161about RTEMS, wish to make suggestions, track development efforts,
162or just want to pick up hints, this is a good list to monitor.
163If you would like to browse the thousands of messages in the fifteen
164year archive of the mailing list or subscribe to it, please visit
165@uref{http://www.rtems.org/mailman,http://www.rtems.org/mailman} for
166more information,
167
168@subsection GCC Mailing Lists
169
170The GCC Project is hosted at @uref{http://gcc.gnu.org,http://gcc.gnu.org}.
171They maintain multiple mailing lists that are described at the web site
172along with subscription information.
Note: See TracBrowser for help on using the repository browser.