Embedded computer systems constitute the widest possible use of computer systems; it includes all computers other than those specifically intended as general-purpose computers. Examples of embedded systems range from a portable music player, to real-time control of systems like the space shuttle. They are characterized by providing a function, or functions, that is not itself a computer.
The majority of commercial embedded systems are designed to perform selected functions at a low cost. Many, but not all embedded systems have real-time system constraints that must be met. These systems may need to be very fast for some functions, but most of its other functions will probably not need speed. These systems meet their real-time constraints with a combination of special purpose hardware and software tailored to the system requirements.

It is difficult to characterize embedded systems as to speed, or cost requirements, but for high volume systems, cost will often dominate much of the system design. Fortunately, most systems have limited real-time requirements that can usually be met with a combination of custom hardware and a limited amount of high performance software. Take for instance a digital set-top box for satellite television. Even though such a system has to process 10s of megabits of continuous-data per second, most of the heavy lifting is done by custom hardware that parses, directs, and decodes the multi-channel digital stream down into a single video output. The embedded CPU is left to determine data paths, handle interrupts at frame boundaries, generate and display graphics, etc. to enable the set-top look and feel. Therefore, often many parts of an embedded system will require low performance compared to primary mission of the system. This allows architecture of an embedded system to be intentionally simplified to lower costs compared to a general-purpose computer accomplishing the same task, by using a CPU that is “good enough” for these secondary functions.

For embedded systems that are not high volume personal computers can often be conscripted into service either by limiting the programs or by replacing the operating system with a real-time operating system. In this case special purpose hardware may be replaced by one or more high performance CPUs. Still, some embedded system may require both high performance CPUs, special hardware, and large memories to accomplish a required task.n the domain of high volume embedded system, e.g. a portable music player, reducing cost becomes a major concern. These systems will often have just a few chips, a highly integrated CPU, a custom chip that controls all other functions and a single memory chip. In these designs each component is selected and designed to minimize system cost..

The software written for many embedded systems, especially those without a disk drive is sometimes called firmware, the name for software that is embedded in hardware devices, e.g. in one or more ROM/Flash memory IC chips.
Programs on an embedded system often run with real-time constraints with limited hardware resources: often there is no disk drive, operating system, keyboard or screen. The software may not have anything remotely like a file system, or if one is present, a flash drive may replace rotating media. If a user interface is present, it may be a small keypad and liquid crystal display.
Embedded systems reside in machines that are expected to run continuously for years without errors. Therefore the software and Firmware is usually developed and tested more carefully than Software for Personal computers. Many embedded systems avoid mechanical moving parts such as Disk drives, switches or buttons because these are unreliable compared to solid-state parts such as Flash memory

In addition, the embedded system may be outside the reach of humans (down an oil well borehole, launched into outer space, etc.), so the embedded system must be able to restart itself even if catastrophic data corruption has taken place. This is usually accomplished with a standard electronic part called a watchdog timer that resets the computer unless the software periodically resets the timer.

Interface designers at PARC, Apple Computer, Boeing and HP minimize the number of types of user actions. For example, their systems use two buttons (the absolute minimum) to control a menu system (just to be clear, one button should be "next menu entry" the other button should be "select this menu entry").A touch-screen or screen-edge buttons also minimize the types of user actions.
Another basic trick is to minimize and simplify the type of output. Designs sometimes use 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 language that he 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 stay on. The labels are in Basic English.

Another example is probably right next to you. Look at a computer printer. Very often the lights are labelled with stick-on labels that can be printed in any language. In some markets, devices are delivered with several sets of labels, so customers can pick the most comfortable language.Designers use colors. Red means the users can get hurt (think of blood). Yellow means something might be wrong. Green means the status is OK/good. This is intentionally like a stop-light, because most people understand those.
Most designs arrange for a display to change immediately after a user action. If the machine is going to do anything, it usually starts within 7 seconds, or gives progress reports.f a design needs a screen, many designers use plain text. It's preferred because users have been reading signs for years. A GUI is pretty and can do anything, but typically adds a year from artist, approval and translator delays and one or two programmers to a project's cost, without adding any value. Often, an overly-clever GUI actually confuses users, because it can use unfamiliar symbols.

Built-In Self-Test
Most embedded systems have some degree or amount of built-in self test. There are several basic types:

Testing the computer: CPU, RAM, and program memory. These often run once at power-up. In safety-critical systems, they are also run periodically, or over time.
Tests of peripherals: These simulate inputs and read-back or measure outputs. A surprising number of communication, analog and control systems can have these tests, often very cheaply.
Tests of power: These usually measure each rail of the power supply, and may check the input as well. Power supplies are often highly stressed, with low margins.
Communication tests: These verify the receipt of a simple message from connected units. The internet, for example, has the ICMP message "ping."
Cabling tests: These usually run a wire in a serpentine arrangement through representative pins of the cables that have to be attached. Synchronous communications systems, like telephone media, often use "sync" tests for this purpose. Cable tests are cheap, and extremely useful when the unit has plugs.
Rigging tests: Often a system has to be adjusted when it is installed. Rigging tests provide indicators to the person that installs the system.
Consumables tests: These measure what a system uses up, and warn when the quantities are low. The most common example is the gas gauge of a car. The most complex examples may be the automated medical analysis systems that maintain inventories of chemical reagents.
Operational tests: These measure things that a user would care about to operate the system. Notably, these have to run when the system is operating. This includes navigational instruments on aircraft, a car's speedometer, and disk-drive lights.
Safety tests: These run within a 'safety interval', and assure that the system is still reliable. The safety interval is usually a time less than the minimum time that can cause harm.

Reliability regimes
Reliability has different definitions depending on why people want it. Interestingly, there are relatively few types of reliability, and system with similar types employ similar types of embeedded system designs and built-in-self tests:

The system is too unsafe, or inaccessible to repair. (Space systems, undersea cables, navigational beacons, bore-hole systems, and oddly, automobiles and mass-produced products) Generally, the embedded system tests subsystems, and switches redundant spares on line, or incorporates "limp modes" that provide partial function. Often mass-produced equipment for consumers (such as cars, PCs or printers) falls in this category because repairs are expensive and repairmen far away, when compared to the initial cost of the unit.
The system cannot be safely shut down. (Aircraft navigation, reactor control systems, some chemical factory controls, engines on single-engine aircraft) Like the above, but "limp modes" are less tolerable. Often the backups are selected by an operator.
The system will lose large amounts of money when shut down. (Telephone switches, factory controls,
The microcode interrupt lets the debugger operate in hardware in which only the CPU works. The CPU-based debugger can be used to test and debug the electronics of the computer from the viewpoint of the CPU. This feature was pioneered on the PDP-11.

Developers should insist on debugging which shows the high-level language, with breakpoints and single-stepping, because these features are widely available. Also, developers should write and use simple logging facilities to debug sequences of real-time events.PC or mainframe programmers first encountering this sort of programming often become confused about design priorities and acceptable methods. Mentoring, code-reviews and egoless programming are recommended.

As the complexity of embedded systems grows, higher level tools and operating systems are migrating into machinery where it makes sense. For example, cellphones, personal digital assistants 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, OSGi or Embedded Java is required so that the third-party software provider can sell to a large market.
Most such open environments have a reference design that runs on a personal computer. Much of the software for such systems can be developed on a conventional PC. However, the porting of the open environment to the specialized electronics and the development of the device drivers for the electronics are usually still the responsibility of a classic embedded software engineer. In some cases, the engineer works for the integrated circuit manufacturer, but there is still such a person somewhere.

Start-up
All embedded systems have start-up code. Usually it disables interrupts, sets 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 restarting (without recent self-tests). Restart times under a tenth of a second are common.

Many designers have found one or more hardware plus software-controlled LEDs useful to indicate errors during development (and in some instances, after product release, to produce troubleshooting diagnostics). A common scheme is to have the electronics turn on all of the LED(s) at reset (thereby proving that power is applied and the LEDs themselves work), whereupon the software changes the LED pattern as the Power-On Self Test executes. After that, the software may blink the LED(s) or set up light patterns during normal operation to indicate program execution progress and/or errors. This serves to reassure most technicians/engineers and some users. An interesting exception is that on electric power meters and other items on the street, blinking lights are known to attract attention and vandalismTypes of embedded software architectures
There are several basically different types of software architectures in common use.

The control loop
In this design, the software simply has a loop. The loop calls subroutines. Each subroutine manages a part 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 outermost 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 expires, 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 once in a trillion times. That's about once a year with modern hardware. With a million mass-produced devices, leaving out a software timer is a business disaster.

State machines may be implemented with a function-pointer per state-machine (in C++, C or assembly, anyway). 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.Many designers prefer to design their state machines to check only one or two things per state. Usually this is a hardware event, and a software timer.

Designers recommend that hierarchical state machines should run the lower-level state machines before the higher, so the higher run with accurate information.
Complex functions like internal combustion controls are often handled with multi-dimensional tables. Instead of complex calculations, the code looks up the values. The software can interpolate between entries, to keep the tables small and cheap.ne 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 very precise timings.Another major weakness of this system is that it can become complex to add new features. Algorithms that take a long 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 its simplicity, and on small pieces of software the loop is usually so fast that nobody cares that it is not predictable.
Another advantage is that this system guarantees that the software will run. There is no mysterious operating system to blame for bad behavior.

An architecture with similar properties is to have an event queue, and have a loop that removes events and calls subroutines based on a field in the queue-entry.

The advantages and disadvantages are very similar to the control loop, except that adding new software is easier. One simply writes a new task, or adds to the queue-interpreterPreemptive timers
Take any of the above systems, but add a timer system that runs subroutines from a timer interrupt. This adds completely new capabilities to the system. For the first time, the timer routines can occur at a guaranteed time.

Also, for the first time, the code can step on its own data structures at unexpected times. The timer routines must be treated with the same care as interrupt routine(s).
the above nonpreemptive task system, and run it from a preemptive timer or other interrupts.Suddenly the system is quite different. Any piece of task code can damage the data of another task—they must be precisely separated. Access to shared data must be rigidly controlled by some synchronization strategy, for example message queues or semaphores. (Recently non-blocking synchronization strategies have been developed).

Often, at this stage, the developing organization buys a real-time operating system. This can be a wise decision if the organization lacks people with the skills to write one, or if the port of the operating system to the hardware will be used in several products. Otherwise, be aware that it usually adds six to eight weeks to the schedule, and forever after programmers can blame delays on it.

Office-style operating systems
These are popular for embedded projects that have no systems budget. In the opinion of at least one author of this article, they are usually a mistake. Here's the logic:

Operating systems are specially-packaged libraries of reusable code. If the code does something useful, the designer saves time and money. If not, it's worthless.
Operating systems for business systems lack interfaces to embedded hardware. Example: if one uses Linux to write a motor controller or telephone switch, most of the real control operations end up as numbered functions in an IOCTL call. Meanwhile, the normal read, write, fseek, interface is purposeless. So the operating system actually interferes with development.
Most embedded systems perform no office work, so most code of office operating systems is wasted. Example: most embedded systems never use a file system or screen, so file system and GUI logic is wasted. Unused code is just a reliability liability.
Office style operating systems protect the hardware from user programs. That is, they interfere with embedded systems development profoundly.
Operating systems must invariably be ported to an embedded system. That is, the hardware driver code must always be written anyway. This is the most difficult part of the operating system, so little is saved by using one.
The genuinely useful, portable features of operating systems are small pieces of code. Examples: a basic TCP/IP interface is about 3,000 lines of C code; as is a simple file system. If a design needs these, they can be had for less than 10% of the typical embedded system's development budget, without royalty, just by writing them. And, if the needed code is sufficiently generic, the back of embedded systems magazines typically have vendors selling royalty-free C implementation.
Nevertheless Embedded Linux is increasing in popularity, especially on the more powerful embedded devices such as Wireless Routers and GPS Navigation Systems. Here are some of the reasons:

Ports to common embedded platforms are available.
The abilty to re-use publically available code for Device Drivers, Web Servers, Firewalls, and numerous other utilities.
The ability to configure the distribution to exclude unneeded functionality.
The abilty to develop embedded applications user mode, makes the development process ustom operating systems
Some systems require safe, timely, reliable or efficient behavior unobtainable with the above architectures. There are well-known tricks to construct these systems:

Hire a real system programmer. They cost a little more, but can save years of debugging, and the associated loss of revenue.
RMA (rate monotonic analysis), can be used to find whether a set of tasks can run under a defined hardware system. In its simplest form, the designer assures that the quickest-finishing tasks have the highest priorities, and that on average, the CPU has at least 30% of its time free.
Harmonic tasks optimize CPU efficiency. Basically, designers assure that everything runs from a heartbeat timer. It's hard to do this with a real-time operating system, because these usually switch tasks when they wait for an I/O device.
Systems with exactly two levels of priority (usually running, and interrupts-disabled) cannot have Priority inversion problems in which a higher priority task waits for a lower priority task to release a semaphore or other resource.
Systems with monitors can't have deadlocks. A monitor locks a region of code from interrupts or other preemption. If the monitor is only applied to small, fast pieces of code, this can work acceptably well. If the monitor API can be proven to run to completion in all cases, (say, if it merely disabels interrupts) then no hangs are possible.
This means that systems that use dual priority and monitors are safe and reliable because they lack both deadlocks and priority inversion. If the monitors run to completion, they will never hang. If they use harmonic tasks, they can even be fairly efficient. However, RMA can't characterize these systems, and levels of priority had better not exist anywhere, including in the operating system and hardware.

index page1 page2 page3 page4 page5

beauty tips history of india mesothelioma pharmacy information auto parts forum