1.3 The Future of Embedded Systems
Until the early 1990s, embedded systems were generally simple, autonomous devices with long product lifecycles. In recent years, however, the embedded industry has experienced dramatic transformation, as reported by the Gartner Group, an independent research and advisory firm, as well as by other sources:
· Product market windows now dictate feverish six- to nine-month turnaround cycles.
· Globalization is redefining market opportunities and expanding application space.
· Connectivity is now a requirement rather than a bonus in both wired and emerging wireless technologies.
· Electronics-based products are more complex.
· Interconnecting embedded systems are yielding new applications that are dependent on networking infrastructures.
· The processing power of microprocessors is increasing at a rate predicted by Moore’s Law, which states that the number of transistors per integrated circuit doubles every 18 months.
If past trends give any indication of the future, then as technology evolves, embedded software will continue to proliferate into new applications and lead to smarter classes of products. With an ever-expanding marketplace fortified by growing consumer demand for devices that can virtually run themselves as well as the seemingly limitless opportunities created by the Internet, embedded systems will continue to reshape the world for years to come.
1.4 Points to Remember
· An embedded system is built for a specific application. As such, the hardware and software components are highly integrated, and the development model is the hardware and software co-design model.
· Embedded systems are generally built using embedded processors.
· An embedded processor is a specialized processor, such as a DSP, that is cheaper to design and produce, can have built-in integrated devices, is limited in functionality, produces low heat, consumes low power, and does not necessarily have the fastest clock speed but meets the requirements of the specific applications for which it is designed.
· Real-time systems are characterized by the fact that timing correctness is just as important as functional or logical correctness.
· The severity of the penalty incurred for not satisfying timing constraints differentiates hard real-time systems from soft real-time systems.
· Real-time systems have a significant amount of application awareness similar to embedded systems.
· Real-time embedded systems are those embedded system with real-time behaviors.
Chapter 2: Basics Of Developing For Embedded Systems
2.1 Introduction
Chapter 1 states that one characteristic of embedded systems is the cross-platform development methodology. The primary components in the development environment are the host system, the target embedded system, and potentially many connectivity solutions available between the host and the target embedded system, as shown in Figure 2.1.
Figure 2.1: Typical cross-platform development environment.
The essential development tools offered by the host system are the cross compiler, linker, and source-level debugger. The target embedded system might offer a dynamic loader, a link loader, a monitor, and a debug agent. A set of connections might be available between the host and the target system. These connections are used for downloading program images from the host system to the target system. These connections can also be used for transmitting debugger information between the host debugger and the target debug agent.
Programs including the system software, the real-time operating system (RTOS), the kernel, and the application code must be developed first, compiled into object code, and linked together into an executable image. Programmers writing applications that execute in the same environment as used for development, called
The areas of focus in this chapter are
· the ELF object file format,
· the linker and linker command file, and
· mapping the executable image onto the target embedded system.
This chapter does not provide full coverage on each tool, such as the compiler and the linker, nor does this chapter fully describe a specific object file format. Instead, this chapter focuses on providing in-depth coverage on the aspects of each tool and the object file format that are most relevant to embedded system development. The goal is to offer the embedded developer practical insights on how the components relate to one another. Knowing the big picture allows an embedded developer to put it all together and ask the specific questions if and when necessary.
2.2 Overview of Linkers and the Linking Process
Figure 2.2 illustrates how different tools take various input files and generate appropriate output files to ultimately be used in building an executable image.
Figure 2.2: Creating an image file for the target system.
The developer writes the program in the C/C++ source files and header files. Some parts of the program can be written in assembly language and are produced in the corresponding assembly source files. The developer creates a makefile for the make utility to facilitate an environment that can easily track the file modifications and invoke the compiler and the assembler to rebuild the source files when necessary. From these source files, the compiler and the assembler produce object files that contain both machine binary code and program data. The archive utility concatenates a collection of object files to form a library. The linker takes these object files as input and produces either an executable image or an object file that can be used for additional linking with other object files. The linker command file instructs the linker on how to combine the object files and where to place the binary code and data in the target embedded system.
