Embedded Systems

In addition to the emphasis on interaction with the external world,

also provide functionality specific to their applications. Instead of executing spreadsheets, word processing and engineering analysis, Embedded systems typically execute control laws, finite state machines, and signal processing algorithms. They must often detect and react to faults in both the computing and surrounding electromechanical systems, and must manipulate application-specific user interface devices.

If you code for an embedded system, optimization and debugging are essential to keeping your applications running efficiently. Here is a tip on adding a code profiler to help debug.

Timer interrupt—You need a timer interrupt to periodically sample the instruction pointer. On entry to the interrupt, the CPU will store the interrupted code’s instruction pointer on the stack or in a CPU register, depending on the processor architecture. Here, the timer interrupt service routine can retrieve the pointer and use it to determine which region of code was executing when the interrupt struck and which profile counter should be incremented.

For typical systems, an interrupt interval of between 1 ms and 10 ms is perfectly adequate, but a faster interrupt interval will give even better results.

you will come to know that 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 you come to get Embedded systems is:

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.

Interpreting the results—When a profiling session is complete, you can dump the contents of the profile counter table to a debug terminal or file for analysis. The counters with the largest accumulated counts correspond to areas of the executable code containing the most frequently executed code. By cross-referencing these code addresses with the information provided by the linker-generated map file and optionally some code disassembly, you can accurately determine the location of the bottlenecks in the source code.