Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
computer science technology
Active In SP

Posts: 740
Joined: Jan 2010
24-01-2010, 05:46 PM

.doc   EMBEDDED SYSTEMS full report.DOC (Size: 77 KB / Downloads: 970)


Many embedded systems have substantially different design constraints than desktop computing applications. No single characterization applies to the diverse spectrum of embedded systems. However, some combination of cost pressure, long life-cycle, real¬-time requirements, reliability requirements, and design culture dysfunction can make it difficult to be successful applying traditional computer design methodologies and tools to embedded applications. Embedded systems in many cases must be optimized for life-cycle and business-driven factors rather than for maximum computing throughput. There is currently little tool support for expanding embedded computer design to the scope of holistic embedded system design. However, knowing the strengths and weaknesses of current approaches can set expectations appropriately, identify risk areas to tool adopters, and suggest ways in which tool builders can meet industrial needs.
If we look around us, today we see numerous appliances which we use daily, be it our refrigerator , the microwave oven, cars, PDAs etc. Most appliances today are powered by something beneath the sheath that makes them do what they do. These are tiny microprocessors, which respond to various keystrokes or inputs. These tiny microprocessors, working on basic assembly languages, are the heart of the appliances. We call them embedded systems. Of all the semiconductor industries, the embedded systems market place is the most conservative, and engineering decisions here usually lean towards established, low risk solutions. Welcome to the world of embedded systems, of computers that will not look like computers and wonâ„¢t function like any thing we are familiar with.
As the name signifies, an Ëœembedded systemâ„¢ is built into a noncomputing device, say a car, TV or toy. We can define an embedded system as a computing device, built in to a device that is not a computer, and meant for doing specific computing tasks. In general engineering terms, embedded systems are used for the control of industrial or physical processes. In computer science terms, embedded systems are distributed reactive systems. Typically these systems have to react to stimuli from their environment in real time. This can be of high importance in situations where a lot of signal processing must be carried out on the inputs inorder to compute the outputs. e.g., multimedia applications.
Embedded systems have been around us for about as long as computer themselves. These were first used in the late 1960s to control electro mechanical telephone switches. As computer industry has moved towards smaller systems over the last decade or so, embedded systems have also moved along with this trend.
Embedded systems are divided into autonomous, realtime, networked & mobile categories.
Autonomous systems: They function in standalone mode. Many embedded systems used for process control in manufacturing units& automobiles fall under this category.
Realtime embedded systems: These are required to carry out specific tasks in a specified amount of time. These systems are extensively used to carryout time critical tasks in process control.
Networked embedded systems: They monitor plant parameters such as temperature, pressure and humidity and send the data over the network to a centralized system for on line monitoring.
Mobile gadgets: Mobile gadgets need to store databases locally in their memory. These gadgets imbibe powerful computing & communication capabilities to perform realtime as well as nonrealtime tasks and handle multimedia applications.
The embedded system is a combination of computer hardware, software, firmware and perhaps additional mechanical parts, designed to perform a specific function. A good example is an automatic washing machine or a microwave oven. Such a system is in direct contrast to a personal computer, which is not designed to do only a specific task. But an embedded system is designed to do a specific task with in a given timeframe, repeatedly, endlessly, with or without human interaction.
Good software design in embedded systems stems from a good understanding of the hardware behind it. All embedded systems need a microprocessor, and the kinds of microprocessors used in them are quite varied. A list of some of the common microprocessors families are: The Zilog Z8 family, Intel 8051/X86 family, Motorola 68K family and the power PC family. For processing of information and execution of programs, embedded system incorporates microprocessor or micro- controller. In an embedded system the microprocessor is a part of final product and is not available for reprogramming to the end user. An embedded system also needs memory for two purposes, to store its program and to store its data. Unlike normal desktops in which data and programs are stored at the same place, embedded systems store data and programs in different memories. This is simply because the embedded system does not have a hard drive and the program must be stored in memory even when the power is turned off. This type of memory is called ROM. Embedded applications commonly employ a special type of ROM that can be programmed or reprogrammed with the help of special devices.
UMS Hardware:
A common obstacle for developers has been the need to develop different sets of hardware and software for different devices. An intelligent washing machine uses a hardware chip different from that used by an intelligent wrist watch. In addition, the software running on the hardware chip is different. This often results in increased costs and time taken for development.
The Universal Micro System(UMS) from cradle technologies is a solution for this problem. UMS is a general purpose chip built around a simple instruction set. It can be used to develop applications for embedded devices because all the functionality required for a specific device can be modeled in the software. Since the major functionality provided in UMS is through software, the processor and memory units must be very fast and the input, output units must be programmable and versatile. UMS uses a large number of high speed, low power and small RISC based processors on a single chip. Each processing element coupled with two digital signal processors form a multi stream processor(MSP), which processes voluminous chunks of data. Developing on UMS represents a significant infrastructure cost savings, dramatic decrease in time to market and an unprecedented opportunity to combine many functions and redefine products in the market.
UMS hardware architecture:

Embedded software has grown complex and pervasive enough to attract the attention of computer scientists. Embedded softwareâ„¢s main task is to engage the physical world interacting directly with sensors & actuators. The most pressing problem is how to adapt existing software techniques to meet the challenges of the physical world. Software for embedded systems must handle problems beyond those found in application software for desktops or mainframe computers. Embedded software often has several things to do at once - respond to external events, cope with unusual conditions without human intervention while being subjected to deadlines. So embedded software is harder to design. Embedded systems are increasingly networked which introduced significant complications such as downloadable modules that dynamically reconfigure the system. Moreover, consumers demand ever more elaborate functionality which greatly increases software complexity. These systems can no longer be designed by a single engineer, fine tuning tens of kilobytes of assembly code. Embedded software design is art as much as it is science. We must know how fast our system operates and know how critical it is to meet each deadline. If deadlines are absolute, then it is a hard real time system else it is a soft real time system.
Functionality has steadily shifted from hardware to software. C has become the language of choice for embedded programmers, because it has the benefit of processor independence. Languages such as C++, Java are also used. Home devices will flourish best if they present a uniform API to application programmers, and an ideal interface is Java. Open Service Gateway Initiative(OSGI) , a java based system that combines services with event on security mechanisms, is defining a set of open standard software application interfaces for building Open Service Gateways including Residential Gateways . Embedded Graphical User Interface™s (GUI) are growing more elaborate day by day. Developers now have to contend with such arcana as a color pallet. In some applications, an embedded GUI has to compete with mechanical controls. In luxury cars, for e.g, Graphical displays are starting to replace mechanical speedo meters and tacho meters.Visualization tools are designed to find bugs that are hard to find with theusual Breakpoint and explore debugging paradigm. They work beautifully on Heisenberg bugs “ so called because they disappear when we start looking for them.
Any source code written in C or C++ or assembly language must be converted into an executable image that can be loaded onto a ROM chip. For this purpose three distinct steps are involved.
Cross compiled or assembled to generate object files.
Object files must be linked into a relocatable program.
Physical memory address must be assigned to the relocatable program.
To run any software we need operating system. Embedded systems do not require a complete operating system, which may make the system bulky, but only the basic functionalities of the operating system in a real time environment “ RTOS. Off-the-shelf operating systems for these systems began to appear in the late 1970™s, and today several dozen viable options are available.Embedded operating systems are available in variety of flavours: Windows NT, LINUX, Windows CE 3.0, PalmOS, QNX, ROMDOS, JBED, RT kernel, Tiny BIOS, Turbo task, Nucleus plus/Tasking, Diamond,ThreadX (#$@%) etc. Out of these , a few major players have emerged , such as Vxworks, PSOS, neculeus, windows CE, ThreadX and linux. ˜Inferno™ and ˜Chai™ are the two popular environments that are used to develop applications.
Embedded Databases:
Embedded Databases are in software applications and in hardware devices, both mobile and fixed. The purpose of Embedded Database is data storage and retrieval with minimum intervention and minimum system impact. The rapid increase in the number of Telecomputers, the explosive growth of E-commerce and general migration to wireless technologies have put Embedded Database development on the IT short list. In a world of mobile computers and smart devices , size matters because memory and storage are very limited. A key factor is a small memory foot print. Embedded database vendors and developers tend to focus on smallness of their achievements. Sybaseâ„¢s Ultra Lite, a version of SQL which is any where portable database has a foot print of 50 kilobytes.
Ëœe2Bâ„¢: The internet gives machines a way to communicate. For embedded internet, communication channels are seen in technologies such as blue tooth, CEbus, upnp and TCP/IP; linguistic mechanisms in notions such as java RMI; HTTP & SNMP. Embedding internet technologies is also called as Ëœe2Bâ„¢ or embedded to business.
Many authors use software and firmware in the same sense. Actually firmware consists of microcode programs executed from very high speed control storage. Commonly used object programs placed in ROMs and PROMs are also some times referred to as firmware. The problem with any approach to the field firmware updates is that if the upgrade contains a flaw, the target system may become an expensive doorstop. Many of the pitfalls are obvious and straight forward, but some insidious defects donâ„¢t appear until after a product has been deployed. Any well designed firmware upgrade system must be able to recover from user errors and other catastrophic events to the fullest extent possible. The best way to accomplish this is to implement a fundamentally sound firmware update strategy that avoids these problems entirely. A microprogrammer is a system level description of how an embedded system beheves before, during and after the firmware update process. This is designed to help avoid many of the problems to downloadable firmware. ËœFlexwareâ„¢ is a flexible firmware development environment.
Other common parts found on many embedded systems:
¢ UART& RS232
¢ ASIC™s& FPGA™s
¢ Watch dog timer e.t.c.
Design process:
Embedded system design is a quantitative job. The pillars of the system design methodology are the separation between function and architecture, is an essential step from conception to implementation. In recent past, the search and industrial community has paid significant attention to the topic of hardware-software (HW/SW) codesign and has tackled the problem of coordinating the design of the parts to be implemented as software and the parts to be implemented as hardware avoiding the HW/SW integration problem marred the electronics system industry so long. In any large scale embedded systems design methodology, concurrency must be considered as a first class citizen at all levels of abstraction and in both hardware and software. Formal models & transformations in system design are used so that verification and synthesis can be applied to advantage in the design methodology. Simulation tools are used for exploring the design space for validating the functional and timing behaviors of embedded systems.
Hardware can be simulated at different levels such as electrical circuits, logic gates, RTL e.t.c. using VHDL description. In some environments software development tools can be coupled with hardware simulators, while in others the software is executed on the simulated hardware. The later approach is feasible only for small parts of embedded systems.


Design of an embedded system using Intelâ„¢s 80C188EB chip is shown in the figure. Inorder to reduce complexity, the design process is divided in four major steps: specification, system synthesis, implementation synthesis and performance evaluation of the prototype.
Specification: During this part of the design process, the informal requirements of the analysis are transformed to formal specification using SDL.
System synthesis: For performing an automatic HW/SW partitioning, the system synthesis step translates the SDL specification to an internal system model switch contains problem graph& architecture graph. After system synthesis, the resulting system model is translated back to SDL.
Implementation synthesis: SDL specification is then translated into conventional implementation languages such as VHDL for hardware modules and C for software parts of the system.
Prototyping: On a prototyping platform, the implementation of the system under development is executed with the software parts running on multiprocessor unit and the hardware part running on a FPGA board known as phoenix, prototype hardware for Embedded Network Interconnect Accelerators.
Embedded systems are finding their way into robotic toys and electronic pets, intelligent cars and remote controllable home appliances. All the major toy makers across the world have been coming out with advanced interactive toys that can become our friends for life. ËœFurbyâ„¢ and ËœAIBOâ„¢ are good examples at this kind. Furbies have a distinct life cycle just like human beings, starting from being a baby and growing to an adult one. In AIBO first two letters stands for Artificial Intelligence. Next two letters represents robot . The AIBO is robotic dog. Embedded systems in cars also known as Telematic Systems are used to provide navigational security communication & entertinment services using GPS, satellite. Home appliances are going the embedded way. LG electronics digital DIOS refrigerator can be used for surfing the net, checking e-mail, making video phone calls and watching TV.IBM is developing an air conditioner that we can control over the net. Embedded systems cover such a broad range of products that generalization is difficult. Here are some broad categories.
Aerospace and defence electronics: fire control, radar, robotics/sensors, sonar.
Automotive: autobody electronics, auto power train, auto safety, car information systems.
Broadcast & entertainment: Analog and digital sound products, camaras, DVDs,
Set top boxes, virtual reality systems, graphic products.
Consumer/internet appliances: Business handheld computers, business network computers/terminals, electronic books, internet smart handheld devices, PDAs.
Data communications: Analog modems, ATM switches, cable modems, XDSL modems, Ethernet switches, concentrators.
Digital imaging: Copiers, digital still cameras, Fax machines, printers, scanners.
Industrial measurement and control: Hydro electric utility research & management traffic management systems, train marine vessel management systems.
Medical electronics: Diagnostic devices, real time medical imaging systems, surgical devices, critical care systems.
Server I/O: Embedded servers, enterprise PC servers, PCI LAN/NIC controllers, RAID devices, SCSI devices.
Telecommunications : ATM communication products, base stations, networking switches, SONET/SDH cross connect, multiplexer.
Mobile data infrastructures: Mobile data terminals, pagers, VSATs, Wireless LANs, Wireless phones.
Embedded systems have virtually entered every sphere of our life, right from the time we work out on tread mills to the cars that we drive today. The possibilities in this field are only limited by our imagination.Many of the embedded systems are managed by human controllers by some sort of man machine interface-for example a cash register,a cell phone, a TV screen or a PC interface.It is this MMI that often represents the most costly investment in the systemâ„¢s development,interms of both time and money.
[1] Embedded Systems Programming. Miller Freeman, San Francisco, ISSN 1040-3272.
[2] Daniel D. Gajski. Frank Vahid, Sanjiv Narayan & Jie Gong, Specification and Design of Embedded Systems. PTR Prentice Hall, Englewood Cliffs NJ, 1994.
[3J Jack Ganssle, Art of programming Embedded Systems, Academic Press, San Diego. 1992.
[4J Shem-Tov Levi & Ashok Agrawala, Fault Tolerant System Design, McGraw¬Hill, New York, 1994.
[5] Nancy Leveson, Safeware: system safety and computers, Addison-Wesle,1994..
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
seminar topics
Active In SP

Posts: 559
Joined: Mar 2010
30-03-2010, 12:48 PM

1. Introduction
We live in a world today in which software plays a critical part. The most critical soft ware is not running on large systems and PCs. rather, it runs inside the infrastructure and in the devices that we use every day. Our transportation, communications, and energy systems won't work if the embedded software contained in our cars, phones, routers and power plants crashes.
Evolution of a software system is a natural process. In most systems, evolution takes place during the maintenance phase of their life cycles. Those systems that have reached their limit in evolution have usually reached their end of useful life and may have to be replaced. However, there are systems in which evolution occurs during the operational phase of their life cycles. Such systems are designed to evolve while in use or, in other words, be adaptable. Semantically adaptable systems are of particular interest to industry as such systems often times adapt themselves to environment change with little or no intervention from their developing or maintaining organization. Since embedded systems usually have a restricted hardware configuration, it is difficult to apply the techniques developed for non-embedded systems directly to embedded systems. This paper focuses on evolution through adaptation and develops the concepts and techniques for semantic evolution in embedded systems. As the first step in the development of a software solution, architectures of software systems themselves have to be made semantically evolvable. In this paper we explore various architectural alternatives for the semantic evolution of embedded systems-- these architectures are based on four different techniques that we have identified for semantic evolution in embedded systems. The development of these architectures follows the systematic, process provided by the non-functional requirement (NFR) framework, which also permits the architectures to be rated in terms of their evolvability. As the field of embedded systems is vast, this paper concentrates on those embedded systems that can be remotely controlled. In this application domain the embedded system is connected to an external controller by a communication link such as Ethernet, serial, radio frequency, etc., and receives commands from and sends responses to the external controller via the communication link. The architectures developed in this paper have been partly validated by applying them in a real embedded system--a test instrument used for testing cell phones. These architectures and techniques for semantic evolution in this application domain give a glimpse of what can be done in achieving semantic evolution in software-implemented systems.
Approximately 3 billion embedded CPUs are sold each year, with smaller (4-, 8-, and 16-bit) CPUs dominating by quantity and aggregate dollar amount [1]. Yet, most research and tool development seems to be focused on the needs of high-end desktop and military/aerospace embedded computing. This paper seeks to expand the area of discussion to encompass a wide range of embedded systems.
The extreme diversity of embedded applications makes generalizations difficult. Nonetheless, there is emerging interest in the entire range of embedded systems and the related field of hardware/software codesign.
This paper and the accompanying tutorial seek to identify significant areas in which embedded computer design differs from more traditional desktop computer design. They also present "design challenges" encountered in the course of designing several real systems. These challenges are both opportunities to improve methodology and tool support as well as impediments to deploying such support to embedded system design teams. In some cases research and development has already begun in these areas -- and in other cases it has not.
The observations in this paper come from the author's experience with commercial as well as military applications, development methodologies, and life-cycle support. All characterizations are implicitly qualified to indicate a typical, representative, or perhaps simply an anecdotal case rather than a definitive statement about all embedded systems. While it is understood that each embedded system has its own set of unique requirements, it is hoped that the generalizations and examples presented here will provide a broad-brush basis for discussion and evolution of CAD tools and design methodologies.
An embedded system is a special-purpose computer system designed to perform one or a few dedicated functions, often with real-time computing constraints. It is usually embedded as part of a complete device including hardware and mechanical parts. In contrast, a general-purpose computer, such as a personal computer, can do many different tasks depending on programming. Embedded systems have become very important today as they control many of the common devices we use.
Since the embedded system is dedicated to specific tasks, design engineers can optimize it, reducing the size and cost of the product, or increasing the reliability and performance. Some embedded systems are mass-produced, benefiting from economies of scale.
Physically, embedded systems range from portable devices such as digital watches and MP3 players, to large stationary installations like traffic lights, factory controllers, or the systems controlling nuclear power plants. Complexity varies from low, with a single microcontroller chip, to very high with multiple units, peripherals and networks mounted inside a large chassis or enclosure.
The design of this invisible, embedded software is crucial to all of us. Yet, there has been a real shortage of good information as to effective design and implementation practices specific to this very different world. Make no mistake, it is indeed different and often more difficult to design embedded software than more traditional programs. Time, and the interaction of multiple tasks in real-time, must be managed.
In general, "embedded system" is not an exactly defined term, as many systems have some element of programmability. For example, Handheld computers share some elements with embedded systems ” such as the operating systems and microprocessors which power them ” but are not truly embedded systems, because they allow different applications to be loaded and peripherals to be connected.
2. History
In the earliest years of computers in the 1930-40s, computers were sometimes dedicated to a single task, but were far too large and expensive for most kinds of tasks performed by embedded computers of today. Over time however, the concept of [[programmable controllers]] evolved from traditional [[electromechanical]] sequencers, via solid state devices, to the use of computer technology.
One of the first recognizably modern embedded system was the [[Apollo Guidance Computer]], developed by [[Charles Stark Draper]] at the MIT Instrumentation Laboratory. At the project and implimentation's inception, the Apollo guidance computer was considered the riskiest item in the Apollo project and implimentation as it employed the then newly developed monolithic integrated circuits to reduce the size and weight. An early mass-produced embedded system was the [[Autonetics D-17]] guidance computer for the [[Minuteman (missile) |Minuteman missile]], released in 1961. It was built from [[transistor]] [[digital circuit logic]] and had a [[hard disk]] for main memory. When the Minuteman II went into production in 1966, the D-17 was replaced with a new computer that was the first high-volume use of integrated circuits. This program alone reduced prices on quad [[Sheffer stroke#NAND gate|nand gate ICs]] from $1000/each to $3/each, permitting their use in commercial products.
Since these early applications in the 1960s, embedded systems have come down in price and there has been a dramatic rise in processing power and functionality. The first [[microprocessor]] for example, the [[Intel 4004]] was designed for [[calculator]] s and other small systems but still required many external memory and support chips. In 1978 National Engineering Manufacturers Association released a "standard" for programmable microcontrollers, including almost any computer-based controllers, such as single board computers, numerical, and event-based controllers.
As the cost of microprocessors and microcontrollers fell it became feasible to replace expensive knob-based [[analog electronics analog]] components such as [[potentiometer]]s and [[variable capacitor]]s with up/down buttons or knobs read out by a microprocessor even in some consumer products. By the mid-1980s, most of the common previously external system components had been integrated into the same chip as the processor and this modern form of the [[microcontroller]] allowed an even more widespread use, which by the end of the decade was the norm rather than the exception for almost all electronics devices. Embedded systems are the applications that fuel some of the microprocessors that play a hidden but crucial role in our everyday lives. These are the tiny, quick, and smart microprocessors that live inside printers, answering machines, elevators, cars, cash machines, refrigerators, thermostats, wristwatches, and even toasters. Embedded systems are on the cutting edge of consumer electronics, poised to revolutionize various technologies by making them "smarter." A branch of the embedded-systems industry wants to see some of this newly smart equipment hooked up to the Internet, so that networking capabilities become a ubiquitous feature of modern machines.
The history of embedded systems goes back at least to the sixties, but the expense and limitations of the early systems limited their use. Embedded systems really took off in 1992, when the PC/104 Consortium was founded by Ampro, RTD, and other manufacturers. The group established a format for Intel microprocessors based on a motherboard approximately four inches square, and just under an inch high. The boards were stackable, allowing a very powerful computer to be assembled in a box approximately four inches square, or even less.
The PC/104 was initially targeted at military and medical markets, where it became widely used and respected. When the processor power increased enough to handle multimedia applications, PC/104-based kiosks became possible, and eventually common.
Today, there are estimated to be well over 100 different companies making PC/104 products. There are PC/104 cards to add Ethernet, FireWire, hard drives, RAM drives, video cards, audio cards, general I/O, flash cards, modems, GPS, cellular telephone, wireless Internet, and more, to the PC/104 motherboard of your choice. Some off-the-shelf PC/104 cases can handle up to 13 or more cards, so your budget is your only constraint.
Kiosk development software is also progressing. Amulet Technologies (http://www.AmuletTechnologies.com) demonstrated a system that will allow LCD touch screens to be programmed in HTML. Since it usually takes C++ programming and several months to program a touch screen interface, the Amulet Technologies system is a major breakthrough. In addition to saving time and money, the technology leaves the interface design to an HTML layout artist, not an engineer. (We managed to program a simple interface with it in less than fifteen minutes from the time we opened the box.) It would be easy and economical to use this technology to make an interface for a hot tub, or a table-top ordering system for customers at restaurants.
Interestingly, many of the exhibitors at the 2002 Embedded Systems Conference were marketing systems much smaller than the PC/104 format. In fact, some of the exhibitors were just selling chips, primarily to add Internet connectivity to products ranging from cars to coffee makers.
Microchip design has advanced so far over the last few years that it's now possible to build a complete computer system on a chip, including wireless Internet connectivity. These chips can easily be added to thousands of products, and soon will be.
It is unavoidable that computer will continue to become cheaper, smaller and more powerful, and that eventually they will be inexpensive enough to put in nearly every product, including soda straws and matchbooks. In addition, nearly all computer equipped products will have some kind of access to either local networks, or the Internet.
Imagine a bathroom shower that will maintain exactly whatever water temperature you tell it to maintain. Aside from meaning no child would ever be accidentally scalded in a bathtub again, this would also mean more efficient and comfortable showers. A computer equipped bathtub would also be smart enough to turn it self off before it overflowed, and send you e-mail to let you know when your bath was ready.
Over the next decade, many common household items will be given embedded systems, reinventing them, and changing forever how we interface with them.
Like desktop publishing, and later the Internet, embedded systems is a technology that will fundamentally, and permanently, change the way advertising and marketing works. It will also permanently change the kind of products that are made, and how they are made.
It's about time, too. For all the benefits industrialization has brought, it has also brought a host of problems as well. The problems go beyond VCR's and microwaves that take an engineering degree to program.
For several hundred years, man has increasingly adjusted life to fit the needs of industrialization and the corporate structure that has grown to support it. In the process, we've become slaves of the machines built to sustain us, and some would argue, slaves to the system itself.
The development of intelligent products, and intelligent product marketing, made possible by embedded systems, will at least offer the possibility of a world where machines exist for the convenience of people, and not the reverse. Given the tools we have now, this kind of dream is no longer impossible.
The rise of embedded systems marks a new phase in industrialization. We've mechanized civilization. Now we have to civilize mechanization.
3. Examples of Embedded Systems
Figure 1 shows one possible organization for an embedded system.
Figure 1. An embedded system encompasses the CPU as well as many other resources.
In addition to the CPU and memory hierarchy, there are a variety of interfaces that enable the system to measure, manipulate, and otherwise interact with the external environment. Some differences with desktop computing may be:
¢ The human interface may be as simple as a flashing light or as complicated as real-time robotic vision.
¢ The diagnostic port may be used for diagnosing the system that is being controlled -- not just for diagnosing the computer.
¢ Special-purpose field programmable (FPGA), application specific (ASIC), or even non-digital hardware may be used to increase performance or safety.
¢ Software often has a fixed function, and is specific to the application.
Table 1. Four example embedded systems with approximate attributes.
In order to make the discussion more concrete, we shall discuss four example systems (Table 1). Each example portrays a real system in current production, but has been slightly generalized to represent a broader cross-section of applications as well as protect proprietary interests. The four examples are a Signal Processing system, a Mission Critical control system, a Distributed control system, and a Small consumer electronic system. The Signal Processing and Mission Critical systems are representative of traditional military/aerospace embedded systems, but in fact are becoming more applicable to general commercial applications over time.
Using these four examples to illustrate points, the following sections describe the different areas of concern for embedded system design: computer design, system-level design, life-cycle support, business model support, and design culture adaptation.
Desktop computing design methodology and tool support is to a large degree concerned with initial design of the digital system itself. To be sure, experienced designers are cognizant of other aspects, but with the recent emphasis on quantitative design life-cycle issues that aren't readily quantified could be left out of the optimization process. However, such an approach is insufficient to create embedded systems that can effectively compete in the marketplace. This is because in many cases the issue is not whether design of an immensely complex system is feasible, but rather whether a relatively modest system can be highly optimized for life-cycle cost and effectiveness.
While traditional digital design CAD tools can make a computer designer more efficient, they may not deal with the central issue -- embedded design is about the system, not about the computer. In desktop computing, design often focuses on building the fastest CPU, then supporting it as required for maximum computing speed. In embedded systems the combination of the external interfaces (sensors, actuators) and the control or sequencing algorithms is or primary importance. The CPU simply exists as a way to implement those functions. The following experiment should serve to illustrate this point: ask a roomful of people what kind of CPU is in the personal computer or workstation they use. Then ask the same people which CPU is used for the engine controller in their car (and whether the CPU type influenced the purchasing decision).
In high-end embedded systems, the tools used for desktop computer design are invaluable. However, many embedded systems both large and small must meet additional requirements that are beyond the scope of what is typically handled by design automation. These additional needs fall into the categories of special computer design requirements, system-level requirements, life-cycle support issues, business model compatibility, and design culture issues.
Embedded systems span all aspects of modern life and there are many examples of their use.
Telecommunications systems employ numerous embedded systems from telephone switches for the network to mobile phones at the end-user. Computer networking uses dedicated routers and network bridges to route data.
Consumer electronics include personal digital assistants (PDAs), mp3 players, mobile phones, videogame consoles, digital cameras, DVD players, GPS receivers, and printers. Many household appliances, such as microwave ovens, washing machines and dishwashers, are including embedded systems to provide flexibility, efficiency and features. Advanced HVAC systems use networked thermostats to more accurately and efficiently control temperature that can change by time of day and season. Home automation uses wired- and wireless-networking that can be used to control lights, climate, security, audio/visual, etc., all of which use embedded devices for sensing and controlling.
Transportation systems from flight to automobiles increasingly use embedded systems. New airplanes contain advanced avionics such as inertial guidance systems and GPS receivers that also have considerable safety requirements. Various electric motors ” brushless DC motors, induction motors and DC motors ” are using electric/electronic motor controllers. Automobiles, electric vehicles. and hybrid vehicles are increasingly using embedded systems to maximize efficiency and reduce pollution. Other automotive safety systems such as anti-lock braking system (ABS), Electronic Stability Control (ESC/ESP), and automatic four-wheel drive.
Medical equipment is continuing to advance with more embedded systems for vital signs monitoring, electronic stethoscopes for amplifying sounds, and various medical imaging (PET, SPECT, CT, MRI) for non-invasive internal inspections.
4. Characteristics
Embedded systems are designed to do some specific task, rather than be a general-purpose computer for multiple tasks. Some also have [[Real-time computing real-time]] performance constraints that must be met, for reason such as safety and usability; others may have low or no performance requirements, allowing the system hardware to be simplified to reduce costs.
# Embedded systems are not always separate devices. Most often they are physically built-in to the devices they control. {{Fact date=September 2007}}.
# The software written for embedded systems is often called [[firmware]], and is stored in read-only memory or [[Flash memory]] chips rather than a disk drive. It often runs with limited computer hardware resources: small or no keyboard, screen, and little memory.
4.1 User Interfaces:
Embedded systems range from no user interface at all — dedicated only to one task — to full user interfaces similar to desktop operating systems in devices such as PDAs.
4.2 Simple Systems:
Simple embedded devices use buttons, [[LED]] s, and small character- or digit-only displays, often with a simple [[Menu (computing) |menu system]].
4.3 In More Complex Systems:
A full graphical screen, with [[touch screen touch]] sensing or screen-edge buttons provides flexibility while minimizing space used: the meaning of the buttons can change with the screen, and selection involves the natural behavior of pointing at what's desired.
Handheld systems often have a screen with a "joystick button" for a pointing device.
The rise of the [[World Wide Web]] has given embedded designers another quite different option: providing a web page interface over a network connection. This avoids the cost of a sophisticated display, yet provides complex input and display capabilities when needed, on another computer. This is successful for remote, permanently installed equipment such as Pan-Tilt-Zoom cameras and network routers.
4.4 CPU Platforms:
Embedded processors can be broken into two broad categories: ordinary microprocessors (µP) and microcontrollers (µC), which have many more peripherals on chip, reducing cost and size. Contrasting to the personal computer and server markets, a fairly large number of basic [[CPU architecture]]s are used; there are [[Von Neumann architecture|Von Neumann]] as well as various degrees of [[Harvard architecture]]s, [[RISC]] as well as non-RISC and [[VLIW]]; word lengths vary from 4-bit to 64-bits and beyond (mainly in [[Digital signal processor|DSP]] processors) although the most typical remain 8/16-bit. Most architectures come in a large number of different variants and shapes, many of which are also manufactured by several different companies.
A long but still not exhaustive list of common architectures are: [[65816]], [[65C02]], [[68HC08]], [[68HC11]], [[68k]], [[8051]], [[ARM architecture ARM]], [[Atmel AVR|AVR]], [[Blackfin]], [[C167 family|C167]], [[Coldfire]], [[COP8]], [[Zilog Z8|eZ8]], [[eZ80]], [[FR-V]], [[Renesas H8|H8]], [[HT48FXX Flash I/O type series|HT48]], [[M16C]], [[M32C]], [[MIPS architecture|MIPS]], [[MSP430]], [[PIC microcontroller|PIC]], [[PowerPC]], [[R8C]], [[Super Harvard Architecture Single-Chip Computer|SHARC]], [[ST6]], [[SuperH]], [[TLCS-47]], [[TLCS-870]], [[TLCS-900]], [[Tricore]], [[V850]], [[x86 architecture|x86]], [[XE8000]], [[Z80]], etc.
4.4.1 Ready Made Computer Boards:
[[PC/104]] and PC/104+ are examples of available ''ready made'' computer boards intended for small, low-volume embedded and ruggedized systems. These often use [[DOS]], [[Linux]], [[NetBSD]], or an embedded [[real-time operating system]] such as [[MicroC/OS-II]], [[QNX]] or [[VxWorks]].
4.4.2 ASIC and FPGA Solutions:
A common configuration for very-high-volume embedded systems is the [[system on a chip]] (SoC), an [[application-specific integrated circuit]] (ASIC), for which the CPU core was purchased and added as part of the chip design. A related scheme is to use a [[field-programmable gate array]] (FPGA), and program it with all the logic, including the CPU.
4.5 Peripherals:
Embedded Systems talk with the outside world via [[peripheral]] s, such as:
*Serial Communication Interfaces (SCI): [[RS-232]], [[RS-422]], [[RS-485]] etc
*Synchronous Serial Communication Interface: [[I2C]], [[JTAG]], [[Serial Peripheral Interface Bus|SPI]], SSC and ESSI
*[[Universal Serial Bus]] (USB)
*Networks: [[Ethernet]], [[Controller Area Network]], [[LonWorks]], etc
*Timers: [[PLL]] (s), Capture/Compare and [[Time Processing Unit]] s
*Discrete IO: aka [[General Purpose Input/Output]] (GPIO)
*Analog to Digital/Digital to Analog (ADC/DAC)
4.6 Tools:
As for other software, embedded system designers use [[compiler]]s, [[Assembly language#Assembler|assembler]]s, and [[debugger]]s to develop embedded system software. However, they may also use some more specific tools:
* In circuit debuggers or emulators (see next section).
* Utilities to add a checksum or [[Cyclic redundancy check|CRC]] to a program, so the embedded system can check if the program is valid.
* For systems using [[digital signal processing]], developers may use a math workbench such as [[MATLAB]], [[Simulink]], [[MathCad]], or [[Mathematica]] to simulate the mathematics. They might also use libraries for both the host and target which eliminates developing DSP routines as done in [[DSPnano RTOS]] and [[Unison Operating System]].
* Custom compilers and linkers may be used to improve optimization for the particular hardware.
* An embedded system may have its own special language or design tool, or add enhancements to an existing language such as [[Forth (programming language)|Forth]] or [[BASIC Stamp|Basic]].
* Another alternative is to add a [[Real-time operating system]] or [[Embedded operating system]], which may have DSP capabilities like [[DSPnano RTOS]].
Software tools can come from several sources:
* Software companies that specialize in the embedded market
* Ported from the [[GNU]] software development tools
* Sometimes, development tools for a personal computer can be used if the embedded processor is a close relative to a common PC processor
As the complexity of embedded systems grows, higher level tools and operating systems are migrating into machinery where it makes sense. For example, [[cellphone]] s, [[personal digital assistant]]s and other consumer computers often need significant software that is purchased or provided by a person other than the manufacturer of the electronics. In these systems, an open programming environment such as [[Linux]], [[NetBSD]], [[OSGi]] or [[Embedded Java]] is required so that the third-party software provider can sell to a large market.
4.7 Debugging:
Embedded [[Debugging]] may be performed at different levels, depending on the facilities available. From simplest to most sophisticated they can be roughly grouped into the following areas:
* Interactive resident debugging, using the simple shell provided by the embedded operating system (e.g. Forth and Basic)
* External debugging using logging or serial port output to trace operation using either a monitor in flash or using a debug server like the [[Remedy Debugger]] which even works for heterogeneous [[multicore]] systems.
* An in-circuit debugger (ICD), a hardware device that connects to the microprocessor via a [[JTAG]] or NEXUS interface. This allows the operation of the microprocessor to be controlled externally, but is typically restricted to specific debugging capabilities in the processor.
* An [[in-circuit emulator]] replaces the microprocessor with a simulated equivalent, providing full control over all aspects of the microprocessor.
* A complete [[emulator]] provides a simulation of all aspects of the hardware, allowing all of it to be controlled and modified and allowing debugging on a normal PC.
Unless restricted to external debugging, the programmer can typically load and run software through the tools, view the code running in the processor, and start or stop its operation. The view of the code may be as [[assembly code]] or [[source-code]].
4.8 Reliability:
Embedded systems often reside in machines that are expected to run continuously for years without errors and in some cases recover by themselves if an error occurs. Therefore the software is usually developed and tested more carefully than that for personal computers, and unreliable mechanical moving parts such as disk drives, switches or buttons are avoided.
Specific reliability issues may include:
#The system cannot safely be shut down for repair, or it is too inaccessible to repair. Examples include space systems, undersea cables, navigational beacons, bore-hole systems, and automobiles.
#The system must be kept running for safety reasons. "Limp modes" are less tolerable. Often backups are selected by an operator. Examples include aircraft navigation, reactor control systems, safety-critical chemical factory controls, train signals, engines on single-engine aircraft.
#The system will lose large amounts of money when shut down: Telephone switches, factory controls, bridge and elevator controls, funds transfer and market making, automated sales and service.
A variety of techniques are used, sometimes in combination, to recover from errors -- both software bugs such as memory leaks, and also [[soft error]] s in the hardware:
* [[watchdog timer]] that resets the computer unless the software periodically notifies the watchdog
* Subsystems with redundant spares that can be switched over to
* Software "limp modes" that provide partial function
* [[Immunity Aware Programming]]
4.9 High vs. Low Volume:
For high volume systems such as [[Digital audio player portable music players]] or [[mobile phone]]s, minimizing cost is usually the primary design consideration. Engineers typically select hardware that is just good enough to implement the necessary functions.
For low-volume or prototype embedded systems, general purpose computers may be adapted by limiting the programs or by replacing the operating system with a [[real-time operating system
5. Computer Design Requirements
Embedded computers typically have tight constraints on both functionality and implementation. In particular, they must guarantee real time operation reactive to external events, conform to size and weight limits, budget power and cooling consumption, satisfy safety and reliability requirements, and meet tight cost targets.
5.1. Real time/reactive operation
Real time system operation means that the correctness of a computation depends, in part, on the time at which it is delivered. In many cases the system design must take into account worst case performance. Predicting the worst case may be difficult on complicated architectures, leading to overly pessimistic estimates erring on the side of caution. The Signal Processing and Mission Critical example systems have a significant requirement for real time operation in order to meet external I/O and control stability requirements.
Reactive computation means that the software executes in response to external events. These events may be periodic, in which case scheduling of events to guarantee performance may be possible. On the other hand, many events may be aperiodic, in which case the maximum event arrival rate must be estimated in order to accommodate worst case situations. Most embedded systems have a significant reactive component.
Design challenge:
¢ Worst case design analyses without undue pessimism in the face of hardware with statistical performance characteristics.
5.2. Small size, low weight
Many embedded computers are physically located within some larger artifact. Therefore, their form factor may be dictated by aesthetics, form factors existing in pre-electronic versions, or having to fit into interstices among mechanical components. In transportation and portable systems, weight may be critical for fuel economy or human endurance. Among the examples, the Mission Critical system has much more stringent size and weight requirements than the others because of its use in a flight vehicle, although all examples have restrictions of this type.
Design challenges:
¢ Non-rectangular, non-planar geometries.
¢ Packaging and integration of digital, analog, and power circuits to reduce size.
5.3. Safe and reliable
Some systems have obvious risks associated with failure. In mission-critical applications such as aircraft flight control, severe personal injury or equipment damage could result from a failure of the embedded computer. Traditionally, such systems have employed multiply-redundant computers or distributed consensus protocols in order to ensure continued operation after an equipment failure.
However, many embedded systems that could cause personal or property damage cannot tolerate the added cost of redundancy in hardware or processing capacity needed for traditional fault tolerance techniques. This vulnerability is often resolved at the system level as discussed later.
Design challenge:
¢ Low-cost reliability with minimal redundancy.
5.4. Harsh environment
Many embedded systems do not operate in a controlled environment. Excessive heat is often a problem, especially in applications involving combustion (e.g., many transportation applications). Additional problems can be caused for embedded computing by a need for protection from vibration, shock, lightning, power supply fluctuations, water, corrosion, fire, and general physical abuse. For example, in the Mission Critical example application the computer must function for a guaranteed, but brief, period of time even under non-survivable fire conditions.
Design challenges:
¢ Accurate thermal modeling.
¢ De-rating components differently for each design, depending on operating environment.
5.5. Cost sensitivity
Even though embedded computers have stringent requirements, cost is almost always an issue (even increasingly for military systems). Although designers of systems large and small may talk about the importance of cost with equal urgency, their sensitivity to cost changes can vary dramatically. A reason for this may be that the effect of computer costs on profitability is more a function of the proportion of cost changes compared to the total system cost, rather than compared to the digital electronics cost alone. For example, in the Signal Processing system cost sensitivity can be estimated at approximately $1000 (i.e., a designer can make decisions at the $1000 level without undue management scrutiny). However, with in the Small system decisions increasing costs by even a few cents attract management attention due to the huge multiplier of production quantity combined with the higher percentage of total system cost it represents. Embedded computers typically have tight constraints on both functionality and implementation. In particular, they must guarantee real time operation reactive to external events, conform to size and weight limits, budget power and cooling consumption, satisfy safety and reliability requirements, and meet tight cost targets.
Design challenge:
¢ Variable "design margin" to permit tradeoff between product robustness and aggressive cost optimization.
6. System-level requirements
In order to be competitive in the marketplace, embedded systems require that the designers take into account the entire system when making design decisions.
6.1. End-product utility
The utility of the end product is the goal when designing an embedded system, not the capability of the embedded computer itself. Embedded products are typically sold on the basis of capabilities, features, and system cost rather than which CPU is used in them or cost/performance of that CPU.
One way of looking at an embedded system is that the mechanisms and their associated I/O are largely defined by the application. Then, software is used to coordinate the mechanisms and define their functionality, often at the level of control system equations or finite state machines. Finally, computer hardware is made available as infrastructure to execute the software and interface it to the external world. While this may not be an exciting way for a hardware engineer to look at things, it does emphasize that the total functionality delivered by the system is what is paramount.
Design challenge:
¢ Software- and I/O-driven hardware synthesis (as opposed to hardware-driven software compilation/synthesis).
6.2. System safety & reliability
An earlier section discussed the safety and reliability of the computing hardware itself. But, it is the safety and reliability of the total embedded system that really matters. The Distributed system example is mission critical, but does not employ computer redundancy. Instead, mechanical safety backups are activated when the computer system loses control in order to safely shut down system operation.
A bigger and more difficult issue at the system level is software safety and reliability. While software doesn't normally "break" in the sense of hardware, it may be so complex that a set of unexpected circumstances can cause software failures leading to unsafe situations. This is a difficult problem that will take many years to address, and may not be properly appreciated by non-computer engineers and managers involved in system design decisions (discusses the role of computers in system safety).
Design challenges:
¢ Reliable software.
¢ Cheap, available systems using unreliable components.
¢ Electronic vs. non-electronic design tradeoffs.
6.3. Controlling physical systems
The usual reason for embedding a computer is to interact with the environment, often by monitoring and controlling external machinery. In order to do this, analog inputs and outputs must be transformed to and from digital signal levels. Additionally, significant current loads may need to be switched in order to operate motors, light fixtures, and other actuators. All these requirements can lead to a large computer circuit board dominated by non-digital components.
In some systems "smart" sensors and actuators (that contain their own analog interfaces, power switches, and small CPUS) may be used to off-load interface hardware from the central embedded computer. This brings the additional advantage of reducing the amount of system wiring and number of connector contacts by employing an embedded network rather than a bundle of analog wires. However, this change brings with it an additional computer design problem of partitioning the computations among distributed computers in the face of an inexpensive network with modest bandwidth capabilities.
Design challenge:
¢ Distributed system tradeoffs among analog, power, mechanical, network, and digital hardware plus software.
6.4. Power management
A less pervasive system-level issue, but one that is still common, is a need for power management to either minimize heat production or conserve battery power. While the push to laptop computing
has produced "low-power" variants of popular CPUs, significantly lower power is needed in order to run from inexpensive batteries for 30 days in some applications, and up to 5 years in others.
Design challenge:
¢ Ultra-low power design for long-term battery operation.
7. Life-cycle support
Figure 2 shows one view of a product life-cycle.
Figure 2. An embedded system lifecycle.
First a need or opportunity to deploy new technology is identified. Then a product concept is developed. This is followed by concurrent product and manufacturing process design, production, and deployment. But in many embedded systems, the designer must see past deployment and take into account support, maintenance, upgrades, and system retirement issues in order to actually create a profitable design. Some of the issues affecting this life-cycle profitability are discussed below.
7.1. Component acquisition
Because an embedded system may be more application-driven than a typical technology-driven desktop computer design, there may be more leeway in component selection. Thus, component acquisition costs can be taken into account when optimizing system life-cycle cost. For example, the cost of a component generally decreases with quantity, so design decisions for multiple designs should be coordinated to share common components to the benefit of all.
Design challenge:
¢ Life-cycle, cross-design component cost models and optimization rather than simple per-unit cost.
7.2. System certification
Embedded computers can affect the safety as well as the performance the system. Therefore, rigorous qualification procedures are necessary in some systems after any design change in order to assess and reduce the risk of malfunction or unanticipated system failure. This additional cost can negate any savings that might have otherwise been realized by a design improvement in the embedded computer or its software. This point in particular hinders use of new technology by resynthesizing hardware components -- the redesigned components cannot be used without incurring the cost of system recertification.
One strategy to minimize the cost of system recertification is to delay all design changes until major system upgrades occur. As distributed embedded systems come into more widespread use, another likely strategy is to partition the system in such a way as to minimize the number of subsystems that need to be recertified when changes occur. This is a partitioning problem affected by potential design changes, technology insertion strategies, and regulatory requirements.
Design challenge:
¢ Partitioning/synthesis to minimize recertification costs.
7.3. Logistics and repair
Whenever an embedded computer design is created or changed, it affects the downstream maintenance of the product. A failure of the computer can cause the entire system to be unusable until the computer is repaired. In many cases embedded systems must be repairable in a few minutes to a few hours, which implies that spare components and maintenance personnel must be located close to the system. A fast repair time may also imply that extensive diagnosis and data collection capabilities must be built into the system, which may be at odds with keeping production costs low.
Because of the long system lifetimes of many embedded systems, proliferation of design variations can cause significant logistics expenses. For example, if a component design is changed it can force changes in spare component inventory, maintenance test equipment, maintenance procedures, and maintenance training. Furthermore, each design change should be tested for compatibility with various system configurations, and accommodated by the configuration management database.
Design challenge:
¢ Designs optimized to minimize spares inventory.
¢ High-coverage diagnosis and self-test at system level, not just digital component level.
7.4. Upgrades
Because of the long life of many embedded systems, upgrades to electronic components and software may be used to update functionality and extend the life of the embedded system with respect to competing with replacement equipment. While it may often be the case that an electronics upgrade involves completely replacing circuit boards, it is important to realize that the rest of the system will remain unchanged. Therefore, any special behaviors, interfaces, and undocumented features must be taken into account when performing the upgrade. Also, upgrades may be subject to recertification requirements.
Of special concern is software in an upgraded system. Legacy software may not be executable on upgraded replacement hardware, and may not be readily cross-compiled to the new target CPU. Even worse, timing behavior is likely to be different on newer hardware, but may be both undocumented and critical to system operation.
Design challenge:
¢ Ensuring complete interface, timing, and functionality compatibility when upgrading designs.
7.5. Long-term component availability
When embedded systems are more than a few years old, some electronic components may no longer be available for production of new equipment or replacements. This problem can be especially troublesome with obsolete processors and small-sized dynamic memory chips.
When a product does reach a point at which spare components are no longer economically available, the entire embedded computer must sometimes be redesigned or upgraded. This redesign might need to take place even if the system is no longer in production, depending on the availability of a replacement system. This problem is a significant concern on the Distributed example system.
Design challenge:
¢ Cost-effectively update old designs to incorporate new components.
8. Business model
The business models under which embedded systems are developed can vary as widely as the applications themselves. Costs, cycle time, and the role of product families are all crucial business issues that affect design decisions.
8.1. Design vs. production costs
Design costs, also called Non-Recurring Engineering costs (NRE), are of major importance when few of a particular embedded system are being built. Conversely, production costs are important in high-volume production. Embedded systems vary from single units to millions of units, and so span the range of tradeoffs between designs versus production costs.
At the low-volume end of the spectrum, CAD tools can help designers complete their work with a minimum of effort. However, at the high-volume end of the spectrum the designs may be simple enough and engineering cost such a small fraction of total system cost that extensive hand-optimization is performed in order to reduce production costs.
CAD tools may be able to outperform an average engineer at all times, and a superior engineer on very large designs (because of the limits of human capacity to deal with complexity and repetition). However, in small designs some embedded computer designers believe that a superior human engineer can outperform CAD tools. In the Small system example a programmer squeezed software into a few hundred bytes of memory by hand when the compiler produced overly large output that needed more memory than was available. It can readily be debated whether CAD tools or humans are "better" designers, but CAD tools face skepticism in areas that require extraordinary optimization for size, performance, or cost.
Design challenge:
¢ Intelligently trade off design time versus production cost.
8.2. Cycle time
The cycle time between identification of a product opportunity and product deployment (also called Time to Market) can be quite long for embedded systems. In many cases the electronics are not the driving force; instead, product schedules are driven by concerns such as tooling for mechanical components and manufacturing process design. Superficially, this would seem to imply that design time for the electronics is not an overriding concern, but this is only partially true.
Because the computer system may have the most malleable design, it may absorb the brunt of changes. For example, redesign of hardware was required on the Mission Critical example system when it was found that additional sensors and actuators were needed to meet system performance goals. On the Small example system, delays in making masked ROM changes in order to revise software dominate concerns about modifications (and programmable memory is too expensive). So, although the initial design is often not in the critical path to product deployment, redesign of the computer system may need to be done quickly to resolve problems.
Design challenge:
¢ Rapid redesign to accommodate changing form factors, control algorithms, and functionality requirements.
8.3. Product families
In many cases embedded system designs are not unique, and there are a variety of systems of various prices and capabilities forming a product family. To the extent that system designers can reuse components, they lower the total cost of all systems in the product family.
However, there is a dynamic tension between overly general solutions that satisfy a large number of niche requirements, and specifically optimized designs for each point in a product family space. Also, there may be cases in which contradictory requirements between similar systems prevent the use of a single subsystem design. In the Mission Critical and Small examples different customers require different interfaces between the embedded system and their equipment. In the Distributed example regulatory agencies impose different safety-critical behavior requirements depending on the geographic area in which the system is deployed.
Design challenge:
¢ Customize designs while minimizing component variant proliferation.
9. Design culture
Design is a social activity as well as a technical activity. The design of desktop computers and CPUs in particular, has matured in terms of becoming more quantitative in recent years. With this new maturity has come an emphasis on simulation and CAD tools to provide engineering tradeoffs based on accurate performance and cost predictions.
Computer designers venturing into the embedded arena must realize that their culture (and the underlying tool infrastructure) is unlike what is commonly practiced in some other engineering disciplines. But, because embedded system design requires a confluence of engineering skills, successful computer designers and design methodologies must find a harmonious compromise with the techniques and methodologies of other disciplines as well as company management. Also, in many cases the engineers building embedded computer systems are not actually trained in computer engineering (or, perhaps not even electrical engineering), and so are not attuned to the culture and methodologies of desktop computer design.
9.1. Computer culture vs. other cultures
A specific problem is that computer design tools have progressed to the point that many believe it is more cost-effective to do extensive simulation than build successive prototypes. However, in the mechanical arena much existing practice strongly favors prototyping with less exhaustive up-front analysis. Thus, it may be difficult to convince project and implimentation managers (who may be application area specialists rather than computer specialists) to spend limited capital budgets on CAD tools and defer the gratification of early prototype development in favor of simulation.
Design challenge:
¢ Make simulation-based computer design accessible to non-specialists.
9.2. Accounting for cost of engineering design
One area of common concern is the effectiveness of using engineers in any design discipline. But, some computer design CAD tools are very expensive, and in general organizations have difficulty trading off capital and tool costs against engineering time. This means that computer designers may be deprived of CAD tools that would reduce the total cost of designing a system.
Also, in high-volume applications engineering costs can be relatively small when compared to production costs. Often, the number of engineers is fixed, and book-kept as a constant expense that is decoupled from the profitability of any particular system design, as is the case in all four example systems. This can be referred to as the "Engineers Are Free" syndrome. But, while the cost of engineering time may have a small impact on product costs, the unavailability of enough engineers to do work on all the products being designed can have a significant opportunity cost (which is, in general, unmeasured).
Design challenge:
¢ Improved productivity via using tools and methodologies may be better received by managers if it is perceived to increase the number of products that can be designed, rather than merely the efficiency of engineers on any given product design effort. This is a subtle but, in practice, important distinction.
9.3. Inertia
In general, the cost of change in an organization is high both in terms of money and organizational disruption. The computer industry can be thought of as being forced to change by inexorable exponential growth in hardware capabilities. However, the impact of this growth seems to have been delayed in embedded system development. In part this is because of the long time that elapses between new technology introduction and wide-scale use in inexpensive systems. Thus, it may simply be that complex designs will force updated CAD tools and design methodologies to be adopted for embedded systems in the near future.
On the other hand, the latest computer design technologies may not have been adopted by many embedded system makers because they aren't necessary. Tool development that concentrates on the ability to handle millions of transistors may simply not be relevant to designers of systems using 4- and 8-bit microprocessors that constitute the bulk of the embedded CPU market. And, even if they are useful, the need for them may not be compelling enough to justify the pain and up-front expense of change so long as older techniques work.
That is not to say that new tools aren't needed, but rather that the force of cultural inertia will only permit adoption of low-cost tools with significant advantages to the problem at hand.
However, the impact of this growth seems to have been delayed in embedded system development. In part this is because of the long time that elapses between new technology introduction and wide-scale use in inexpensive systems. Tool development that concentrates on the ability to handle millions of transistors may simply not be relevant to designers of systems using 4- and 8-bit microprocessors that constitute the bulk of the embedded CPU market. On the other hand, the latest computer design technologies may not have been adopted by many embedded system makers because they aren't necessary.
Design challenge:
¢ Find/create design tools and methodologies that provide unique, compelling advantages for embedded design.
¢ Rapid redesign to accommodate changing form factors, control algorithms, and functionality requirements.
10. Application
Embedded systems are omnipresent and play significant roles in modern-day life. Embedded systems are also diverse and can be found in consumer electronics, such as digital cameras, DVD players and printers; in industrial robots; in advanced avionics, such as missile guidance systems and flight control systems; in medical equipment, such as cardiac arrhythmia monitors and cardiac pacemakers; in automotive designs, such as fuel injection systems and auto-braking systems. Embedded systems have significantly improved the way we live today-and will continue to change the way we live tomorrow.
The availability of low-cost computational-powerful micro-controllers has made it possible to extend the performance and the functionality of the embedded controllers used in automotive industry to limits that were unthinkable only a few years ago. Nowadays, top class cars are equipped with many (more than 80) embedded controllers that handle different subsystems, such as engine, gear, brakes, suspensions, windows, and dash-board
The every increasing complexity and challenges of the automotive requirements in terms of drivability, safety, emissions and fuel consumption imposed by car manufacturers and regulations call for more powerful design approaches and expose the need for a more structured and accurate design flow. The adopted design methodologies have to ensure the development of embedded systems achieving the requested specification and meeting the extremely tight cost and development-time constraints imposed by the market.
Embedded systems already play an important role not only in consumer electronics but also in many important and safety-critical systems in applications such as avionics, space, railway and transport, process control and medical systems. There are, for instance, already many embedded systems in cars with critical control functions (e.g. ABS braking systems, airbags), and these will become much more widely used in the automotive industry once they can be delivered at prices acceptable to the automotive market.
Hybrid system techniques can provide significant contributions to the improvement of the design flow for embedded systems in the automotive industry, since they allow to clearly represent the complex combination of time and event-based behaviors as well as the interactions between continuous and discrete phenomena. Hybrid formalisms and methodologies proved to be very effective in handling several critical issues of the design flow such as:
¢ formalization of system specifications;
¢ representation of embedded controller inputs/outputs;
¢ plant and environment modeling;
¢ representation of multirate asynchronous control loops;
¢ description of the control-flow and data-flow components of control algorithms;
¢ validation and verification of control algorithms and their implementations;
¢ description of the HW/SW implementation requirements.
11. Conclusions
Many embedded systems have requirements that differ significantly both in details and in scope from desktop computers. In particular, the demands of the specific application and the interface with external equipment may dominate the system design. Also, long life-cycles and in some cases extreme cost sensitivity require more attention to optimization based on these goals rather than maximizing the computational throughput.
The business and cultural climates in many embedded system design situations are such that traditional simulation-based computer design techniques may not be viable in their current form. Such methodologies may not be cost-effective given constraints on categories of expenditures, may not be seen as worthwhile by non-computer-trained professionals, or may simply be solving the wrong problems.
Recent interest in hardware/software codesign is a step in the right direction, as it permits tradeoffs between hardware and software that are critical for more cost-effective embedded systems. However, to be successful future tools may well need to increase scope even further to include life-cycle issues and business issues.
12. References
1]. http://www.wikipedia.org
2]. http://www.embeddedstar.org
3]. http://www.embeddedindia.com
4]. http://www.zdnet.com
5]. Real time concepts for embedded systems by Qing LI.
1]: Introduction ¦¦ 03
2]: History ¦¦ 06
3]: Examples of Embedded Systems ¦¦ 10
4]: Characteristics ¦¦ 14
4.1]: User Interfaces
4.2]: Simple Systems
4.3]: In more complex systems
4.4]: CPU platforms
4.4.1]: Ready made computer
4.4.2]: ASIC and FPGA solutions
4.5]: Peripherals
4.6]: Tools
4.7]: Debugging
4.8]: Reliability
4.9]: High vs. Low Volume
5]: Computer Design Requirements ¦¦ 19
5.1]: Real time/reactive operation
5.2]: Small size, low weight
5.3]: Safe and reliable
5.4]: Harsh environment
5.5]: Cost sensitivity
6]: System-level requirements ¦¦ 22
6.1]: End-product utility
6.2]: System safety & reliability
6.3]: Controlling physical systems
6.4]: Power management
7]: Life-cycle support ¦¦ 25
7.1]: Component acquisition 7.2]: System certification 7.3]: Logistics and repair 7.4]: Upgrades 7.5]: Long-term component availability
8]: Business Model ¦¦ 29
8.1]: Design vs. production costs 8.2]: Cycle time 8.3]: Product families
9]: Design culture ¦¦ 31 9.1]: Computer culture vs. other cultures 9.2]: Accounting for cost of engineering 9.3]: Inertia
10]: Application ¦¦ 34
11]: Conclusions ¦¦ 36
12]: Reference ¦¦ 37

Attached Files
.doc   EMBEDDED SYSTEMS main report.doc (Size: 286 KB / Downloads: 293)
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
project topics
Active In SP

Posts: 2,492
Joined: Mar 2010
12-04-2010, 08:45 PM

An embedded system can be defined as the computing device that has computer hardware, either with software embedded in it as one of its most important component. It may be an independent system or a part of a larger system. The emergence of embedded systems is a recent development. As a scientific discipline it resembles the state of microelectronics (and VLSI design, in particular) around 1980. Todayâ„¢s challenge is similar to back then, except that the stakes are probably higher. Embedded systems will appear in virtually all devices, and intelligent devices have the tendency to oust their "stupid" counterparts from the market place, just like CD players have ousted gramophone players. Thanks to developments in microelectronics, the computing power of the desktop computers is now becoming available on the palmtops. Embedded systems are heterogeneous. Since they are mixtures of hardware and software, trade-off is important design decisions: do we realize a function in hardware or in software But embedded systems are more heterogeneous than just combining computer science & digital electronics. and text provides a brief introduction to the wide eld of embedded systems. It covers the history and the main aspects of hard- and software design for embedded systems. The basic concepts of synthesis and automated verications are introduced and a short overview of well-known metrics, which are used to describe the economical and technical at-tributes of a system, is provided. Additionally the deferenceâ„¢s between commonly used operating systems are discussed.

Anti-lock breaking system is designed to help the driver maintain steering control during hard breaking , especially in slippery conditions .It prevents the wheels from locking up , helping you maintain steering control during braking . In a similar situation, driving a car equipped with four-wheel ABS, it would be easier for you to steer your vehicle while braking.
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
project topics
Active In SP

Posts: 2,492
Joined: Mar 2010
21-04-2010, 09:13 PM

.ppt   Embedded Systems presentation.ppt (Size: 1,002 KB / Downloads: 355)

SEMINAR ON Embedded Systems

Presented by:-
Rupali Kusumbe




First embedded system was the APOLLO GUIDANCE COMPUTER.
In 1961 Autonetics D-17 guidance computer used in missile.
Microprocessor INTEL 4004 was designed .


A system that has an embedded software in a device that make a system dedicated for an application or for a specific part of an application or product ,or a part of a larger system.
What is an Embedded System
An Embedded System is microprocessor or microcontroller based system that is embedded as a subsystem, in a larger system (which may or may not be a computer system).
Physically, embedded systems range from portable devices such as digital watches and MP3 players, to large stationary installations like traffic lights, factory controllers, or the systems controlling nuclear power plants


A microprocessor is used as general-purpose processor when large embedded software has to be located in the external memory chips.
In general , a microprocessor is a single VLSI chip that
has a CPU.
CPU executes information stores in the memory.


A microcontroller is a single chip VLSI unit having limited capabilities.
No addition of external memory.
Microcontroller is of 8-bit, 16-bit, 32-bit, 64-bit.
General Characteristics of Embedded Systems
Perform a single as well as multitasking.
Increasingly high performance and real time constrained.
Power, cost and reliability are important considerations.
HW-SW systems
Software is used for more features and flexibility
Hardware (processors, memory etc. are used for performance and security.


Small scale embedded systems.
Medium scale embedded system.
Sophisticated embedded systems.
Small scale embedded systems
Single 8-bit or 16-bit microcontroller.
Less number of hardware and software.
Battery operated.
Use of C language.

Medium scale embedded systems

Few number of 16-bit or 32-bit microcontroller.
Number of hardware and software increases.
Use of C++/C/JAVA.
Example:-Music system
Sophisticated embedded systems
Number of 32-bit or 64-bit microcontroller.
Increase in the Number of hardware and software.
Use of C++/VISUAL C++/JAVA.
Use of software function such as encryption.
Example:-Mobile phone , Smart card

Application areas

Automotive electronics
Aircraft electronics

Application areas

Views on embedded System
It is estimated that each year embedded software is written five times as much as 'regular' software
The vast majority of CPU-chips produced world-wide today are used in the embedded market ... ; only a small portion of CPU's is applied in PC's
... the number of software-constructors of Embedded Systems will rise from 2 million in 1994 to 10 million in 2010;
... the number of constructors employed by software-producers 'merely' rises from 0.6 million to 1.1 million.

Some problems

¢ How can we capture the required behaviour of complex
¢ How do we validate specifications
¢ How do we translate specifications efficiently into
¢ Do software engineers ever consider electrical power
¢ How can we check that we meet real-time constraints
¢ How do we validate embedded real-time software
(large volumes of data, testing may be safety-critical)

Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
project topics
Active In SP

Posts: 2,492
Joined: Mar 2010
21-04-2010, 10:05 PM

.doc   Embedded systems MYREPORT.DOC (Size: 126.5 KB / Downloads: 185)

You read about it everywhere: distributed computing is the next revolution, Perhaps relegating our desktop computers to the museum. But in fact the age of distributed computing has been around for quite a while. Every time we withdraw money from an ATM, start our car, use our cell phone, or microwave our dinner, microprocessors are at work performing dedicated functions. These are examples of just a very few of the thousands of embedded systems.
Until recently the vast majority of these embedded systems used 8- and 16-bit microprocessors, requiring little in the way of sophisticated software development tools, including an Operating System (OS). But the 32-bit processors are now driving an explosion in high-volume embedded applications. And a new trend towards integrating a full system-on-a-chip (SOC) promises a further dramatic expansion for 32-bit embedded applications as we head into the 21st century.
Aerospace companies were the first end-markets for embedded systems, driven by military and space applications. But this market has never developed the growth potential of the newer commercial applications. In the past five years, the major end-markets for embedded systems have been telecommunications, computer networking, and office equipment. But, now we see consumer and automotive electronics as major emerging markets. And looming on the horizon is the suspected wave of networked appliances, with Sun Microsystems, IBM, Microsoft and others targeting products and standards; envisioning billions of embedded network connections running embedded JAVA applications across a network.
The first recognizably modern embedded system was the Apollo Guidance Computer, developed by Charles Stark Draper at the MIT Instrumentation Laboratory. Each flight to the moon had two. They ran the inertial guidance systems of both the command module and LEM.
At the project and implimentation's inception, the apollo guidance computer was considered the riskiest item in the apollo project and implimentation. The use of the then new monolithic integrated circuits, to reduce the size and weight, increased this risk.
The first mass-produced embedded system was the guidance computer for the Minuteman missile in 1961. It was the Autonetics D-17 guidance computer, built using discrete transistor logic and a hard disk for main memory. When the Minuteman II went into production in 1966, the D-17 was replaced with a new computer that used integrated circuits, and was the first volume user of them. Without this program, integrated circuits might never have reached a usable price-point.
The crucial design features of the Minuteman computer were that its guidance algorithm could be reprogrammed later in the program, to make the missile more accurate, and the computer could also test the missile, saving cable and connector weight.
What characterizes an embedded system? Usually it means that there are a set of pre-defined, specific functions to be performed, and that the resources available (e.g., memory, power, processor speed, computational functionality) are constrained. Often, though not always, the application will run out of ROM on a microprocessor. This, in comparison to a desktop computer, which is a general-purpose processor and support system designed for a wide range of applications. The range of embedded software is much broader than desktop software, where a handful of applications (word processors, spreadsheets, games, and so on) make up the vast majority of applications.
Embedded tools are now catching up with Windows GUI, object oriented programming and client/server architectures. These new tools are stressing ease-of-use and enabling team disciplines to work on the same project and implimentation from different locations across the enterprise.
Driving this need for tools is a basic fact of the embedded market. With increased competition, companies supplying embedded products cannot afford schedule slippage that result in missed market opportunities. Increasing the productivity of engineers and programmers has become the critical factor in bringing embedded products to market quickly and at reasonable cost.
The most developed segment of the embedded tools market are the off-the-shelf real-time operating systems (RTOSs), including their support programming tools: source level debuggers, integrated development environment, and compilers.
The commercial RTOS market is highly fragmented with offerings from dozens of vendors, supplying products for many different microprocessors. This fragmentation is caused by three factors. First, there are dozens of different microprocessors optimized for different embedded applications. A different version of the RTOS, with a corresponding set of development tools, must be written for each microprocessor. Second, different applications offer widely variable sets of available programming resources. Some RTOSs are optimized for more resource constrained environments, and others are aimed at less constrained environments. And third, different end market applications have different needs and levels of complexity. Some RTOSs offer a wide range of available services, while others are simpler. A single RTOS cannot provide the optimal solution for every application.
The components needed for the development of Embedded Applications are:
1. Micro Controller.
2. Real-time Operating System.
3. A language for coding.
4. Machine code generator.
5. Debugger.
Micro Controller:
The micro controller consists of microprocessor, ROM, RAM and some I/O ports all on the same chip. The commonly used micro controller is 8051.
Machine code generator:
The source code is written in a particular language like C/C++. This has to be then used to generate the code for the particular microprocessor. The machine specific code is then burnt into the chip(ROM). The microprocessor takes the instructions from the ROM and executes them to produce the desired effect.
What does real-time mean when used in the context of an operating system? Simply put, this means that the embedded application can and will respond to external events in real time, as opposed to waiting for some other task or process to complete its operation. This is made even more confusing by the use of the terms hard real-time and soft real-time.
Hard real-time means an activity must be completed always by a specified deadline (which may be a particular time or time interval, or at the arrival of some event), usually in tens of microseconds to few milliseconds. Some examples include the processing of a video stream, the firing of spark plugs in an automobile engine, or the processing of echoes in a Doppler radar.
Soft real-time applies to those systems that are not hard real-time, but some sort of timeliness is implied. That is, missing the deadline will not compromise the systemâ„¢s integrity, but will have a deleterious effect. Examples of this type of system are point of sale (POS) systems in retail stores, ATMs and other credit card machines, and PDAs. When a POS system can not read the bar code because the item was scanned too quickly, the system simply indicates an error, and the item will be scanned again for identification.
Further confusing the notion of hard and soft real-time is increased processor speeds. When the processor speed increases, interrupts are processed more quickly. More importantly, the interrupt window in which interrupts are disabled keeps shrinking and this will improve the timeliness of response. So soft real-time performance may improve just as a function of processor speed. But countering this trend is the increasing complexity of the applications, requiring more processing to be done at interrupts, and the blurring of the hardware-software interface.
But be they hard or soft, real-time (or perhaps a general term should be embedded) OSs have four characteristics in common that differentiate them from desktop or mainframe OSs.
Bounded Interrupt Servicing:
There is a maximum allowable time that the system can be diverted to process an interrupt. The interrupt service routine must do the absolute minimum processing and terminate.
Priority Based Scheduling:
In a real-time system, all tasks are assigned a level of priority, viz a viz each other. This priority may be based on any number of criteria (including run time). This implies that tasks do not execute just because they are ready, but rather because they are the highest priority task that is ready.
Preemptive Tasks:
All tasks and routines must be constructed in such a way that they can be pre-empted by some higher priority task or routine becoming ready.
The OS services provided are not monolithic. Rather, they are provided as a set of modules or libraries. The services needed for an application are included in the build by simply setting flags at the time of the application build; or, in the case of libraries, by having the linker pull in the services used by the application; or by using conditional compilation to scale the OS.
But, besides these four, there are other differences between real-time and desktop OSs that have more to do with the needs of the end application, the needs of the embedded developer, and the restrictions placed on the application by the resources available. The most obvious is the RAM requirement. Considering the volumes and tight end user pricing of most embedded systems, RAM is a very precious commodity. The OS must use this memory efficiently while preventing fragmentation, recovering RAM when tasks are terminated, requiring the minimum amount of RAM when tasks are created, and providing for efficient stack and heap structures.
Probably just as important are the scheduling algorithms, since these are at the heart of system performance. There are wide varieties of algorithms that have been developed and, depending on the end application, the developer would want to choose the one satisfying the response requirements while being the stingiest on resources. Some of the algorithms developed include:
At any time, the task with the earliest deadline will be executed. This algorithm is efficient, but it may not find a feasible schedule even if one exists.
Round Robin:
Each task is assigned a fixed amount of processor time, and when that time is up, the next task executes.
Simple Priority:
The user assigns a priority at the time of thread creation. The next thread to execute is based on the priority of the ready thread. In a large system, it can be difficult for the user to decide the priorities of each thread.
Rate Monotonic:
The tasks of the program are assigned priorities in descending order according to the length of the period. The task with the shortest period has the highest priority, and the task with the longest period has the lowest priority. In its simplest form, it does not provide support for sporadic events. Modifications have been proposed, such as polling, priority exchange algorithm, and deferrable server algorithm.
Deadline Monotonic Scheduling:
This is close to the Rate Monotonic but accommodates sporadic tasks.
Not as obvious, but just as important, are mechanisms that have been created to synchronize and communicate between tasks. While also found in non-RTOSs, these mechanisms take on a critical role in embedded systems due to the requirements on response and the scarcity of resources. The well known synchronization mechanisms are semaphores, mutexes, and condition variables, with message queues and mailboxes being
among the more common task communication devices. But just having these mechanisms is not sufficient. These mechanisms must be designed in such a way as to take a bounded amount of time for worst case situations. For example, if a set of tasks have to wait for a semaphore in a wait queue, the wait queue should not be singularly linked, since removing a task from the list will require traversing the entire list of waiting tasks. Some more efficient algorithm, with bounded worst case performance, must be used.
An example of a commercial RTOS architecture is given in Figure 1 for pSOSystem from Integrated Systems, Inc.
pSOSystem uses a modular architecture, containing the pSOS+ real-time, multi-tasking kernel and a collection of companion software components and libraries. These components are delivered as black boxes, remaining unchanged from application to application. This assures high reliability to the end user.
Example structure of an embedded system
Embedded Systems are, if nothing else, characterized by constraints such as response, size, performance, costs, and so on. And it is optimizing for these constraints (or rather perhaps working within them) that makes designing an embedded system a difficult task. Numerous questions have to be answered before the design even begins:
? What are the worst case performance requirements for each activity?
? What are the number and complexity of activities to be performed?
? How should these activities be distributed amongst the software tasks so that the processor load is balanced (and thereby get the best cost/performance out of the processor selection)?
? What is the degree of coupling of these tasks (critical deadlines, type of data flow among tasks, event interdependencies)?
? How much RAM and ROM does the hardware design provide?
? How much RAM and ROM will be consumed for the specific set of tasks, ISRs, queues, and so on?
? How much buffer space should be allocated for stack usage?
Over the years, the articles in Embedded Systems Programming magazine have dealt with many, if not most, of the issues facing embedded systems designers. A number of the more commonly faced issues are summarized here.
Time Constraints:
Real-time operating systems bow to a combination of time specific constraints. Some routines must execute at precisely fixed intervals, while other routines are not bound to a critical time alignment. The most critical task of an embedded programmer is to characterize each of the actions to be performed so he will know how to assign priority and resources to that action in order that the overall system performance objectives are met. To aid in this task, it is helpful to break the actions in an embedded system down into the following four task groups:
1. Time critical task routines are those that must occur at a fixed rate with a minimum startup latency (e.g., servicing an A/D converter).
2. Time sensitive task routines are different from time critical tasks in that they can tolerate a large latency before being serviced. Like time critical task routines, they may also occur at fixed rates or they may be initiated at random intervals, but are guaranteed to execute no more frequently than some fixed rate by the task handler itself.
3. Idle task routines are important background operations, and they execute as frequently as possible?at more or less random interval when it is convenient.
4. Mainline tasks routines interpret the user commands, perform non-real-time functions, and make calls to the time sensitive and idle task service routines.
While the reliability of hardware has improved dramatically, when the mission of the embedded system is critical, the embedded designer must build tests of the processor and memory into the application. There are a variety of ways that this can be accomplished.
Probably the first and simplest safety technique learned by many embedded programmers consists of filling unused program memory with either halt instructions or illegal instructions. This technique guards against illegal jumps outside of the program space and provides cheap insurance.
Another common protection is to use buffers that guard against stack underflow/overflow or the corruption of a task's stack. Many of the commercial RTOSs now contain facilities and functions that support stack checking.
To verify the integrity of a program or data stored in ROM, a simple ROM test should be included as well a watchdog timer to prevent the software from getting caught in a loop.
It is also well known that a rogue pointer, for example, can lead to wholesale corruption of memory. So how does one protect against the corruption of program data? One technique is the redundant storage of critical variables, and comparison prior to being used. Another is the grouping of critical variables together and keeping a CRC over each group.
Device Drivers:
It is well known that writing efficient device drivers requires knowledge of both hardware and software. The resulting device drivers become the keys to embedded system performance since they are called repeatedly, and therefore dictate real-time performance in terms of response time, and utilization of memory and other system resources.
Interrupt Service Routines:
Using interrupt processing is a powerful technique that is often more appropriate than using software loops to continuously poll peripheral devices. However, the compiler does not dictate interrupt-processing strategy, and most RISC processors do very little in response to interrupts. These constraints place a burden on the embedded developer in that he must decide which interrupt architecture is best. Some approaches are to save the interrupted context on a memory stack. Another is to preserve the context in a cache, be it on-chip registers (if there are a lot of them to use) or off-chip memory. To simplify debugging, it is best to keep ISRs short.
Storage Allocation:
One important feature to be considered in the selection of an RTOS or embedded system design is storage allocation. Ill-designed dynamic storage allocation can be wasteful for two reasons. First, allocating memory from the heap can be both slow and non-deterministic. The time it takes for the memory manager to search the free-list for a block of the right size may not be bounded. Second, one may create the possibility of a memory allocation fault caused by a fragmented heap. One typical solution is to statically declare all objects up front and get rid of dynamic allocation. However, this can waste storage since the objects always exist and take space. Whilst difficult, the apparently conflicting goals of a dynamic storage allocator can be achieved.
Optimizing Performance:
Writing embedded code that runs efficiently brings about a whole new set of rules. Often optimizing for speed and size opposing design goals-an improvement on one often degrades the other. In trying to achieve this balance, the article promotes the use of three techniques:
? the judicious use of the optimization options found with most embedded cross-platform compilers (for example, eliminating redundant code, or replacing operations with equivalent but faster operations, or unrolling loops, optimizing the use of registers, or removing code segments that the compiler knows cannot be reached)
? the mix of fixed and floating-point operations and
? the employment of user optimizations, making the most out of available resources.
Debugging Memory Problems:
Since many RTOSs and/or embedded microprocessors do not support memory protection, tracking down software memory bugs can become a serious debugging problem. In attacking this problem, it is best to categorize the problem by the type of Memory affected. In general, they fall into three categories:
? Global memory bugs: those bugs that result in corruption of global memory data areas.
? Stack memory bugs: these often cause a complete failure of the program execution; they are the hardest to track down as they are often a function of external events and the current state of the stack.
? Dynamically allocated memory bugs: examples are, heap memory allocated by a malloc service; or problems caused by writing past the boundaries of an allocated memory block or using one that is no longer allocated.
The locator will build a file that describes the image of the target softaware. Let us see the issue of getting that file into the target system.
PROM programmers
The classical way to get the software from the locator file into the target system is to create a RAM or PROM . Creating ROM is appropriate only when software development has been completed,since the toolong cost to build ROMs is quite high.
Putting the program into a PROM requires a device called a PROM programmer. This is appropriate ifvolumes are not large enough to justify using a ROM, if plan to make changes to the software, or while we are debugging . If we plan to use PROMs and a PROM programmer for debugging purposes,it is usefulto build the version of the taaget system in which the PROM is placed in a socket on the target system rather than being soldered directly into the circuit. Then when we find a bug, we can remove the PROM containing the software with the bug from the target system and put it into the eraser or into the waste baket ,program a new PROM with software that has the bug fixed, and put that PROm into the socket. Schematic view of socket
ROM emulator
Rom emulator is a device that replaces the ROM in the target system. From the point of view of the rest of the hardware in the target system, the emulator looks just like a ROM. However, the ROM emulator contains a large box of electronics and a serial port or a network connection through which it can be connected to our host. Software running on host send files created by the locator to the ROM emulator , which will act like a ROM that has been programmed with the software we have written.
There is a flood of trends rushing through the embedded market today, many influencing the RTOS requirements in conflicting ways. It is hard to envision that five years from now RTOS products will bear much resemblance to what is supplied today.
Some of these trends are application driven while others are device driven, and it is important to understand the influences these trends will have.
Application Specific:
In several markets, the end users have banded together to issue specific requirements for RTOSs to be used in their future products. They have purposely chosen to drop their proprietary behaviors of the past in order to get the benefits of multiple suppliers and interoperability of software. In this manner, only the needed software is linked into the application, preventing additional overhead and allowing for an extremely efficient kernel implementation.
System On A Chip (SOC):
As mentioned earlier, SOCs are beginning to appear throughout the embedded market, in at least three different ways. First, the semiconductor suppliers are providing developers the ability to pick and choose from a combination of industry standard functions integrated around a 32-bit core processor. These functions may include memory, IO drivers, a bus interface, network protocol support, or algorithms for special functions, such as an MPEG decoder. Second, end product manufacturers are integrating custom ASICs with common 32-bit core processors to provide complete solutions. Some recent examples include cable modems and ATM switches. And third, startups are emerging that will provide custom design services, complete with optimized RTOS, compiler, and debuggers.
SOC will be particularly well suited for a whole range of consumer electronics and wireless communications devices where size, cost, and low power requirements are crucial. It will also drive cost reductions in networking and telecom equipment, where more functionality can be added at lower costs. A subset of this SOC trend is the emergence of multi-core devices on single silicon. The most common to date has been the combination of standard microprocessors and Digital Signal Processors (DSPs). In some cases, the DSPs are dedicated function processors, but emerging trends have the DSP as a full programmable device.
Automatic Code Generation:
Probably the most radical notion is the idea that application code can be generated automatically from graphical diagrams depicting the logic flow for the end product. To a limited extent, this has already been accomplished, with products like MATRIX, BetterStat, Statemat, and MATLAB?being used for application modeling and code generation. In the case of MATRIX, flight ready code for the international space station has been used for some time now, and the technology is being extended into the more restrictive automotive market. If these tools were to become reality, the whole notion of commercial RTOS and development tools will be upset, as the developer will only interact with the graphical tool, and will be totally isolated from the resulting software implementation.
This seminar and presentation helped in understanding the following concepts.
1. Embedded systems application development.
2. The components of embedded systems.
3. The design issues.
4. The applications in which embedded systems are used.
5. RTOS and its features.
6. How to carry out effective presentation.
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
project report helper
Active In SP

Posts: 2,270
Joined: Sep 2010
24-09-2010, 04:03 PM

.pdf   embeddedsysdigitalbikeoperatingsystem.pdf (Size: 96.63 KB / Downloads: 121)




Now a days consumer products like washing machine, microwave oven, and cellphone
to industries digital technology plays a major role. But we have not yet used this
technology in bikes. What my idea of making u se of this tech. in bikes is a complete
digital bike operating system sans key. According to my invention key is not required
to operate a bike(The operation includes starting & locking the bike, fuel tank cap
opening) & also the petrol knob need no t to be turned on for petrol flow. All are done
automatically by pressing a single button. To start the bike a four -digit password has to
be entered. A keypad is provided for this purpose. After the acceptance of the
password, we can operate the bike . Some safety features are also introduced .If others
try to operate the bike with out the permission from the bike owner they will fail in
their attempt and immediately an alarm which is fixed in the bike starts louding and at
the same time a receiver will indicate it to us.
project report helper
Active In SP

Posts: 2,270
Joined: Sep 2010
07-10-2010, 12:06 PM

.ppt   IT-606-ramesh-L1.ppt (Size: 2.39 MB / Downloads: 221)

S. Ramesh


Many embedded systems have substantially different design constraints than desktop computing applications. No single characterization applies to the diverse spectrum of embedded systems. However, some combination of cost pressure, long life-cycle, real¬-time requirements, reliability requirements, and design culture dysfunction can make it difficult to be successful applying traditional computer design methodologies and tools to embedded applications. Embedded systems in many cases must be optimized for life-cycle and business-driven factors rather than for maximum computing throughput. There is currently little tool support for expanding embedded computer design to the scope of holistic embedded system design. However, knowing the strengths and weaknesses of current approaches can set expectations appropriately, identify risk areas to tool adopters, and suggest ways in which tool builders can meet industrial needs.
If we look around us, today we see numerous appliances which we use daily, be it our refrigerator , the microwave oven, cars, PDAs etc. Most appliances today are powered by something beneath the sheath that makes them do what they do. These are tiny microprocessors, which respond to various keystrokes or inputs. These tiny microprocessors, working on basic assembly languages, are the heart of the appliances. We call them embedded systems. Of all the semiconductor industries, the embedded systems market place is the most conservative, and engineering decisions here usually lean towards established, low risk solutions. Welcome to the world of embedded systems, of computers that will not look like computers and wonâ„¢t function like any thing we are familiar with.
As the name signifies, an Ëœembedded systemâ„¢ is built into a noncomputing device, say a car, TV or toy. We can define an embedded system as a computing device, built in to a device that is not a computer, and meant for doing specific computing tasks. In general engineering terms, embedded systems are used for the control of industrial or physical processes. In computer science terms, embedded systems are distributed reactive systems. Typically these systems have to react to stimuli from their environment in real time. This can be of high importance in situations where a lot of signal processing must be carried out on the inputs inorder to compute the outputs. e.g., multimedia applications.
Embedded systems have been around us for about as long as computer themselves. These were first used in the late 1960s to control electro mechanical telephone switches. As computer industry has moved towards smaller systems over the last decade or so, embedded systems have also moved along with this trend.
Embedded systems are divided into autonomous, realtime, networked & mobile categories.
Autonomous systems: They function in standalone mode. Many embedded systems used for process control in manufacturing units& automobiles fall under this category.
Realtime embedded systems: These are required to carry out specific tasks in a specified amount of time. These systems are extensively used to carryout time critical tasks in process control.
Networked embedded systems: They monitor plant parameters such as temperature, pressure and humidity and send the data over the network to a centralized system for on line monitoring.
Mobile gadgets: Mobile gadgets need to store databases locally in their memory. These gadgets imbibe powerful computing & communication capabilities to perform realtime as well as nonrealtime tasks and handle multimedia applications.

Reference: http://topicideas.org/how-to-embedded-sy...z11bgNhDvH
Active In SP

Posts: 1,124
Joined: Jun 2010
07-10-2010, 03:43 PM

.doc   The Embedded Systems.doc (Size: 172.5 KB / Downloads: 78)
This article is presented by:
Ketul B Sutaria
Siddarth P Vaidya

The Embedded Systems


In the fast growing world there always arise a need for a product that are smaller, cheaper & smarter.
With the increasing amount of the salaries to be paid for small work is not a practical solution to deal with.
Thus there arise the need for a machine, which can work autonomously & requires very less attention to be paid.
All these need lead to the invention of the technology that is known as embedded system.


These are the complicated systems that are the combination of a hardware & software.

An embedded system is preprogrammed to perform a narrow range of functions with minimal end user or operator intervention.

It refers to a device that contains computer logic on a chip inside it not independently programmable by the user. Such equipment is electrical or battery powered. The chip controls one or more functions of the equipment, such as remembering how long it has been since the device last received maintenance.

With the combination of the hardware & software make them performs or controls a function, either in whole or in part, as an integral element of a larger system or subsystem such as, ground support equipment, flight simulators, engine test stands, or fire control systems.

The addition of the mechanical element also proves to be useful as it helping developing a complete low power operated system.
E.g. As an anti-lock braking system in a car.

These systems are mainly produced in order to achieve specific purpose & allow themselves to make the decision in different conditions.

With all these things they are able to do the prescribed work to them with efficiency.
Now continuously working, they consume power. Also the complicated technologies converging in them, they prove to become costly. But this is the main criterion they are to be designed.
Today they have proved not only to be reliable but also to be cheaper then we have imagined.
A specialized computer, often hidden from the end user, used to control devices such as automobiles, home and office appliances, hand-held units of all kinds as well as machines as sophisticated as space vehicles. Operating system and application functions are often combined in the same program. An embedded system implies a fixed set of functions programmed into a non-volatile memory (ROM, flash memory, etc.) in contrast to a general-purpose computing machine. Think of it like a self-contained system. An example would be a computer in a car that controls the ignition system. Because they often operate critically important applications, reliable real-time reactions are vital.

"Real Time" Systems such as industrial control, security, facilities automation, navigational systems, production control, laboratory instrumentation, and similar microprocessor-controlled devices. Embedded systems tend to serve no other function independent of the system into which they are embedded, although some include external data input/output linkages that may pass date-sensitive data to other systems. Operating systems, bootstraps and other pre-programmed instructions are often contained on EPROM or EEPROM

project report helper
Active In SP

Posts: 2,270
Joined: Sep 2010
08-10-2010, 09:46 AM

.pdf   01.%20Introduction%20to%20Embedded%20Systems.pdf (Size: 204.44 KB / Downloads: 133)

Babak Kia
Adjunct Professor
Boston University
College of Engineering
Email: bkia -at- bu.edu


sufficientcomputer on a chip, used to control devices
Active In SP

Posts: 1,124
Joined: Jun 2010
08-10-2010, 10:48 AM

.pdf   embedded-securitysystems-datasheet.pdf (Size: 39.38 KB / Downloads: 109)

Security systems
whether pure software or a combination of hardware and software – must store and manage critical information reliably. Because these systems are a crucial part of the security infrastructure for enterprises, they have unusual requirements not common to many business applications that use database technology. Choosing the right database product can increase reliability, improve performance and enhance the level of security provided by mission-critical deployed systems.

Securing Data from Attack
Security infrastructure, just like other applications, operates on data – user passwords, profile and preferences, roles and responsibilities, access logs, configuration settings and more. Unlike many business applications, though, security infrastructure products must be hardened against attack. As a result, the components that make up the security software, including any database system, must be designed for secure deployment. Security threats can come from a number of implementation choices in software. Especially common, though, are threats due to exposed administrative or user-level interfaces, which allow an attacker to communicate directly with a subsystem in the security product. Many database systems rely on such interfaces in normal operation.
Designers of security infrastructure are often best served by choosing a truly embeddable database management system, rather than a conventional RDBMS designed for business applications, for use in their products. A commercial embedded database can provide all the performance, reliability and recoverability guarantees that applications require, and can also improve overall security by eliminating interfaces that could be use to compromise the system.
Oracle’s family of embedded database products, including Oracle Database, Oracle TimesTen In-Memory Database, Oracle Berkeley DB and Oracle Database Lite, was designed for use in applications that need fast, reliable storage services, without requiring a database administrator. These products can be deployed for zero or near zero administration, so that they are invisible and inaccessible to users and malicious attackers.
seminar surveyer
Active In SP

Posts: 3,541
Joined: Sep 2010
16-10-2010, 05:19 PM

Submitted by
Vijay kumar. S
Vamsi kali Krishna. S

.pdf   embeddedsyscrr.pdf (Size: 334.8 KB / Downloads: 99)


Imagine you control all the systems around just by a simple gesture and the things respond to you as if it was some magic. This could be possible with embedded systems.

The term ‘embedded systems’ is quite a complex one. Simply put, it is a combination of hardware and software that performs the component of a larger system. A few years ago embedded technology existed in stand-alone devices such as vending machines and copiers that did their jobs with little regards for what went on around them. But as technology advance to connect devices to the internet and to each other, the potential of embedded technology has increased. Home appliances, mobile phones, cars, tiny micro chips, avionics etc.., are all using embedded technology.

As you go about the affair of living, you put your life safe and luxurious with all the available resources .Now days we all are entrenched with computers and almost all depended on them. Devices with intelligence rule the world. Imbibing intelligence to these devices is through a system called “EMBEDDED SYSTEM”. Its applications provide marvelous opportunities for ingenious use of computer technology. Almost all every system introduced into the market is an example of Embedded System. An embedded device finds applications in all segments of industrial and commercial marketplace. Home appliances, mobile phones, Personal Digital Assistants (PDA), cars, tiny microchips and avionics are all using embedded technology.

The current topic “Automation of car” that we are going to present is one of the fine examples of Embedded System.
project report helper
Active In SP

Posts: 2,270
Joined: Sep 2010
20-10-2010, 12:18 PM

.doc   embided system_report.doc (Size: 586.5 KB / Downloads: 79)
Embedded Systems


1.1 What is Embedded Systems?
Consider some real-world examples. Firstly, the case of an Intelligent Water-Level Controller For this, some sensors (MEMS based) is placed in the water tank, for level detection. The electrical outputs of the sensor are handled by an embedded login circuit. This circuit takes its own decisions for controlling the water pump. If the water level decreases from a certain level, the login circuit automatically turns-on the pump. In the same manner, if the logic circuit automatically turns-on the pump. In the same manner, if the water level increases from a certain level, it automatically turns-off the pump. Digital Soldering Station is another case, in which an embedded logic circuit controls the header for providing a constant temperature at the tip, by constantly detecting the tip temperature. In contrast to a manual gear system, an automatic gear system automatically changes gear levels according to vehicles’ speed conditions. A smart TV automatically adjusts picture quality according to ambient brightness conditions, through a photo sensor and an embedded circuit.
From above discussion we can conclude that, Embedded Systems are small systems embedded or hidden within a large system like TV Receiver. These small systems take big decisions also.
project report helper
Active In SP

Posts: 2,270
Joined: Sep 2010
26-10-2010, 12:29 PM

.pdf   Chap01Lesson_3Emsys.pdf (Size: 37.36 KB / Downloads: 93)

Power Source
1. System own supply with separate
supply rails for IOs, clock, basic
processor and memory and analog
units, or
2. Supply from a system to which the
embedded system interfaces, for
example in a network card, or
3 .Charge pump concept used in a
system of little power needs, for
examples, in the mouse or contact-less
smart card.

seminar surveyer
Active In SP

Posts: 3,541
Joined: Sep 2010
24-12-2010, 03:36 PM

.doc   embedded systems.doc (Size: 812 KB / Downloads: 91)


“Thousands of persons killed as a cause of earthquake”. The above words aren’t the headlines of the newspaper but daily news everyone come across whenever we go through a newspaper or watching over a TV news.

A person’s life is precious and meaningful to his loved ones.

We, as responsible Engineers felt a part of society to bring a system to avoid these mishaps. With the meteoric Embedded systems along with microprocessor our designed system in preventing deaths and providing safe guided measures.

A new revolutionary microwave life detection system, which is used to locate human beings buried under earthquake rubble, has been designed. This system operating at certain frequency can remotely detect the breathing and heartbeat signals of human beings buried under earthquake rubble. By proper processing of these signals, the status of the person under trap can be easily judged. The entire process takes place within a few seconds as the system is controlled by a microprocessor (8085) or microcontroller unit.

By advent of this system the world death rate may decrease to greater extent as large percentage of death occur due to earthquake.

We welcome and wish you to a safe journey of this paper.

At present as we all know the need of the hour is to find an effective method for rescuing people buried under earthquake rubble (or) collapsed building. It has to be done before we experience another quake. Present methods for searching and rescuing victims buried (or) tapped under earthquake rubble are not effective. Taking all the factors in mind, a system, which will be really effective to solve the problem, has been designed.

The basic principle is that when a microwave beam of certain frequency [L (or) S band (or) UHF band] is aimed at a portion of rubble (or) collapsed building under which a person has been trapped, the microwave beam can penetrate through the rubble to reach the person.
When the microwave beam focuses the person, the reflected wave from the person’s body will be modulated (or) changed by his/her movements, which include breathing and heartbeat. Simultaneously, reflected waves are also received from the collapsed structures.
So, if the reflected waves from the immovable debris are cancelled and the reflected wave from the person’s body is properly distinguished, the breathing and heartbeat signals can be detected.
By proper processing of these signals, the status of the person under trap can be easily judged. Thus a person under debris can be identified.

The microwave life detection system has four major components. They are
1. A microwave circuit which generates, amplifies and distributes microwave signals to different microwave components.
2. A microwave controlled clutter cancellation system, which creates an optimal signal to cancel the clutter from the rubble.
3. A dual antenna system, which consists of two antennas, energized sequentially.
4. A laptop computer which controls the microprocessor and acts as the monitor for the output signal.

The frequency of the microwave falls under two categories, depending on the type and nature of the collapsed building. They are
1. L (or) S band frequency say 1150 MHz
2. UHF band frequency say 450 MHz

Let us see the advantages and disadvantages of both the systems later.

The circuit description is as follows:
Phase locked oscillator:
The phase locked oscillator generates a very stable electromagnetic wave say 1150 MHz with output power say 400mW.
Directional coupler 1 (10 dB):
This wave is then fed through a 10 dB directional coupler and a circulator before reaching a radio frequency switch, which energizes the dual antenna system. Also the ten dB directional coupler branches out one-tenth of the wave (40mW) which is then divided equally by a directional coupler 2 (3 dB).
Directional coupler 2 (3 dB):
One output of the 3 dB directional coupler 2 (20mW) drives the clutter cancellation unit. Other output (20mW) serves as a local reference signal for the double balanced mixer.
Antenna system:
The dual antenna system has two antennas, which are energized sequentially by an electronic switch. Each antenna acts separately.
Clutter cancellation system:
The clutter cancellation unit consists of
1. A digitally controlled phase shifter I
2. A fixed attenuator
3. A RF amplifier
4. A digitally controlled attenuator.

.ppt   FINAL SEMINAR1.ppt (Size: 1.02 MB / Downloads: 113)

Presented by :
Pratik Mehta

Possible within few couples of years.

Real Time Operating System (RTOS) and Embedded system are the major technologies that played a major role in making the above fairly tales come true.

Defination of Embedded System

An embedded system is one that has computer hardware with software embedded in it as one of its most important component.
It is a dedicated computer based system for an application or product.
As its software usually embeds in ROM, it does not need secondary memories as in a computer.

seminar surveyer
Active In SP

Posts: 3,541
Joined: Sep 2010
27-01-2011, 01:50 PM

.doc   EMBEDDEDSYSTEM.doc (Size: 50 KB / Downloads: 49)


II B.Tech , E.C.E.,

This paper attempts to investigate the approach of embedded systems. The embedded system is a combination of computer hardware, software and perhaps additional mechanical or other parts, designed to perform a specific function within a given time frame.

Design of embedded systems, embedded software architectures, user interfaces.

An embedded system is a special-purpose computer system built into a larger device .An embedded-system is typically required to meet very different requirements than a general-purpose personal computer Two major areas of differences are cost and power consumption. Since many embedded systems are produced in the tens of thousands to millions of units range, reducing cost is a major concern. Embedded systems often use a (relatively) slow processor and small memory size to minimize costs.
• Some of the attributes of the coming era:
1. The number of smart devices ( i.e., products with embedded operating systems inside ) will grow exponentially, reaching numbers in the billions.
2. The choice of CPU will be more a matter of cost than technology or a architecture
3. Nearly all devices will have connectivity, whether wired or wireless.
4. Most devices will have the ability to be upgraded or repaired remotely, by downloading new firmware or software.
Most devices will have specific rather than general-purpose functionality, so their users application software will be defined by the manufactures (rather than loaded by their).
This needs to, “minimize cost and maximize specialization”creates the opportunity for embedded systems.

Paper Identification Number : SS-2.5
This peer reviewed paper has been published by the Pentagram Research Centre (p) limited. Responsibility of contents of this paper rests upon the authors and not upon pentagram research center (p) limited. Copies can be obtained from the company for a cost.
Embedded systems are becoming all pervasive. Every microwave has one. A cellular hand phone has two. A luxury Mercedes car has around 40. The latest Boeing 777-302,will have tens of dozens-we’re talking about the ubiquitous microprocessor chips and their associated peripheral devices.
To cite other examples, embedded software allows your washing machine to choose speed according to the type of cloth, gives thinking power to the microwave, acts like a music conductor in the car engine and pushes rocket launchers into space
The embedded system generally comprises topics like real time embedded digital signal processing, microprocessor architecture programming concepts; Real-time Operating System (QXN, RT Linux, V x Works); Micro controllers; Embedded Systems Programming Data Communication Networking, C concepts and linux among others.

All embedded systems have start-up code. Usually it disables interrupts, sets of up the electronics, tests the computer (RAM, CPU and software), and then starts the application code. Many embedded systems recover from short-term power failures by skipping the self-tests if the software can prove they were done recently. Restart times under a tenth of a second are common.
“Embedded systems’ has come to mean “micro-controller programming”. With the increasing proliferation of embedded systems, and advances in hardware and software technologies and the blurring of the boundary between them we need a more meaning-ful glimpse into this area. “Embedded systems’ addresses this need and brings out the issues in building modern-embedded systems.

The electronics usually uses either a microprocessor or a microcontroller some large are old systems use general-purpose mainframe computers are mini computers. Embedded systems design is getting complex, requiring intimate knowledge of both the hardware and software worlds. Cramming all those chips in a square centimetre of silicon real estate is more an art then a science. Getting the software to work with limited memory is often a struggle. Designers embedded systems strive to improve performance, reliability and cost effectiveness. Hardware and software choices are simultaneously considered. This is called co-design.
The goal is to produce an efficient implementation that satisfies-performance and cost requirements on the design the entire system on a chip-the SOC approach. Information appliances can be fabricated from custom SOC silicon .This has been successful in designing cellular hand phones where the high volume usually dictate this design strategy.

Two major areas of differences are cost and power consumption . Since many embedded systems are produced in the tens of thousands to millions of units range, reducing cost is a major concern. Embedded systems often use a (relatively) slow processor and small memory size to minimize costs.
The slowness is not just clock speed. The whole architecture of the computer is often intentionally simplified to lower costs.
For example embedded systems often use peripherals controlled by synchronous serial Interfaces, Which are ten to hundreds of times slower than comparable peripheral used in PCs. Programs on an embedded systems often must run with real time constrains with limited hard ware resources:
Often there is no disk drive, operating system , keyboard or screen. A flash drive may replace rotating media and a small keypad and LCD screen may be used instead of a PCs keyboard and screen.
Firmware is the name for software that is embedded in hardware devices, e.g. in one or more ROM memory IC chips .

There are many different CPU architecture used in embedded designs.
This in contrast to the disk top computer marke-t, which as of this writing (2003) is to
limited just a few competing architectures , chieply intel’s x86,and the apple/Motorola/IBM power PC, used in the apple macintosh.
One common configuration for embedded system is the system on a chip, an application specific integrated circuit, for which the CPU was purchased as intellectual property to add to IC’s design.

Like a typical computer programmer, embedded system, designers use compiler, assembler and debbuger to develop an embedded system.
Those software tools can come from several sources:
Soft-ware companies that specialize in the embedded market. Ported from the GNU software development tolls. Some times, development tools for a personal computer can be used if the embedded process is a close relative to a common PC processors . Embedded system designers also use a few software tools rarely used by typical computer programmers.
Some designers keep a utility program to turn data files into codes, so that they can include any kind of data in a program.Most designers also have utility programs to add a check sum or CRC to a program, so it can check its program data before executing it.

They often have no operating system or a specialized embedded operating system (often real time operating system), or the programmer is assigned to part one of these to the new system .

There are severally basical different types of software architectures in common use.

In this design, the software simply has a loop. The loop calls subroutines. Each subroutine manages apart of the hardware or software. Interrupts generally set flags, or update counters that are read by the rest of the software.
A simple API disables and enables interrupts. Done right, it handles nested calls in Nested subroutines, and restores the preceding interrupt state in the outer most enable. This is one of the simplest methods of creating an exokernel.
Typically, there’s some sort of subroutine in the loop to manage a list of software timers, using a periodic real time interrupt.
When a timer expire, an associated subroutine is run, or flag is set . Any expected hardware event should be backed-up with a software timer . Hardware events fail about ones in a trillion times.
That’s about once a year with modern hardware. With a million mass-produced devices, living out a software timer is a business disaster.
State machines are implemented with a function-pointer per state- machine (in C++, C or assembly any way). A change of state stores a different function into the pointer. The function pointer is executed every time the loop runs.
Many designers recommend reading each IO device once per loop, and storing the result so the logic acts on consistent values.
Any designers prefer to design their state machines to check only one are two things per states. Usually this is a hardware event, and a software timer .
Designers recommand the hierarchical state machines should run the lower-level state Machine before the higher, so the higher run with accurate information.
Complex function like internal combustion control are often handle with multi-dimensional tables.
Instead of complex calculations the code looks up the values. The software can interpolate between entries, to keep the table small and cheap. One major weakness of this system is that it does not guarantee a time to respond to any particular hardware event. Careful coding can easily assure that nothing disables interrupts for long.
Thus interrupt code can run at vary precise timings.Another major weakness of this system is that it can become complex to add few features. Algorithms that take along time to run must be carefully broken down so only a little piece gets done each time through the main loop.
This system’s strength is it’s simplicity, and on small pieces of software the loop is usually so fast that nobody cares that is not predictable.
Another advantage is that system guarantees that a software will run. There is no mysterious operating system to blame for bad behaviour.


User interfaces for embedded systems vary wildly, and thus deserve some special comment. Designers recommend testing the user interface for usability at the earliest possible instant.
Exactly one person should approve the user interface ideally, this should be a customer, the major distributor or someone directly responsible for selling the system. The decision maker should be able to decide. The problem is that a committee will never make-up its mind, and neither will some people. Not doing in this causes avoidable, expensive delays. A usability test is more important then any number of opinions. A touch-screen or screen-edge buttons also minimize that types of user actions. Another basic trick is to minimize and simplify the type output.
Designs should consider using a status light for each interface plug, or failure condition ,to tell what failed. A cheap variation is to have two light bars with a printed matrix of errors that they select-the user can glue on the labels for the languages that she speaks.
For example, Boeing’s standard test interface is a button and some lights. When you press the button all the lights turn on. When you release the button the lights with failures say on. The labels are in basic english. For another example, look at a small computer printer. You might have one next to your computer. Notice that the lights are labeled with stick-on the labels that can be printed in any language. Really look at it.
Designers use colors. Red means the user can get hurt-think of blood.
Yellow means some thing might be wrong. Green means everything’s OK. Another essential trick is to make any modes absolutely clear on the user’s display.
An interface has modes, they must be reversible in an obvious way.
Most designers prefer the display to respond to the user. The display should change immediately after a user action. If the machine is going to do any thing, it should start within 7 seconds, or give progress reports. If a design needs a screen, many designers use plain text.

• . Automatic Teller Machine (ATM).
• . Cellular telephones and telephone switches.
• . Computer network Equipment , including router and fire wall.………
• . Computer Printer .
• . Disk drive .
• . Engine controller and antilock break controller for automobiles.
• . Home auto machine products, like thermostat sprinkler, and security monitoring . . systems.
• . Handheld Calculator.
• . Household appliance, including. Microwave oven ,washing machine ,television sets . . DVD players/recorders.
• . Inertial guidance system for air-craft and missile.
• . Medical Equipment.
• . Multi function Wristwatches.
• . Personal digital assistants.
• . Programmable logic control for industrial automation and monitoring.
• . Video game console.

In this paper we had tried to cover the fundamental principles of embedded systems used in modern digital instruments. In modern world the major problem with present desktop system is that they are very bulky in size to they cause severe problem in their decomposition. But as the embedded system does same task with smaller size made then vary useful for electronic instruments and many others. So it’s the most crucial thing which will become the heart of every electronic device in feature.

1. http://bambooweb.com/articles/e/m/embedded system.html
2. http://oranetech.com/


Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Tagged Pages: embedded systems employes a combination of software and hardware to perform a specific function, how to make project report on embedded technology, design and implementation of caution system for vehicle pollution in vhdl, a full seminar report on embedded microprocessor, embedded systems projects with complete project report, new catching seminar topics on electronics with full report, complete embedded topics,
Popular Searches: difference between pic and at89s52, seminar topics on vlsi embedded system, buy management information system book shops in phoenix, inurl project report on hotel management, recognition day, report on embedded systems in wikipedia, global sourcing of technology related services is estimated to have grown more information,

Quick Reply
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
Exclamation Electronics: a systems approach 4th edition solutions Thijroden 1 125 08-10-2016, 12:13 PM
Last Post: amrutha735
Last Post: mkaasees
  advanced cooling systems for automobiles ppt jaseelati 0 234 15-01-2015, 03:51 PM
Last Post: jaseelati
  artificial vision systems for the blind using ultrasonic wave jaseelati 0 261 07-01-2015, 02:49 PM
Last Post: jaseelati
  bomb detection robotics using embedded controller jaseelati 0 313 06-01-2015, 04:50 PM
Last Post: jaseelati
  user identification and authentication systems must support the minimum requirements jaseelati 0 479 04-12-2014, 01:44 PM
Last Post: jaseelati
  witricity full report project report tiger 28 38,075 30-08-2014, 02:26 AM
Last Post: radiopodarok.ru
Last Post: Guest
  How FACTS Controllers Benefit AC Transmission Systems seminar ideas 1 2,218 13-05-2014, 09:46 AM
Last Post: Ernest Striegel
  ACCIDENT PREVENTION USING WIRELESS COMMUNICATION full report computer science topics 5 7,570 17-04-2014, 11:07 AM
Last Post: seminar project topic