ABSTRACT:
This paper focuses on all major aspects of one of the most interesting and challenging field of computers, ‘Embedded Systems.’ An Embedded system is a combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a specific function. Embedded systems are microcomputer systems with software self-contained in Read Only Memory (ROM) and without a readily recognizable software operating system. Embedded systems are most often “dedicated” microprocessor environments with single functional utilization. Frequently, the systems are "black boxes" associated with manufacturing equipment, process control devices, or similar industrial hardware. Embedded systems contain microcomputer systems with software that is totally ROM-based, and they usually have programmable interfaces. The capabilities of individual systems, the devices attached, and the methods of gathering information from the operator and of disseminating information to the operator (operator interface), are ostensibly unique, but have similar conceptual and technical characteristics. An embedded system is a component within a larger system. The embedded systems are connected by certain communication networks and are used in a vast array of applications across many industries, mostly will be encountered by consultants and others outside a specific market environment for plant floor equipment or process control. Those who deal with larger and more complex systems frequently have other engineering focus, greater workloads, and a myriad of other reasons to ask for occasional help outside.
INTRODUCTION:
Embedded System
Any device or collection of devices that contain one or more dedicated computers, microprocessors, or micro controllers is called an Embedded System. Device(s) may be local and also may be distributed. Embedded computing devices have rigidly defined operational bounds. These are dedicated to specific tasks having rich variety of microprocessors and the designs are cost sensitive.
This is in direct contrast to the personal computer in the family room. It too comprises of computer hardware and software and mechanical components (disk drives, for example). However, a personal computer is not designed to perform a specific function. Rather, it is able to do many different things. Many people use the term general-purpose computer to make this distinction clear. As shipped, a general-purpose computer is a blank slate; the manufacturer does not know what the customer will do with it. One customer may use it for a network file server, another may use it exclusively for playing games, and a third may use it to write the next great American novel.
At the possible risk of confusing you, it is important to point out that a general-purpose computer is itself made up of numerous embedded systems. For example, a computer consists of a keyboard, mouse, video card, modem, hard drive, floppy drive, and sound card-each of which is an embedded system. Each of these devices contains a processor and software and is designed to perform a specific function.
In a well designed Embedded system, the existence of the processor and software could not be completely noticed by a user of the device. Such is the case for a microwave oven, VCR, or alarm clock. In some cases, it would even be possible to build an equivalent device that does not contain the processor and software. This could be done by replacing the combination with a custom integrated circuit that performs the same functions in hardware. However, a lot of flexibility is lost when a design is hard-coded in this way. It is much easier, and cheaper, to change a few lines of software than to redesign a piece of custom hardware.
A Typical Embedded System
Technically, there are prevalent and common characteristics of embedded systems. From a programmer's perspective the following components are minimum: Central Processing Unit (CPU), Random Access Memory (RAM), Programmable Read Only Memory (PROM) or Erasable PROM (EPROM), and Input/Output (I/O) space.
Since many embedded systems contain time-critical functions, another often-essential component is one or more system timers. Timer units are available in a variety of commercial forms. For boxes built around the VME or STD system bus architectures, timers are frequently included as features of CPU boards manufactured for these systems, or as separate specialized "timer boards." CPUs sometimes provide timers for programming purposes; Intel's 80186, for example, has three.
Device interaction is the sole reason for the system's existence, hence application-specific devices are also ultimate system essentials. One or more devices will be used for operator interaction with the system (operator interface). All devices will be attached to the system via the I/O space. From the programmer's perspective, a baseline embedded system is shown in figure below.
Obviously, the devices above can vary drastically from environment to environment. For the spray equipment mentioned earlier, there might be multiple heaters, pumps, indicator lights, and interlocks as a minimum. A serial communications interface could allow remote configuration, where a display and keypad would be required. Feedback from a conveyer could allow automatic adjustment of pump pressure for varying production-line speeds. For a carpet metering and cutting machine, there could be multiple photoeyes and conveyer motors. A measuring wheel, a cutting mechanism, a display, and a keypad would be desirable. Several serial communications interfaces could allow centralized reporting and/or bar-coded inputs for preprinted orders.
Figure: Baseline Embedded System
Figure: Typical Embedded System
Operator interfaces are equally disparate devices. Control boxes for large plant floor machinery sometimes use serial interfaces to giant high-resolution color screens sporting Carroll infrared touch technology. The huge physical size allows a single individual in the plant to monitor several machines from a comfortable distance. Stand-alone embedded units typically have small keypads and small liquid crystal diode (LCD) displays that show only a few lines of text, or only a single text line of a few characters. This allows more economical construction when feasible. For further economy under the right circumstances, interfaces may even be digital switches for operator input with only indicator lights for problem determination.
With these common traits revealed, there is still no way to precisely define those systems that fall into the embedded category. A comprehensive and concise definition of embedded systems probably does not exist. Even the United States Department of Defense does not attempt definition within its series of "Military Standard" publications. If the operating system were removed from a typical personal computer (PC), and all the programs that were to be executed in a given environment were made to reside in ROM, then the modified PC might be considered an embedded system with processing dedicated to predetermined functions, but this is a stretch.
Better examples are found inside consumer products. Many American homes have microwave ovens, dishwashers, security systems, audiovisual entertainment centers, or communications equipment that use programmable embedded systems to monitor or control these units. The owner can "program" features of the device via touch panels, buttons, or hand-held remote controllers to accomplish a desired end, and the system does the rest. Some controlled operations are sequential, some are timed, and some are one-shot commands to the equipment.
Most new automobiles contain a computer "brain" which is an embedded system that has been encapsulated within silicon or epoxy compound to provide a small electronic "brick." Using sensors within the gasoline metering system, this brick-brain can monitor and massage gasoline flow rates and provide an instantaneous display to the driver. The display can indicate the current consumption (miles per gallon to be anticipated) under the existing driving conditions. If the driver depresses or releases the accelerator, the display is updated instantly to the changed conditions. The brain can also provide other information such as the current state of door locks, seat belts, and leveling of the vehicle if the load shifts. This information can be displayed visually and/or audibly depending on how the system hardware is designed and programmed.
In the industrialized sector, modern plants have a number of electronic boxes controlling and monitoring many different types of machinery and equipment. Very often the controls are built as integral parts of specialized manufacturing devices or systems. Virtually all of these controlling units are embedded systems made by companies who are expert in specific manufacturing technologies.
The Up Side of Embedded Programming
It is precisely the diversity of devices and the varying depth of knowledge required about each one that makes embedded systems programming so attractive to those that choose the field. There is a constant learning process. Fun for the initiated includes the substantial timing challenges found in the "real time" aspects of device coordination. In addition, since computer operating systems shield programmers from many low-level functions of hardware and peripheral I/O, the programming of embedded systems requires more in-depth knowledge of how platform components function and interact than does programming under an operating system. Embedded systems programming is much closer to the hardware.
The makeup of excellent programmers is still an elusive compound. Some are graduate musicians and airplane pilots rather than computer engineering majors. Whatever the ingredients, they share the common trait of project dedication born of genuine interest. All enjoy savoring the fruits of their labor when, for example, a control unit does exactly what it is supposed to do. A casual observer looking at computer-controlled machinery would see only moving parts; the programmer sees the coordinated execution of each code thread performing its function. Sometimes this is reward enough; but for those programmers with a less technical bent, embedded systems programming can be a real pain. Some things are better unknown, and, to many, this includes device details and other aspects of the field.
Specialized Microchips
Intel and other chip manufacturers are currently making families of specialized chips for the embedded systems market. Intel's MCS-48 family, for example, consists of integrated microcomputer systems. A single integrated circuit contains the processor (CPU), RAM, PROM, a timer, and I/O space--basic essentials of an embedded system. Another Intel chip family, the MCS-96, has targeted the market of high-speed control functions. The family uses 16-bit processors with on-chip features that include a high-speed I/O subsystem, EPROM, a 10-bit A/D converter, five 8-bit I/O ports, and a 16-bit watchdog timer, among other things.
More recently, Intel's 80960 32-bit chip family, was developed from scratch for embedded control applications. It has been touted to eliminate architectural obstacles to state-of-the-art implementation techniques that allow parallel and out-of-order instruction execution. The Intel 80960KA, for example, uses Reduced Instruction Set Computer (RISC) technology in conjunction with a 32-bit processor, and is advertised by Intel as having a 512-byte instruction cache, a built-in interrupt controller, multiple parallel execution units, and an overall capability of execution rates in excess of 9.4 million instructions per second, and these are only a subset of the touted features.
Specialized chips like these, with such advanced and attractive features, simply did not exist until very recently. Such current and rapidly unfolding technological innovations indicate that the first full step of microcomputer evolution is not yet completed. With the proliferation of microcomputer systems in general and embedded systems in particular, newer technologies addressing the unique needs of embedded systems projects will constantly emerge; but, despite advances in hardware technology, the essential techniques of programming will remain unchanged.
Hardware evolution can reduce the quantitative code required of programmers. This is easily seen when hardware evolution is visualized as the evolution of board-level products containing state-of-the-art chip sets and sophisticated firmware.
Embedded Operating Systems
Earlier it was stated that embedded systems typically do not utilize computer operating systems. This is essentially a true statement; however, there are a number of specialized embedded operating systems currently in use. Most of these software systems could be more precisely defined as "real time executives"--not full-blown operating systems. Frequently they are task schedulers that allow timed, pre-emptive task scheduling of large embedded systems. Sometimes they are selected with the hopes of reducing the quantitative software development required for a particular system. Occasionally, they are highly necessary supervisors of specialized systems. The most common physical trait of these systems is that they require some interface convention of programmers. Typically, primitive descriptive tables are filled in by the programmer in order to identify task properties to the operating system. The operating system will include a library of task control interface routines that must be used by the programmer as specified by the system documentation. When the compiled software modules are linked together, operating system modules are included as a part of the final, executable module.
Most of these embedded operating systems will require specified areas of RAM for task control blocks and similar management functions. Some even duplicate the interrupt vector table. Regardless, these system-specific peculiarities are always well-documented and explained.
An Overview of Embedded Software
Normally there is no mass storage device such as a disk drive attached to an embedded system. The programming code is not loaded from hard disk into RAM in order to be executed by the CPU. Typically, embedded systems code is stored internally in EPROM where it can be directly read by the CPU. Constant data items are also stored in EPROM’s. Volatile data items are expected to be at specified RAM addresses, and data items to be retained for indefinite periods are normally kept in nonvolatile RAM (NVRAM). NVRAM is frequently battery-backed RAM.
At system power-up, Intel-based embedded systems typically execute a single assembly language software instruction which has been placed by the programmer at a designated CPU-specific address. This instruction normally causes a code "jump" to the program starting point. The starting point would be the EPROM location of the assembly language start-up module that is necessary to initialize volatile RAM and perform other desired hardware housekeeping functions before calling the MAIN() C language function. Motorola CPUs typically require that the initial supervisor stack pointer and program starting address be located in the first eight bytes of the interrupt vector table (memory location 0). At system power-up the stack pointer and program counter are loaded from location 0 and execution commences at the specified program counter address, which would be the location of the start-up module.
Once the start-up module has called the MAIN () function, embedded systems code frequently becomes real time critical and interrupt intensive. In less encountered cases, embedded systems can even be on-line. Interrupts and timing issues are addressed later, but on-line issues are not presented in this text. Of course, in order to write the start-up module, to address any RAM or ROM contained in the system, and to communicate with any peripheral equipment, the hardware must be defined in terms that the software can understand. One of the first project communications tasks of the hardware engineer is to provide descriptive hardware information to the software engineer.
Real-Time Systems
One subclass of embedded systems is worthy of an introduction at this point. As commonly defined, a real-time system is a computer system that has timing constraints. In other words, a real-time system is partly specified in terms of its ability to make certain calculations or decisions in a timely manner. These important calculations are said to have deadlines for completion. And, for all practical purposes, a missed deadline is just as bad as a wrong answer.
The issue of what happens if a deadline is missed is a crucial one. For example, if the real-time system is part of an airplane's flight control system, it is possible for the lives of the passengers and crew to be endangered by a single missed deadline. However, if instead the system is involved in satellite communication, the damage could be limited to a single corrupt data packet. The more severe the consequences, the more likely it will be said that the deadline is "hard" and, thus, the system a hard real-time system. Real-time systems at the other end of this continuum are said to have "soft" deadlines.
DESIGN REQUIREMENTS:
Processing power: The amount of processing power necessary to get the job done. A common way to compare processing power is the MIPS (millions of instructions per second) rating. If two processors have ratings of 25 MIPS and 40 MIPS, the latter is said to be the more powerful of the two. However, other important features of the processor need to be considered. One of these is the register width, which typically ranges from 8 to 64 bits. Today's general-purpose computers use 32- and 64-bit processors exclusively, but embedded systems are still commonly built with older and less costly 8- and 16-bit processors.
Memory: The amount of memory (ROM and RAM) required to hold the executable software and the data it manipulates. Here the hardware designer must usually make his best estimate up front and be prepared to increase or decrease the actual amount as the software is being developed. The amount of memory required can also affect the processor selection. In general, the register width of a processor establishes the upper limit of the amount of memory it can access. Of course, the smaller the register width, the more likely it is that the processor employs tricks like multiple address spaces to support more memory. Several thousand bytes is a more likely minimum, even for an 8-bit processor.
Development cost: The cost of the hardware and software design processes. This is a fixed, one-time cost, so it might be that money is no object (usually for high-volume products) or that this is the only accurate measure of system cost (in the case of a small number of units produced).
Number of units: The tradeoff between production cost and development cost is affected most by the number of units expected to be produced and sold. For example, it is usually undesirable to develop your own custom hardware components for a low-volume product.
Expected lifetime: How long must the system continue to function (on average)? This affects all sorts of design decisions from the selection of hardware components to how much the system may cost to develop and produce.
Reliability: How reliable must the final product be? If it is a children's toy, it doesn't always have to work right, but if it's a part of a space shuttle or a car, it had sure better do what it is supposed to each and every time. In addition to these general requirements, there are the detailed functional requirements of the system itself.
Common Design Requirements for Embedded Systems
| Criterion | Low | Medium | High |
| Processor | 4- or 8-bit | 16-bit | 32- or 64-bit |
| Memory | < 16 KB | 64 KB to 1 MB | > 1 MB |
| Development cost | < $100,000 | $100,000 to $1,000,000 | > $1,000,000 |
| Production cost | < $10 | $10 to $1,000 | > $1,000 |
| Number of units | < 100 | 100-10,000 | > 10,000 |
| Expected lifetime | days, weeks, or months | years | decades |
| Reliability | may occasionally fail | must work reliably | must be fail-proof |
CHARACTERISTICS:
- Designs are cost-sensitive
- Have real-time performance constraints
- Used with Real-Time Operating Systems (RTOS)
- Software failure can be life-threatening
- May have constraints on power consumption
- Operate over a wide-range of environmental conditions
- Fewer system resources then a desktop system
- All code might be stored in ROM
- Require specialized design tools
- May have on-chip debugging resources
FEATURES:
• Response
• Security
• Availability
• Cost
• Size/Weight
• Survivability
• Maintainability
• Throughput
• Testability
• Low power
• Reliability
• Safety
CONCLUSION:
Embedded system is application dependent program and has no architectural link to standard platforms. Every embedded design is unique and have typically moderate to severe real time constraints. The hardware and software are highly integrated and interrelated. Embedded system may or may not have the operating system services available. Embedded system uses more constraints, different tools and because there is no application form to be insulated from hardware, the hardware/software connection is easier.
REFERENCES:
EE Toolbox (http://www.eetoolbox.com/ebox.htm)
No comments:
Post a Comment