www.wikipedia.org/wiki/Embedded_system -> en.wikipedia.org/wiki/Embedded_system
The wiki will be locked starting in a few minutes An embedded system is a special-purpose 13 computer system built into a larger device. An embedded system is typically required to meet very different requirements than a general-purpose 14 personal computer. 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 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 must run with 34 real-time constraints with limited 35 hardware resources: often there is no disk drive, operating system, keyboard or screen. A 36 flash drive may replace rotating media, and a small keypad and 37 LCD screen may be used instead of a PC's keyboard and screen. Platform There are many different 43 CPU architectures used in embedded designs. This in contrast to the desktop computer market, which as of this writing (2003) is limited to just a few competing architectures, chiefly 44 Intel's 45 x86, and the Apple/Motorola/IBM 46 PowerPC, used in the 47 Apple Macintosh. One common configuration for embedded systems is the system on a chip, an 48 application-specific integrated circuit, for which the CPU was purchased as intellectual property to add to the IC's design. Tools The software tools ( 49 compilers, 50 assemblers and 51 debugger) used to develop an embedded system can come from several sources: * Software companies that specialize in the embedded market * Ported from the 52 GNU software development tools. Operating system They often have no 54 operating system, or a specialized 55 embedded operating system (often a 56 real-time operating system), or the programmer is assigned to port one of these to the new system. Debugging 57 Debugging is usually performed with an 58 in-circuit emulator, or some type of debugger that can interrupt the microcontroller's internal 59 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 61 breakpoints and 62 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. History The first recognizably modern embedded system was the 63 Apollo Guidance Computer, developed by 64 Charles Stark Draper and the 65 MIT Instrumentation Laboratory. They ran the 66 inertial guidance systems of both the command module and 67 LEM. At the project's inception, the apollo guidance computer was considered the riskiest item in the apollo project. The first mass-produced embedded system was the guidance computer for the 68 Minuteman missile. It also 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. Design of embedded systems The electronics usually uses either a 69 microprocessor or a 70 microcontroller. Some large or old systems use general-purpose 71 mainframe computers or 72 minicomputers. Usually it disables interrupts, sets up the electronics, tests the computer (RAM, CPU and program), 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. Many designers have found a software-controlled light useful to indicate errors. One common way to handle it is to have the electronics turn it off (which looks broken) at reset. The software turns it on at the first opportunity to prove the light works. After that, the code blinks it during normal operation, and maybe in patterns for errors. Types 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. 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. 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 73 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. With a million mass-produced devices, leaving out a software timer is a business disaster. State machines are 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. 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. 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 74 CRC to a program, so it can check its program data before executing it. One major weakness of this system is that it does not guarantee a time to respond to any particular hardware event. Another is that it can become complex to add new features. The strength is that it's simple, and on small pieces of software the loop is usually so fast that nobody cares that it's unpredictable. Another advantage is that this system guarantees that the software will run. There's no mysterious operating system to blame for bad behavior. Careful coding can easily assure that nothing disables interrupts for long. Nonpreemptive multitasking This system is very similar to the above, except that the loop is hidden in an 75 API. One defines a series of tasks, and each task gets its own subroutine stack. 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-interpreter. Preemptive timers Take any of the above systems, but add a timer system that runs subroutines from a timer interrupt. 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 routines. Preemptive tasks Take the above nonpreemptive task system, and run it from a preemptive timer or other interrupts. Any piece of task code can damage the data of another ta...
|
http://csua.com/feed/