[attachment=11255]
INTRODUCTION TO EMBEDDED SYSTEM:
Embedded systems are electronic devices that incorporate microprocessors with in their implementations. The main purposes of the microprocessors are to simplify the system design and provide flexibility. Having a microprocessor in the device helps in removing the bugs, making modifications, or adding new features are only matter of rewriting the software that controls the device. Or in other words embedded computer systems are electronic systems that include a microcomputer to perform a specific dedicated application.
The computer is hidden inside these products. Embedded systems are ubiquitous. Every week millions of tiny computer chips come pouring out of factories finding their way into our everyday products.
Embedded systems are self-contained programs that are embedded within a piece of hardware. Whereas a regular computer has many different applications and software that can be applied to various tasks, embedded systems are usually set to a specific task that cannot be altered without physically manipulating the circuitry.
Another way to think of an embedded system is as a computer system that is created with optimal efficiency, thereby allowing it to complete specific functions as quickly as possible.
Embedded systems designers usually have a significant grasp of hardware technologies. They use specific programming languages and software to develop embedded systems and manipulate the equipment. When searching online, companies offer embedded systems development kits and other embedded systems tools for use by engineers and businesses.
Embedded systems technologies are usually fairly expensive due to the necessary development time and built in efficiencies, but they are also highly valued in specific industries. Smaller businesses may wish to hire a consultant to determine what sort of embedded systems will add value to their organization.
CHARACTERISTICS:
Two major areas of differences are cost and power consumption. Since many embedded systems are produced in 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 peripherals used in PCs.
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. A flash drive may replace rotating media, and a small keypad and LCD screen may be used instead of a PC's keyboard and screen.
Firmware is the name for software that is embedded in hardware devices, e.g. in one or more ROM/Flash memory IC chips. Embedded systems are routinely expected to maintain 100% reliability while running continuously for long periods, sometimes measured in years. Firmware is usually developed and tested too much harsher requirements than is general-purpose software, which can usually be easily restarted if a problem occurs.
PLATFORM:
There are many different CPU architectures used in embedded designs. This in contrast to the desktop computer market which is limited to just a few competing architectures mainly the Intel/AMD x86 and the Apple/Motorola/IBM Power PC’s which are used in the Apple Macintosh.
One common configuration for embedded systems is the system on a chip, an application-specific integrated circuit, for which the CPU was purchased as intellectual property to add to the IC's design.
TOOLS:
Like a typical computer programmer, embedded system designers use compilers, assemblers and debuggers to develop an embedded system. Those 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. 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 code, so that they can include any kind of data in a program. Most designers also have utility programs to add a checksum or CRC to a program, so it can check its program data before executing it.
OPERATING SYSTEM:
They often have no operating system, or a specialized embedded operating system (often a real-time operating system), or the programmer is assigned to port one of these to the new system.
DEBUGGING:
Debugging is usually performed with an in-circuit emulator, or some type of debugger that can interrupt the micro controller’s internal microcode. 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.
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 ego less programming are recommended.
DESIGN OF EMBEDDED SYSTEMS:
The electronics usually uses either a microprocessor or a microcontroller. Some large or old systems use general-purpose mainframes computers or minicomputers.
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 of more hardware plus software-controlled LED’s 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 off the LED(s) at reset, whereupon the software turns it on at the first opportunity, to prove that the hardware and start-up software have performed their job so far. After that, the software blinks the LED(s) or sets up light patterns during normal operation, to indicate program execution progress and/or errors. This serves to reassure most technicians/engineers and some users.
THE CONTROL LOOP:
In this design, the software 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 exocrine.
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.
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.
One major disadvantage 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.