source: rtems/doc/started/intro.t @ 48cd0b8e
Last change on this file since 48cd0b8e was 48cd0b8e, checked in by Joel Sherrill <joel.sherrill@…>, on Oct 2, 2003 at 6:01:48 PM

2003-10-02 Joel Sherrill <joel@…>

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