embedded system

ABSTRACT

“An embedded system is a special purpose computer that is used inside of a device.”

An embedded system is a special-purpose computer system usually built into a smaller device. An embedded system is required to meet very different requirements than a general-purpose personal computer. 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 to much stricter requirements than is general purpose software which can usually be easily restarted if a problem occurs. Embedded systems run the computing devices hidden inside a vast array of everyday products and appliances such as cell phones, toys, handheld PDAs, cameras, and microwave ovens. Cars are full of them, as are airplanes, satellites, and advanced military and medical equipments. As applications grow increasingly complex, so do the complexities of the embedded computing devices. The goal of this paper is to develop a comprehensive understanding of the technologies behind the embedded systems design. We develop an appreciation of the existing capabilities and limitations of various steps in overall design methodology-modeling/specification, exploration, partitioning, synthesis (hardware/software/interface),  and validation/verification of embedded systems.

Embedded computing systems are found everywhere, including in cellular telephones,

pagers, VCRs, camcorders, thermostats, automated supermarket stockers, computerized inventory control devices, digital thermometers, telephone answering machines, printers etc. Demand for embedded system designers is large, and is growing rapidly. Many technical observers believe powerful ubiquitous embedded systems will create the next big revolution, just like the Internet did in the past.  The technologies like EE/CS 120B will introduce you to a unified view of hardware and software design, mapping desired functionality to a collection of single-purpose processors (digital hardware and peripherals) and general-purpose processors (microprocessors). We will gain experience building real digital systems using VHDL, synthesis and FPGAs (Xilinx), and programming embedded microprocessors.

INTRODUCTION

                The first recognizably modern embedded system was the Apollo Guidance computer, developed by Charles stark Darper and the MIT Instrumentation Laboratory. 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 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.

              Embedded systems generally use microcontrollers that contain many functions of a computer on a single device. 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 will be under a tenth of a second.

              Embedded systems generally use microcontrollers that contain many functions of a computer on a single device. There are many different 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, mainly the Intel/AMD x86, and the Apple/Motorola/IBM. One common configuration for embedded systems is the system on a chip, an application-specific integrated circuit which the CPU was purchased as intellectual property to add to the IC's design.

BASIC DEFINITION:

             

                       An embedded system is a special-purpose computer system usually built into a smaller device. An embedded system is required to meet very different requirements than a general-purpose personal computer.

         The embedded system designers use compilers, assemblers and debuggers to develop an embedded system. These software tools can come from

·        Software companies that specialize in the embedded market

·        Ported from the GNU software development tools. (cross-compiler)  

·        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.

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.

The electronics usually uses either a microprocessor or a microcontroller. Some large or old systems use general-purpose mainframe computers or minicomputers. 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. 

Characteristics of Embedded systems:

               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  (that is  in huge quantity), 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 must 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 to much stricter requirements than is general purpose software which can usually be easily restarted if a problem occurs.

                      Debugging is usually performed with an in-circuit emulator, or some type of debugger that can interrupt the microcontroller'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 egoless programming are recommended.

Software design and working of embedded systems:

                       In the design of  the software, it  simply has a loop called control 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.There is 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 read 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.

Nonpreemptive multitasking:

            This system is very similar to the control loop, except that the loop is hidden in an API. One defines  a series of tasks, and each task gets its own subroutine stack. Then, when a task is idle, it calls an idle routine (usually called "pause", "wait", "yield", or etc.).

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 tasks:

Take the above nonpreemptive task system, and run it from a preemptive timer or other interrupts.Suddenly the system is quite different that means it changes to preemptive. 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.

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.

Preemptive timers:

            Take any of the above systems like control loop and non preemptive multitasking,             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 routines.

OPERATING SYSTEMS:

Usually the development operating system for the embedded system is the real time operating system. But there are some special purpose operating systems named,

·         Office-style operating systems

·         Exotic custom operating systems

Office-style operating systems:

                 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. For 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.

Office style operating systems protect the hardware from user programs. That is, they interfere with embedded systems development profoundly.

Since most embedded systems do not perform office work, most of the code of an office operating systems is wasted. For example, most embedded systems never use a file system or screen, so file system and GUI logic is wasted.

Operating systems must invariably be ported to an embedded system. That is, the hardware driver code must always be written anyway. Since this is the most difficult part of the operating system, little is saved by using one.

Last, the genuinely useful, portable features of operating systems are small pieces of code. For example, a basic TCP/IP interface is about 3,000 lines of C code. Likewise, a simple file system. So, if a design needs these, they can be had for less than 10% of the typical embedded system's development budget, without a royalty, just by writing them..

A notable, beloved exception to all of these objections is DOS for an IBM-PC. If you use a single-card computer, the BIOS is done, thus no drivers. DOS permits code to write to hardware. Finally, DOS doesn't do much, so it's compact.

 Exotic custom 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:

If we hire a real system programmer, they can save years of debugging and associated loss of revenue. But  the cost is more.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 inverted priorities, in which a lower priority task waits for a higher-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.

This means that systems that use dual priority and monitors are safe and reliable because they lack both deadlocks and priority inversion. 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.

IMPLEMENTATION:
Embedded systems are required to meet very different requirements than a general-purpose personal computer.

                Software engineers will often program directly to the microcontroller hardware without using a host operating system. As embedded systems have become more sophisticated and have started to include more general computer functions such as networking, using a host operating system has become more popular. Linux and Windows Embedded are two popular operating systems for writing embedded controllers.

For example, consider a microwave system which consists of an embedded system. There present a panel and heating elements and an LCD display in the microwave. The embedded system  accepts input from the panel, controls the LCD display which tells the status of heating or the degree of heating the food item in the microwave, and turns on and off the heating elements that cook the food. This process is done by internal electronic signaling. This is the role played by the embedded systems in the real world applications.

APPLICATIONS:

    

            Embedded computing systems are found everywhere, including in cellular telephones, pagers, VCRs, camcorders, thermostats, automated supermarket stockers, computerized inventory control devices, digital thermometers, telephone answering machines, printers etc.

They are also found in various fields like handheld PDAs, cameras, and microwave ovens. Cars are full of them, as are airplanes, satellites, and advanced military and medical equipments.

   

ADVANTAGES AND DISADVANTAGES:

The main advantage of this system is its simplicity, and on small pieces of software the loop is usually so fast.

Another advantage is that this system guarantees that the software will run. There is no mysterious operating system to blame for bad behavior.

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 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.

CONCLUSION:

Embedded systems offer a feasible solution to control some devices. However seen from the implementation of the microwave device it controls the device by electronic signaling. But it suffers from some drawbacks as seen from above discussion. So, it should be taken into account the type, before using this system or application of this system. The cost of implementation should also be considered before implementing.

Addition of new feature  is also not supported, so if any system in future adds any new feature  it is not supported. so all these factors are to be kept in consideration before implementing it.