This page has been robot translated, sorry for typos if any. Original content here.

Development and debugging tools for single-chip microcontrollers

Key debugging tools include:

  • in-circuit emulators.
  • software simulators.
  • development boards (evaluation boards).
  • debug monitors.
  • ROM emulators.

This list does not exhaust all types of existing debugging tools. In addition to these, there are combined devices and sets that can compensate for the shortcomings of fixed assets taken separately.

In-circuit emulators.

An in-circuit emulator is a hardware-software tool capable of replacing an emulated processor in a real circuit. The in-circuit emulator is the most powerful and versatile debugging tool.

In fact, a “good” in-circuit emulator makes the process of functioning of the debugged controller transparent, i.e. easily controlled, arbitrarily managed and modifiable according to the will of the developer.

Functionally in-circuit emulators are divided into interfaced with an external computer (usually it is an IBM PC), and functioning autonomously. Autonomous in-circuit emulators have individual computing resources, input-output means, do not require any external computing tools for their normal operation, but the user has to pay for this either at a significantly higher price or reduced functional and service capabilities compared to similar ones models compatible with IBM PC.

Usually, the in-circuit emulator is docked with a debugged system using an emulation cable with a special emulation head. The emulation head is inserted instead of the microcontroller into the debugged system. If the microcontroller cannot be removed from the system being debugged, then the use of the emulator is possible only if this microcontroller has a debugging mode in which all its outputs are in the third state. In this case, a special adapter-clip is used to connect the emulator, which is connected directly to the terminals of the emulated microcontroller.

At a minimum, the emulator contains the following functional blocks:

  • debugger
  • microcontroller emulation node;
  • emulation memory;
  • breakpoint subsystem;

More advanced models may additionally contain:

  • breakpoint processor;
  • tracer
  • profiler (software code efficiency analyzer);
  • real time timer;
  • software and hardware that provide the ability to read and modify the resources of the emulated processor "on the fly", i.e. in the process of executing a user program in real time;
  • software and hardware tools providing synchronous control necessary for emulation in multiprocessor systems;
  • integrated development environment


The debugger is a kind of bridge between the developer and the debugging tool. The composition and amount of information passing through the input-output means, its availability for perception, control, and, if necessary, for correction and modification, directly depends on the properties and quality of the debugger.

A good debugger allows you to:

  • loading the debugged program into the system memory.
  • output to the monitor of the status and contents of all registers and memory, and, if necessary, their modification.
  • management of the emulation process.

More powerful debuggers, usually referred to as High-Level Debuggers, in addition, allow:

  • conduct symbolic debugging, due to the fact that the debugger "knows" the addresses of all symbolic variables, arrays and structures (due to the use of special information supplied by the compiler). At the same time, the user can operate with more acceptable symbolic names for a person, without bothering to remember their addresses.
  • control and analyze not only disassembled text, but also the source code of a program written in a high-level language, and even with your own comments.

Such a debugger allows the user to simultaneously monitor the progress of the program and see the correspondence between the source text, the image of the program in machine codes, and the state of all resources of the emulated microcontroller.

It should be noted that a high-level debugger provides the execution of all its functions only if a cross-compiler is used that delivers complete and correct debugging information (not all compilers, especially their pirated versions, provide such information) and the format of its presentation should be " sign "debugger.

Emulation memory

The presence of emulation memory makes it possible to use it in the process of debugging instead of ROM in a debugged system, and moreover, debug a program without using a real system or its layout. If you need to make changes to the debugged program, it is enough to load a new or modified program into the emulator's memory, instead of reprogramming the ROM. There are models of emulators that allow the user to “substitute” the emulation memory instead of ROM, not only in whole but also in blocks (in some models the minimum block size can reach one byte), in the order specified by the user. To do this, it is enough for the user to specify the distribution of data memory and program memory, according to which the processor will access both the contents of the ROM in the debugged system and the contents of the emulation memory of the in-circuit emulator. This kind of memory is usually called mapable memory.


In essence, a tracer is a logical analyzer that works synchronously with the processor and captures the flow of instructions and the status of selected external signals. There are models of in-circuit emulators that allow you to trace not only external signals, but also the state of the internal resources of the microcontroller, for example, registers. Such emulators use special versions of microcontrollers (emulation crystals).

Breakpoint processor

The breakpoint processor allows you to stop program execution, or perform other actions, for example, start or stop the tracer, when the user-specified conditions are met. In contrast to the mechanism of conventional breakpoints, the processor of breakpoints allows you to create and monitor conditions of almost any degree of complexity, and the emulated process is not removed from the real-time scale.


The profiler (in other words, the program code efficiency analyzer) allows you to obtain the following information from the results of a debugged program run:

  • the number of calls to various parts of the program;
  • time spent on the implementation of various sections of the program.

Analysis of statistical information supplied by the profiler makes it easy to identify “dead” or overstressed sections of programs, and as a result, optimize the structure of the program being debugged.

Integrated Development Environment

A set of software tools that supports all stages of software development from writing the source code to compiling and debugging it, and provides simple and quick interaction with other tools (software debugger-simulators and programmer).

The presence in the program shell of the emulator of a built-in editor, a built-in project manager and control system, can significantly facilitate the work of the developer, saving him from many routine actions. For the developer, the line between writing a program, editing it and debugging is erased. The transition from editing the source text to debugging and vice versa occurs "transparently" and synchronously with the activation of the corresponding windows, the project manager automatically starts compilation as necessary and activates the corresponding windows of the program interface.

Equally simple is the transition to debugging the project using the existing debugger-simulator, or proceed to the "firmware" of the ROM with a debugged program.

Some models of in-circuit emulators may provide users with other additional features. Among them, we note one, although quite specific, but in some cases of fundamental importance: the ability to build multi-emulator complexes necessary for debugging multiprocessor systems. A distinctive feature of this complex is the ability to synchronously control (from one computer) multiple emulators.

In general, various models of in-circuit emulators can provide the user with the ability to monitor and control the functioning of debugged devices, with various restrictions. For example, it can be incorrect processing of interrupts in a step-by-step mode, or a ban on the use of a serial port, etc. It is also necessary to remember that each real model of the emulator has its own set of supported compilers. Some manufacturers of emulator manufacturers knowingly go to the limit of the number of supported compilers, in the first place this is typical for Western manufacturers. In these cases, the emulator can use only one character format.

We will illustrate the capabilities of a “real” in-circuit emulator using the PICE-51 model as an example.


Intracircuit emulator of 8-bit microcontrollers of the 8051 family

PICE-51 is a new generation emulator created using new hardware and software development technologies.

The use of high-capacity programmable matrices made it possible to drastically reduce the size of the emulator without any damage to its functionality, minimize deviations of the electrical and frequency characteristics of the emulator from the characteristics of the emulated processor, and thereby achieve maximum emulation accuracy at frequencies up to 30 MHz at supply voltages from 3.3V up to 5V.

The resettable hardware structure of the emulator provides emulation of almost all microcontrollers of the 8051 family, both domestic and from Intel, Philips, Siemens, Atmel, Dallas, Temic, OKI, AMD, MHS and others.

Powerful programming interface in Windows environment, is an integrated development environment that supports all stages of software development from writing the source code to its compilation and debugging. The emulator support program is focused on debugging programs in a high-level language according to the source text .

The emulator consists of a main board with a size of 80x76mm, a removable adapter for a specific processor and a replaceable emulation head for a specific type of case. On the main board are implemented: tracer, breakpoint processor . The plug-in adapter board contains an emulating processor for a specific type of microcontroller. The emulation heads allow the emulator to be installed in the DIP and PLCC blocks on the user board. The emulator is powered from the power supply + 5V, 0.5A or directly from the device being debugged. Communication with a computer is via galvanically isolated RS-232C channel at a speed of 115 kbaud ..


  • Accurate emulation - the absence of any restrictions on the use by the user program of the resources of the microcontroller.
  • Up to 256K emulated program and data memory. Support for banked memory model. Memory allocation between the emulator and the user's device with an accuracy of 1 byte.
  • Up to 512K hardware breakpoints for program and data memory access.
  • Hardware support for debugging programs in high-level languages.
  • Trace 8 arbitrary external signals.
  • 4 user equipment synchronization outputs.
  • A real-time tracer with a buffer capacity of 16K to 64K frames of 64 bits with on-the-fly access. Tracing of address, data, control signals, real-time timer and 8 external user signals.
  • Programmable trace filter.
  • A hardware processor of breakpoints with the ability to specify a complex condition for stopping emulation by a combination of address signals, data, control, 8 external signals, a real-time timer, event counters and a delay timer.
  • Four complex breakpoints that can be used independently or in combination with AND / OR / IF-THEN.
  • 48-bit real-time timer.
  • Transparent emulation - on-the-fly access to emulated memory, breakpoints, breakpoint processor, trace buffer, real-time timer.
  • A controlled clock for an emulated processor. The ability to smoothly change the clock frequency from 500 kHz to 40 MHz.
  • An RS-232C communication channel galvanically isolated from the computer with an exchange rate of 115 kBaud.
  • Built-in self-diagnostic system of the emulator equipment.


  • The software is focused on working in a Windows environment on IBM-compatible computers with processors such as 386/486 / Pentium;
  • The built-in multi - window editor is designed for writing the source code of programs. The editor supports operations with blocks of text, search / replace, color selection of syntactic constructions of assembly language and C;
  • Built-in project manager provides automatic compilation of programs. All options are set in a dialog form. The transition from editing the source text to debugging and vice versa is "transparent", i.e. the project manager automatically starts compilation of the project if necessary;
  • PICE-51 provides symbolic and source debugging for programs created using the following compilers:
    • assembler ASM51 from Intel ;
    • assembler MCA-51 of Fiton / Microcosm company ;
    • Intel PL / M Compiler;
    • assembler and C compiler of IAR Systems company;
    • C assembler and compiler Avocet Systems Inc./HiTech ;
    • assembler and C compiler of Keil Software Inc. ;
  • Automatically save and load hardware configuration files, interface and debugging options. Compatibility of configuration files with the PDS-51 simulator is provided. Portability of projects between the PICE-51 emulator and the PDS-51 simulator is provided;
  • The ability to configure colors, fonts and other parameters for all windows simultaneously and for each window separately;

The emulator is equipped with a printed operating manual and contextual electronic manual , which describes in detail its operating principles, commands, menus, hot keys.

Block diagram of the emulator PICE-51

PIC-51 emulator configuration options

Emulated microcontroller Emulation of internal program memory Contents of delivery
Main board Replaceable adapter Emulation head
Intel : 80C31 / 32, 80C51 / 52, 80L / C51FA, 80C51RA;
Philips : 80C31 / 32, 80C51 / 52, 80C51FA; 80C51RA +, 80CL410, 80C524 / 528/550/652/654/575/576/851;
Atmel : 89C51, 89C52, 89C55, 89S8252, 89S53;
Siemens : SAB501 / 502/504/505/511/513;
MHS : 80C31, 80C51, 80C32, 80C52, 80C154;
Oki: 80C31, 80C51, 80C154;
AMD: 80C31, 80C51, 80C52;
Not PICE-51 POD-51-31 ADP-51-DIP40 or ADP-51-LCC44
Intel : 80C31 / 32, 8XC51 / 52/54/58, 8XL / C51FA / FB / FC, 8XC51RA / RB / RC;
Philips : 80C31 / 32, 8XC51 / 52/54/58, 8XC51FA / FB / FC; 8XC51RA + / RB + / RC + / RD +, 8XC524 / 528/550/652/654/575/576/851; 89C535 / 536/538;
Atmel : 89C51, 89C52, 89C55; Siemens SAB501;
MHS : 80C31, 8XC51, 80C32, 8XC52, 8XC154;
Oki : 80C31, 8XC51, 8XC154; AMD: 80C31, 8XC51, 8XC52;
64K PICE-51 POD-51-RX ADP-51-DIP40 or ADP-51-LCC44
Atmel : 89C4051, 89C2051, 89C1051; 4K PICE-51 POD-51-31 or POD-51-RX ADP-51-2051
Philips : 80C451, 80C453; 87C451, 87C453 64K PICE-51 POD-51-453 ADP-51-LCC68
Philips : 80C552, 80C562; 80C554
Philips : 80C552, 80C562; 80C554, 87C552, 87C562, 87C554
Intel : 80C51GB Not PICE-51 POD-51-GB ADP-51-LCC68
Dallas : DS80C310, DS80C320, DS8XC520 64K PICE-51 POD-51-DS530 ADP-51-DIP40 or ADP-51-LCC44
Dallas : DS8XC530 64K PICE-51 POD-51-DS530 ADP-51-DS530

Comparative characteristics of some emulators for microcontrollers of the 8051 family

Model, Supplier EMUL-51 Nohau Corporation USP-51 Signum Systems iceMASTER-8051 MetaLink PICE-5 Fiton1
8051 emulated microcontrollers All known varieties All major varieties All major varieties All major varieties
Maximum emulation frequency 42 MHz 40 MHz 24 MHz 33 MHz
The maximum amount of emulated memory 320K 256K 128K 512K
The possibilities of redistributing memory between the emulator and the user device 4K blocks 256 byte blocks Blocks of 16 bytes Accurate to 1 byte
Trace buffer Up to 16K 48-bit frames Up to 32K frames of 80 bits Up to 4K 48-bit frames Up to 64K frames of 64 bits
On-the-fly access to emulated memory and tracer Yes Yes Yes Yes
Computer interface Card in ISA slot RS-232C, up to 115 Kbaude RS-232C, up to 115 Kbaude Isolated RS-232C, up to 115 Kbaude
Construction and dimensions Two cards in ISA format, 2 meter cables, PODs Enclosure 260x260x64 mm, cable, POD Enclosure 178x140x25 mm, cable, POD The entire emulator is in an emulation head measuring 80x76x50 mm
Price for a comparable delivery configuration: support 80С51, 25 MHz, 128K RAM, trace buffer of 16K frames $ 5200 (Nohau price list) $ 5300 (Signum price list) $ 4000 (MetaLink price list) $ 990

More complete information, as well as a demo version of the emulator, is presented on the Website:

Of course, such a wide range of functionality makes in-circuit emulators the most powerful and versatile debugging tool.


Simulator is a software tool that can simulate the operation of a microcontroller and its memory. As a rule, a simulator contains:

  • debugger
  • CPU and memory model.

More advanced simulators incorporate models of embedded peripherals, such as timers, ports, ADCs, and interrupt systems.

The simulator should be able to download program files in all popular formats, display information about the state of the resources of the simulated microcontroller as fully as possible, and also provide the ability to simulate the execution of the downloaded program in various modes. During debugging, the model “executes” the program, and the current state of the model is displayed on the computer screen.

Having loaded the program into the simulator, the user has the opportunity to run it in step-by-step or continuous modes, set conditional or unconditional breakpoints, control and freely modify the contents of memory cells and registers of the simulated microprocessor. Using the simulator, you can quickly check the logic of program execution, the correctness of arithmetic operations.

Depending on the class of the debugger used, various simulators may support high-level symbolic debugging of programs.

Some models of simulators may contain a number of additional software tools, such as for example: an external environment interface, an integrated integrated development environment.

In a real system, the microcontroller is usually engaged in reading information from connected external devices (sensors), processing this information and issuing control actions to actuators. In order to simulate the sensor operation in a simulator that does not have an external environment interface, you need to manually change the current state of the peripheral device model to which the sensor is connected in a real system. If, for example, when receiving a byte through a serial port, a certain flag is raised and the byte itself falls into a certain register, then both of these actions must be performed manually in such a simulator. The presence of an external environment interface allows the user to create and flexibly use the model of the external environment of the microcontroller, which functions and interacts with a debugged program according to a given algorithm. We will illustrate the capabilities of a "real" debugger simulator using the PDS-PIC model as an example.


Simulator debugger for developing and debugging programs based on PIC16 / PIC17 microcontrollers.

PDS-PIC is a convenient and flexible tool for writing and debugging programs targeted at Microchip's PICmicro microcontrollers.

The simulator has:

  • Built-in multi-window editor for writing source code for programs. The editor supports operations with blocks of text, search / replace, color selection of syntactic constructions of assembly language;
  • Built-in project manager that supports automatic compilation of programs written for Fiton's PASM-PIC macroassembler and Microchip's MPASM macroassembler.
  • All assembler options are set in the form of convenient dialogs. The transition from editing the source text to debugging and vice versa is "transparent", i.e. project manager automatically launches assembler if necessary;
  • Ample opportunities for debugging programs: tracking program execution by its source text, viewing and changing the values ​​of any variables, built-in analyzer of program code efficiency, breakpoints by condition and access to memory cells, viewing a stack of subprogram calls, built-in assembler, accurate calculation of time intervals and much more;
  • The ability to run the program "back" to a large number of steps, as well as in continuous mode. In this case, the state of the microcontroller model is fully restored;
  • An accurate model of the behavior of microcontrollers. It simulates the operation of all peripheral devices built into the microcontroller: timers, ADCs, interrupt systems, ports, etc .;
  • Developed modeling tools for the "external environment", i.e. devices connected to the microcontroller. You can easily set various periodic and non-periodic external signals on the legs of the microcontroller, simulate the operation of external logic. Using the built-in graphical display tools, you can visually display various indicators, build graphs, simulate the keyboard;
  • A system for saving the configuration of windows and settings. It is possible to save and restore an unlimited number of configuration files;
  • The ability to configure colors and fonts and other parameters for all windows simultaneously and for each window separately;
  • Context help system. From any menu, window or dialog, you can get help related to this menu, window or dialog;
  • PDS-PIC runs in a Windows environment.

In more detail, the features of the simulator are presented in the table compiled from the results of a comparative analysis of two simulators: MPlabSIM -Microchip and PDS-PIC -firms Fiton. The main features and differences of MPlabSIM and PDS-PIC are due to the fact that when designing them, conceptually different user interfaces and simulation environments were used.

the mouse
menu system
through the model of the environment
at the address of the executable code
by register content
when changing the value of an expression
when the logical condition
Simulated Events
time resolution
4 cycles of teams
1 cycle of commands
CPU resources
PWM1 / 2
Rc generator
ADC module
no delay on
only synchronously
only synchronously
without high resolution
only synchronously
only registers
time delays
without protective sequence
only delays and registers
only registers
only registers
constant frequency
only delays
synchronously / asynchronously
synchronously / asynchronously
synchronously / asynchronously
only registers and interrupt flags
only registers
only registers
frequency is set independently of the clock frequency
registers for analog inputs
Modeling of external influences
setting setpoints at the input of the input / output port
direct write to registers
cyclic effects
asynchronous effects
description (task of influences) of the external environment algorithmically
external analog signals
only synchronously (by command cycle number)
the relationship between the input and the button in the corresponding dialog
synchronously / asynchronously
Additional features
program run back (backtrace)
code execution efficiency analyzer (profiler)
process graphical capabilities
Performance **



400 teams / sec



100,000 teams / sec

* MPlabSIM uses the menu as an add-on over the line input of commands to control the simulation process with the ability to memorize and execute linear sequences of commands. For example, to change the contents of a register, you need to do the following:

- select the "WINDOWS" section in the menu - select the "MODIFY" option in the submenu - select "what" (STACK, DATA or CODE) (in this case, "DATA") are going to change - indicate the address - enter a new value - confirm the entry in the dump file window you will see the result of the change, but you can’t change anything in the window itself (only through the menu is an analogue of the command line).

Using PDS-PIC, the register value can be modified by pressing two keys. It is just as easy to perform all other actions for debugging the program.

** Based on an example from the MPLAB-sim package for 16c54, when executed on the recommended MICROCHIP configuration P90 / 16RAM.

An obvious feature of software simulators is the fact that the execution of programs loaded into the simulator takes place on a time scale different from the real one. However, the low price, the ability to debug even in the absence of a layout of the device being debugged, make software simulators a very effective debugging tool. Separately, it must be emphasized that there is a whole class of errors that can only be detected using a simulator.

Debug monitors

The debug monitor is a special program loaded into the memory of the system being debugged. It forces the user processor to produce, in addition to the application task, debugging functions:

  • loading user application codes into monitor-free memory
  • setting breakpoints
  • start and stop the loaded program in real time
  • user program step by step
  • viewing, editing the contents of memory and control registers.

The monitor program must necessarily work in conjunction with an external computer or passive terminal, on which visualization and control of the debugging process take place. Once again, debug monitors use the processor that is already on the user's board. The advantage of this approach is the very low cost while maintaining the ability to debug in real time. The main drawback is the distraction of the resources of the microcontroller to debugging and communication procedures, for example: the monitor takes up some memory, interrupts, and a serial channel. The amount of resources diverted depends on the skill of the monitor developer. Recently, products have appeared that practically do not take up the hardware resources of the processor, they will be discussed below in the "ROM emulators" section.

Development Boards

Development boards, or as they are commonly called in foreign literature, Evaluation Boards, are original designers for prototyping application systems. Recently, with the release of a new model of the microcontroller chip, the manufacturer necessarily produces the corresponding development board. Usually this is a printed circuit board with a microcontroller installed on it, plus all the standard wiring necessary for it. On this board also establish communication schemes with an external computer. As a rule, there is also a free field for mounting user application circuits. Sometimes, there is a ready-made wiring for installing additional devices recommended by the company. For example, ROM, RAM, LCD display, keyboard, ADC, etc. In addition to training or prototyping purposes, it became profitable to use such user-modified boards (time saving) as single-board controllers built into low-serial products (5..20 pcs. )

For greater convenience, development boards are also equipped with the simplest debugging tool based on the debug monitor. However, two different approaches emerged here: one is used for microcontrollers having an external bus, and the second is used for microcontrollers without an external bus.

In the first case, the debug monitor is supplied by the company in the form of a ROM chip, which is inserted into a special outlet on the development board. The board also has RAM for user programs and a communication channel with an external computer or terminal. An example here is the Intel development board for the 8051 microcontroller.

In the second case, the development board has built-in programming circuits for the internal ROM of the microcontroller, which are controlled from an external computer. In this case, the monitor program is simply entered into the ROM of the microcontroller together with the user application codes. In this case, the application program must be specially prepared: calls to the debugging routines of the monitor are inserted into its necessary places. Then a trial run is carried out. To make corrections to the program, the user must erase the ROM and re-record. The finished application program is obtained from the debugged one by deleting all calls to the monitor functions and the debug monitor itself. Examples are Microchip development boards for their PICs. The same principle applies to boards for debugging 80C750 Philips or 89C2051 Atmel microcontrollers.

It is important to note that plus to the monitor, sometimes development boards are also equipped with debugging programs that run on an external computer in conjunction with the monitor. These programs have recently become much more complicated and often have a highly professional set of debugging functions, for example, a debugger-simulator, or various elements that are inherent in pure form to integrated development environments. The supplied sets may also include application programs that are most often encountered in practice.

The debugging capabilities provided by the development board plus monitor kit are certainly not as universal as the capabilities of the in-circuit emulator, and some of the microprocessor resources are selected for debugging during the debugging process. Nevertheless, the presence of a complete set of ready-made hardware and software tools that allow installation and debugging of the application system without loss of time is, in many cases, a decisive factor. Especially when you consider that the cost of such a kit is slightly less than the cost of a more universal emulator.

ROM emulators.

The ROM emulator is a software and hardware tool that allows you to replace the ROM on the debugged board, and substitutes RAM for it, into which the program can be downloaded from the computer through one of the standard communication channels. This device allows the user to avoid multiple cycles of reprogramming the ROM. The ROM emulator makes sense only for microcontrollers that are able to access the external program memory. This device is comparable in complexity and cost to development boards. It has one great advantage: versatility. The ROM emulator can work with any type of microcontroller.

Early ROM emulators only allowed you to download a program, start it, and stop it using a general reset. Then, sophisticated models appeared with hardware generation of trace signals after reaching a certain address on the oscilloscope. The emulated memory in such products was available for viewing and modification, but very important control over the internal control registers of the microcontroller was not possible until recently.

However, there are models of intelligent ROM emulators that allow you to "look" inside the microcontroller on the user board and, in general, to control debugging, have become similar to the in-circuit emulator. Cactus even presents its virtually intelligent ROM emulator as an in-circuit emulator of a number of microprocessors, it is so impossible to distinguish between working with both. In reality, the processor is not replaced here, but the one that is on the user's board is used.

Intelligent ROM emulators are a hybrid of a conventional ROM emulator, debug monitor, and quick bus switching schemes from one to another. This creates the effect as if the debug monitor was installed on the user's board and at the same time it does not take any hardware resources from the microcontroller, except for a small area of ​​program steps, approximately 4K. For example, such a device was developed by Fiton for all existing and future microcontrollers that have a core from 8051 but are additionally saturated with various input / output devices. This device supports many different microcontrollers from Philips, Siemens, OKI.

Integrated Development Environments.

Strictly speaking, integrated development environments are not among the debugging tools, however, to ignore this class of software tools that would significantly facilitate and speed up the development and debugging of microprocessor systems would be wrong.

In the traditional approach, the initial stage of writing a program is constructed as follows:

  • The source text is typed using any text editor. Upon completion of the set, the work with the text editor is stopped and the cross compiler starts. As a rule, a newly written program contains syntax errors, and the compiler reports them to the operator console.
  • The text editor starts again, and the operator must find and eliminate the detected errors, while the messages about the nature of the errors displayed by the compiler are no longer visible, since the screen is occupied by the text editor.

And this cycle can be repeated more than once. If the program is not too small and trivial, assembled from various parts, undergoes editing or modernization, even this initial stage may require a lot of effort and time of the programmer, and significantly quench the enthusiasm of the developer.

Avoid the large volume of routine and significantly increase the efficiency of the development and debugging process, so-called Integrated Development Environment (IDE).

As a rule, a “good” integrated environment allows you to combine existing debugging tools (in-circuit emulator, software simulator, programmer) under one wing, and at the same time provides the programmer with turbo-style program texts.

Work in an integrated environment gives the programmer:

  • The ability to use the built-in multi-file text editor, specifically focused on working with the source code of programs.
  • Diagnostics of errors detected during compilation, and the source code of the program, available for editing, are displayed simultaneously in multi-window mode.
  • The ability to organize and conduct parallel work on several projects. The project manager allows you to use any project as a template for a newly created project. The options of the compilers used and the list of project source files are set in the dialog menus and saved within the project, eliminating the need to work with inconvenient batch files.
  • Only edited modules are recompiled.
  • The ability to load the debugged program into existing debugging tools, and work with them without leaving the shell.
  • The ability to connect to the shell of almost any software.

Recently, the functions of integrated development environments have become part of the programming interfaces of the most advanced emulators and debugging simulators. Such functionality, combined with a user-friendly interface, can significantly simplify the life of the developer and accelerate his work.