CROSS ASSEMBLER An assembler that generates machine language for a different type of computer than the one the

assembler is running in. It is used to develop programs for computers on a chip or microprocessors used in specialized applications that are either too small or are otherwise incapable of handling the development software.

The 8051 Cross Assembler takes an assembly language source file created with a text editor and translates it into a machine language object file. This translation process is done in two passes over the source file. During the first pass, the Cross Assembler builds a symbol table from the symbols and labels used in the source file. It's during the second pass that the Cross Assembler actually translates the source file into the machine language object file. It is also during the second pass that the listing is generated.

COMPILER

A compiler is a computer program (or set of programs) that translates text written in a computer language (the source language) into another computer language (the target language). The original sequence is usually called the source code and the output called object code. Commonly the output has a form suitable for processing by other programs (e.g., a linker), but it may be a human-readable text file. The most common reason for wanting to translate source code is to create an executable program. The name "compiler" is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language or machine language). A program that translates from a low level language to a higher level one is a decompiler. A program that translates between high-level languages is usually called a language translator, source to source translator, or language converter. A language rewriter is usually a program that translates the form of expressions without a change of language.

A compiler is likely to perform many or all of the following operations: lexical analysis, preprocessing, parsing, semantic analysis, code generation, and code optimization.

DEBUGGER Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another. A debugger is a computer program that is used to test and debug other programs. 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 much slower than executing the code directly on the appropriate processor. When the program crashes, the debugger shows the position in the original code if it is a source-level debugger or symbolic debugger, commonly seen in integrated development environments. If it is a low-level debugger or a machine-language debugger it shows the line in the disassembly. (A "crash" happens when the program cannot continue because of a programming bug. For example, perhaps the program tried to use an instruction not available on the current version of the CPU or attempted access to unavailable or protected memory.) Typically, debuggers also offer more sophisticated functions such as running a program step by step (single-stepping), stopping (breaking) (pausing the program to examine the current state) at some kind of event by means of breakpoint, and tracking the values of some variables. Some debuggers have the ability to modify the state of the program while it is running, rather than merely to observe it. The importance of a good debugger cannot be overstated. Indeed, the existence and quality of such a tool for a given language and platform can often be the deciding factor in its use, even if another language/platform is better-suited to the task. However, it is also important to note that software can (and often does) behave differently running under a debugger than normally, due to the inevitable changes the presence of a debugger will make to a software program's internal timing. As a result, even with a good debugging tool, it is often very difficult to track down runtime problems in complex multi-threaded or distributed systems.

It is worth pointing out that the same functionality which makes a debugger useful for eliminating accidental bugs allows it to be used as a cracking tool to learn how to evade copy protection and other programmed limitations. Many programmers (especially those accustomed to development in an IDE) dislike or have difficulty working with console debuggers, instead using a front-end incorporating more sophisticated animation and visualization functions and more sophisticated tools. Some examples of these are listed below. EMULATOR Emulation refers to the ability of a program or device to imitate another program or device. Many printers, for example, are designed to emulate Hewlett-Packard LaserJet printers because so much software is written for HP printers. By emulating an HP printer, a printer can work with any software written for a real HP printer. Emulation "tricks" the software into believing that a device is really some other device. A hardware emulator is an emulator which takes the form of a hardware device. Examples include printer emulators inside the ROM of the printer, and FPGA-based hardware emulators. In a theoretical sense, the Church-Turing thesis implies that any operating environment can be emulated within any other. In practice, it can be quite difficult, particularly when the exact behavior of the system to be emulated is not documented and has to be deduced through reverse engineering. It also says nothing about timing constraints; if the emulator does not perform as quickly as the original hardware, the emulated software may run much more slowly than it would have on the original hardware. Most emulators just emulate a hardware architecture if operating system firmware or software is required for the desired software, it must be provided as well (and may itself be emulated). Both the OS and the software will then be interpreted by the emulator, rather than being run by native hardware. Apart from this interpreter for the emulated machine's language, some other hardware (such as input or output devices)

must be provided in virtual form as well; for example, if writing to a specific memory location should influence the screen this would need to be emulated. While emulation could, if taken to the extreme, go down to the atomic level, basing its output on a simulation of the actual circuitry from a virtual power source, this would be a highly unusual solution. Emulators typically stop at a simulation of the documented hardware specifications and digital logic. Sufficient emulation of some hardware platforms requires extreme accuracy, down to the level of individual clock cycles, undocumented features, unpredictable analog elements, and implementation bugs. This is particularly the case with classic home computers such as the Commodore 64, whose software often depends on highly sophisticated low-level programming tricks invented by game programmers and the demoscene. IN-CIRCUIT EMULATOR (ICE) An in-circuit emulator (ICE) also called on-circuit debugger (OCD) or background debug module (BDM) is a hardware device used to debug the software of an embedded system. Embedded systems present special problems for a programmer, because they usually lack keyboards, screens, disk-drives and other helpful user interfaces and storage devices that are present on business computers. In-circuit emulation can also refer to the use of hardware emulation, when the emulator is plugged into a system (not always embedded) in place of a yet-to-be-built chip (not always a processor). These in-circuit emulators provide a way to run the system with "live" data while still allowing relatively good debugging capabilities. It can be useful to compare this with an in-target probe (ITP) sometimes used on enterprise servers. Function The basic idea of an "in-circuit emulator" is that it provides a window into the embedded system. The programmer uses the emulator to load programs into the embedded system, run them, step through them slowly, and see and change the data used by the system's software.

An "emulator" gets its name because it often "emulates" the central processing unit of the embedded system's computer. Often, it literally has a plug that plugs into the same socket as the CPU chip. Emulating the main computer lets it do anything that the main computer can do, but under the control of a programmer. ICEs are always tools that attach a terminal or PC to the embedded system. The terminal or PC provides an interactive user interface for the programmer to investigate and control the embedded system. Notably, when their program fails, most embedded systems simply become inert lumps of nonfunctioning electronics. Embedded systems often lack basic functions to detect signs of software failure, such as an MMU to catch memory access errors. Without an ICE, the development of embedded systems can be extremely difficult, because there is usually no way to tell what went wrong. With an ICE, the programmer can usually test pieces of code, then isolate the fault to a particular failing piece of code, and then inspect the failing code and rewrite it to solve the problem. In usage, an ICE provides the programmer with execution breakpoints, memory display & monitoring, and input/output control. Beyond this, the ICE can be programmed to look for any range of matching criteria to pause at, hopefully catching the failure's origin. Some recent ICE developments (Microchip MPLAB REAL ICE) utilize resources provided on the manufacture version of the microcontroller for emulation and debugging features, instead of needing another special emulation-version of the target microcontroller. Even though it is a cost-effective method since the ICE unit only manages the emulation instead of actually emulating the target microcontroller, tradeoffs have to be made in order to keep the prices low at manufacture time, yet providing enough emulation features for the (relatively few) emulation applications. Advantages Virtually all embedded systems have a hardware element and a software element, which are separate but tightly interdependent. The ICE allows the software element to

be run and tested on the actual hardware on which it is to run, but still allows programmer conveniences to help isolate faulty code, such as "source-level debugging" (which shows the program the way the programmer wrote it) and singlestepping (which lets the programmer run the program step-by-step to find errors). Most ICEs consist of an adaptor unit that sits between the ICE host computer and the system to be tested. A header and cable assembly connects the adaptor to a socket where the actual CPU or microcontroller mounts within the embedded system. Recent ICEs enable a programmer to access the on-chip debug circuit that is integrated into the CPU via JTAG or BDM (Background Debug Mode) in order to debug the software of an embedded system. These systems often use a standard version of the CPU chip, and can simply attach to a debug port on a production system. They are sometimes called In-circuit Debuggers or ICDs, to distinguish the fact that they do not replicate the functionality of the CPU, but instead control an already existing, standard CPU. Since the CPU does not have to be replaced, they can operate on production units where the CPU is soldered in and cannot be replaced. An example is Microchip Technology's ICD, which interfaces with most recent PIC microcontrollers to debug software by attaching to the PIC's In-circuit programming/debugging port. The ICE emulates the CPU. From the system's point of view, it has a real processor fitted, but from the programmer's point of view the system under test is under full control, allowing the developer to load, debug and test code directly. Most host systems are ordinary commercial computers unrelated to the CPU used for development - for example, a Windows PC might be used to develop software for a system using a Freescale 68HC11 chip, which itself could not run Windows. The programmer usually edits and compiles the embedded system's code on the host system, as well. The host system will have special compilers that produce executable code for the embedded system. These are called cross compilers or cross assemblers. Manufacturers

Wind River Systems offers a development suite for JTAG-based debugging using Wind River ICE and Wind River Probe.

Mentor Graphics iSYSTEM AG Lauterbach Datentechnik GmbH Segger Microcontroller Systems Cadence Design Systems makes hardware emulators with in-circuit capability. Microchip Technology Hardware emulators with in-circuit capability, utilizing both On-CHIP and Emulator-CHIP methods.

LOGIC ANALYZER A logic analyzer displays signals in a digital circuit that are too fast to be observed by a human being and presents it to a user so that the user can more easily check correct operation of the digital system. Logic analyzers are typically used for capturing data in systems that have too many channels to be examined with an oscilloscope. Software running on the logic analyzer can convert the captured data into timing diagrams, protocol decodes, state machine traces, assembly language, or correlate assembly with source-level software. Current analyzers are either mainframes, which consist of a chassis containing the display, controls, control computer, and multiple slots into which the actual data capturing hardware is installed, or standalone units which integrate everything into a single package, with options installed at the factory. Operation A logic analyzer can trigger on a complicated sequence of digital events, and then capture a large amount of digital data from the system under test (SUT). The best logic analyzers behave like software debuggers by showing the flow of the computer program and decoding protocols to show messages and violations. When logic analyzers first came into use, it was common to attach several hundred "clips" to a digital system. Later, specialized connectors came into use. The evolution of logic analyzer probe has led to a common footprint that multiple vendors support, which provides added freedom to end users. Introduced in April, 2002, connectorless

technology (identified by several vendor specific trade names: Compression Probing; Soft Touch; D-Max) has become popular. These probes provide a durable, reliable mechanical and electrical connection between the probe and the circuit board with less than 0.5pF to 0.7 pF loading per signal. Once the probes are connected, the user programs the analyzer with the names of each signal, and can group several signals into groups for easier manipulation. Next, a capture mode is chosen, either timing mode, where the input signals are sampled at regular intervals based on an internal or external clock source, or state mode, where one or more of the signals are defined as "clocks," and data is taken on the rising or falling edges of these clocks, optionally using other signals to qualify these clocks. After the mode is chosen, a trigger condition must be set. A trigger condition can range from simple (such as triggering on a rising or falling edge of a single signal), to the very complex (such as configuring the analyzer to decode the higher levels of the TCP/IP stack and triggering on a certain HTTP packet). At this point, the user sets the analyzer to "run" mode, either triggering once, or repeatedly triggering. Once the data is captured, it can be displayed several ways, from the simple (showing waveforms or state listings) to the complex (showing decoded Ethernet protocol traffic). The analyzer can also operate in a "compare" mode, where it compares each captured data set to a previously recorded data set, and stopping triggering when this data set is either matched or not. This is useful for long-term empirical testing. Recent analyzers can even be set to email a copy of the test data to the engineer on a successful trigger.