SIMULATORS AND DEBUGGER
Posted on : Sun , 09 2014 by : virusi
THEORY ON SIMULATORS AND DEBUGGER:
A debugger or debugging tool is a computer program that is used to test and debug other programs (the “target” program). The code to be examined might alternatively be running on an instruction set simulator (ISS), a technique that allows great power in its ability to halt when specific conditions are encountered but which will typically be somewhat slower than executing the code directly on the appropriate (or the same) processor. Some debuggers offer two modes of operation—full or partial simulation—to limit this impact. A “trap” occurs when the program cannot normally continue because of a programming bug or invalid data. For example, the program might have tried to use an instruction not available on the current version of the CPU or attempted to access unavailable or protected memory. When the program “traps” or reaches a preset condition, the debugger typically shows the location in the original code if it is a source-level debugger or symbolic debugger, commonly now seen in integrated development environments. If it is a low-level debugger or a machine-language debugger it shows the line in the disassembly (unless it also has online access to the original source code and can display the appropriate section of code from the assembly or compilation).
Typically, debuggers offer a query processor, symbol resolver, expression interpreter, and debug support interface at its top level. Debuggers also offer more sophisticated functions such as running a program step by step (single-stepping or program animation), stopping (breaking) (pausing the program to examine the current state) at some event or specified instruction by means of a breakpoint, and tracking the values of variables. Some debuggers have the ability to modify program state while it is running. It may also be possible to continue execution at a different location in the program to bypass a crash or logical error. Debugger front-ends are popular extensions to debugger engines that provide IDE integration, program animation, and visualization features. Some early mainframe debuggers such as Oliver and SIMON provided this same functionality for the IBM System/360 and later operating systems, as long ago as the 1970s. Some debuggers include a feature called “reverse debugging“, also known as “historical debugging” or “backwards debugging”. These debuggers make it possible to step a program’s execution backwards in time. Reverse debugging is very useful for certain types of problems, but is still not commonly used yet.
Simulators try to model the behavior of the complete microcontroller in software. Some simulators go even a step further and include the whole system (simulation of peripherals outside of the microcontroller). No matter how fast your PC, there is no simulator on the market that can actually simulate a microcontroller’s behavior in real-time. Simulating external events can become a time-consuming exercise, as you have to manually create “stimulus” files that tell the simulator what external waveforms to expect on which microcontroller pin. A simulator can also not talk to your target system, so functions that rely on external components are difficult to verify. For that reason simulators are best suited to test algorithms that run completely within the microcontroller (like a math routine for example). They are the perfect tool to complement expensive emulators for large development teams, where buying an emulator for each developer is financially not feasible.