Changeset 5741c94 in rtems

Apr 11, 1998, 2:54:09 PM (22 years ago)
Joel Sherrill <joel.sherrill@…>
4.10, 4.11, 4.8, 4.9, master

Added cross development and real-time embedded systems background.

2 edited


  • doc/started/intro.t

    r8e8676da r5741c94  
    2222@end itemize
     24The remainder of this chapter provides background information on real-time
     25embedded systems and cross development.  If you are not familiar with either
     26of these areas, please read them.  This will help familiarize you with the
     27types of systems RTEMS is designed to be used in and the cross development
     28process used when developing RTEMS applications.
     30@section Real-Time Embedded Systems
     32Real-time embedded systems are found in practically every facet of our
     33everyday lives.  Today's systems range from the common telephone, automobile
     34control systems, and kitchen appliances to complex air traffic control
     35systems, military weapon systems, an d production line control including
     36robotics and automation. However, in the current climate of rapidly changing
     37technology, it is difficult to reach a consensus on the definition of a
     38real-time embedded system. Hardware costs are continuing to rapidly decline
     39while at the same time the hardware is increasing in power and functionality.
     40As a result, embedded systems that were not considered viable two years ago
     41are suddenly a cost effective solution. In this domain, it is not uncommon
     42for a single hardware configuration to employ a variety of architectures and
     43technologies. Therefore, we shall define an embedded system as any computer
     44system that is built into a larger system consisting of multiple technologies
     45such as digital and analog electronics,  mechanical devices, and sensors.
     47Even as hardware platforms become more powerful, most embedded systems are
     48critically dependent on the real-time software embedded in the systems
     49themselves.  Regardless of how efficiently the hardware operates, the
     50performance of the embedded real-time software determines the success of the
     51system.  As the complexity of the embedded hardware platform grows, so does
     52the size and complexity of the embedded software. Software systems must
     53routinely perform activities which were only dreamed of a short time ago.
     54These large, complex, real-time embedded applications now commonly contain
     55one million lines of code or more.
     57Real-time embedded systems have a complex set of characteristics that
     58distinguish them from other software applications.  Real-time embedded
     59systems are driven by and must respond to real world events while adhering to
     60rigorous requirements imposed by the environment with which they interact.
     61The correctness of the system depends not only on the results of
     62computations, but also on the time at which the results are produced.  The
     63most important and complex characteristic of real-time application systems is
     64that they must receive and respond to a set of external stimuli within rigid
     65and critical time constraints.
     67A single real-time application can be composed of both soft and hard
     68real-time components. A typical example of a hard real-time system is a
     69nuclear reactor control system that must not only detect failures, but must
     70also respond quickly enough to prevent a meltdown. This application also has
     71soft real-time requirements because it may involve a man-machine interface.
     72Providing an interactive input to the control system is not as critical as
     73setting off an alarm to indicate a failure condition. However, th e
     74interactive system component must respond within an acceptable time limit to
     75allow the operator to interact efficiently with the control system.
     77@section Cross Development
     79Today almost all real-time embedded software systems are developed in a
     80@b{cross development} environment using cross development tools. In the cross
     81development environment, software development activities are typically
     82performed on one computer system, the @b{host} system, while the result of the
     83development effort (produced by the cross tools) is a software system that
     84executes on the @b{target} platform. The requirements for the target platform are
     85usually incompatible and quite often in direct conflict with the requirements
     86for the host.  Moreover, the target hardware is often custom designed for a
     87particular project.  This means that the cross development toolset must allow
     88the developer to customize the tools to address target specific run-time
     89issues.  The toolset must have provisions for board dependent initialization
     90code, device drivers, and error handling code.
     92The host computer is optimized to support the code development cycle with
     93support for code editors, compilers, and linkers requiring large disk drives,
     94user development windows, and multiple developer connections.  Thus the host
     95computer is typically a traditional UNIX workstation such as are available
     96from SUN or Silicon Graphics, or a PC running either a version of MS-Windows
     97or UNIX.  The host system may also be required to execute office productivity
     98applications to allow the software developer to write  documentation, make
     99presentations, or track the project's progress using a project management
     100tool.  This necessitates that the host computer be general purpose with
     101resources such as a thirty-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.
     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  driverss 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 host system and
     114usually has lower performance.  In addition to the processor families
     115targeted only for use in embedded systems, there are versions of nearly every
     116general-purpose process or 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.
  • doc/started_ada/intro.t

    r8e8676da r5741c94  
    1818@itemize @bullet
    19 @item GNU C/C++ Cross Compilation Tools for RTEMS on your host system
     19@item GNAT/RTEMS Cross Compilation Tools on your host system
    2020@item RTEMS OS for the target host
    2121@item GDB Debugger
Note: See TracChangeset for help on using the changeset viewer.