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

Development and debugging tools for single-chip microcontrollers

The main debugging tools include:

  • in-circuit emulators.
  • software simulators.
  • development fees (estimated fees).
  • debug monitors.
  • ROM emulators.

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

In-circuit emulators.

In-circuit emulator - software hardware that can replace an emulated processor in a real circuit. In-circuit emulator is the most powerful and universal debugging tool.

In fact, a “good” in-circuit emulator makes the process of functioning of the debugged controller transparent, i.e. easily controlled, arbitrarily controlled and modified by the developer’s will.

Functionally, in-circuit emulators are divided into dockable with an external computing machine (usually an IBM PC), and functioning autonomously. Autonomous in-circuit emulators have individual computational resources, input-output means do not require docking with any external computational means for their normal work, but the user has to pay for it either with a significantly higher price or reduced functionality and service capabilities compared to similar models docked with the IBM PC.

Usually, the in-circuit emulator is docked with the system being debugged using an emulation cable with a special emulation head. The emulation head is inserted in place of the microcontroller in the system being debugged. 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 of its outputs are in the third state. In this case, a special clip adapter is used to connect the emulator, which is connected directly to the pins 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, providing the ability to read and modify the resources of the emulated processor on the fly, i.e. during user program execution in real time;
  • software and hardware tools that provide synchronous control required 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 depend on the properties and quality of the debugger.

A good debugger allows you to:

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

More powerful debuggers, usually called high-level debuggers, also allow you to:

  • to 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 symbolic names that are more acceptable to a person, without bothering to memorize their addresses.
  • to control and analyze not only the disassembled text, but also the source code of a program written in a high-level language, and even with its 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 the resources of the emulated microcontroller.

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

Emulation memory

The presence of emulation memory makes it possible to use it in the debugging process instead of the ROM in the system being debugged, and moreover, to debug the program without using a real system or its layout. If it is necessary to make changes to the program being debugged, it is enough to load a new or modified program into the memory of the emulator, instead of reprogramming the ROM. There are models of emulators that allow the user to "substitute" emulation memory instead of ROM not only entirely, but block by block (in some models, the minimum block size can be up to 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 system being debugged and the contents of the emulation memory of the in-circuit emulator. Such memory is usually called memory with the possibility of mapping.


In essence, the tracer is a logic analyzer that operates synchronously with the processor and captures the flow of instructions being executed and the state of the 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 processor of breakpoints allows you to stop the execution of the program, or perform other actions, such as starting or stopping the tracer, when the conditions set by the user are met. Unlike the mechanism of usual breakpoints, the processor of breakpoints allows to form and track conditions of almost any degree of complexity, and at the same time the emulated process is not derived from the real-time scale.


The profiler (otherwise, the code efficiency analyzer) allows you to obtain the following information from the results of the program being debugged:

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

Analysis of the statistical information supplied by the profiler makes it easy to identify "dead" or overstressed sections of the programs, and as a result to 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 of a program to compiling and debugging it, and providing easy and fast interaction with other tools (software debugger simulator and programmer).

The presence in the program shell of the emulator built-in editor, built-in project manager and management system, can significantly facilitate the work of the developer, saving him from many routine actions. For the developer, the line between the writing of the program, its editing and debugging is erased. The transition from source code editing to debugging and back is "transparent" and synchronous with the activation of the corresponding windows, the project manager automatically starts compiling as needed and activates the corresponding windows of the program interface.

The transition to debugging a project with the help of the existing simulator debugger is also just as simple, 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 such a complex is the ability to synchronously control (from one computer) several emulators.

In general, various models of in-circuit emulators can provide the user with the ability to control and control the operation of debugged devices, with all sorts of restrictions. For example, this may be incorrect interrupt handling in 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 emulators deliberately go to limit the number of supported compilers, first of all it is typical for Western manufacturers. In these cases, the emulator is able to use only one character format.

The possibilities of the "real" in-circuit emulator, we illustrate the example of the model PICE-51.


In-circuit emulator of 8-bit microcontroller family 8051

PICE-51 is a new generation emulator created with the use of new hardware and software development technologies.

The use of programmable high-capacity matrices allowed to drastically reduce the size of the emulator without any damage to its functionality, minimize the 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 to 5V.

The reloading hardware structure of the emulator provides emulation of virtually all microcontrollers of the 8051 family, both domestically produced and firms: Intel, Philips, Siemens, Atmel, Dallas, Temic, OKI, AMD, MHS and others.

A powerful software interface in the Windows environment, is an integrated development environment that supports all stages of software development from writing the source code of a program to compiling and debugging it. The emulator support program is focused on debugging programs in a high-level language using source code .

The emulator consists of a main board with a size of 80x76mm, a removable adapter for a specific processor, and a removable emulation head for a specific type of case. On the main board are implemented: the tracer, the processor breakpoints . The plug-in adapter card contains an emulation processor for a specific type of microcontroller. Emulation heads provide installation of the emulator in the DIP and PLCC pads on the user's board. The emulator is powered by the + 5V, 0.5A power supply or directly from the device being debugged. Communication with a computer is via an electrically isolated RS-232C channel at a speed of 115 Kbaud.


  • Precise emulation - no restrictions on the use of microcontroller resources by the user program.
  • Up to 256K emulated program memory and data. Support for banking memory model. The distribution of memory between the emulator and the user device with an accuracy of 1 byte.
  • Up to 512K hardware breakpoints for accessing program memory and data.
  • Hardware support for debugging programs in high-level languages.
  • Trace 8 arbitrary external signals.
  • 4 sync user equipment outputs.
  • Real-time tracer with buffer from 16K to 64K frames of 64 bits each with on-the-fly access. Tracing of the address, data, control signals, real-time timer and 8 external user signals.
  • Programmable trace filter.
  • Hardware processor of breakpoints with the ability to set a complex emulation stop condition by a combination of address, data, control, 8 external signals, real-time timer, event counters and delay timer.
  • Four complex breakpoints that can be used independently or in combination according to the conditions 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.
  • Managed clock generator for the emulated processor. The ability to smoothly change the clock frequency from 500 kHz to 40 MHz.
  • RS-232C communication channel galvanically isolated from a computer with an exchange rate of 115 kBaud.
  • Built-in self-test equipment emulator.


  • The software is focused on working in the Windows environment on IBM-compatible computers with 386/486 / Pentium type processors;
  • The built-in multi - window editor is designed for writing source programs. The editor supports text block operations, search / replace, color highlighting of syntax constructions of assembly language and C;
  • Built-in project manager provides automatic compilation of programs. All options are set in the dialog form. The transition from editing the source text to debugging and back is "transparent", i.e. the project manager automatically starts compiling the project if necessary;
  • PICE-51 provides symbolic debugging and source-level debugging for programs created using the following compilers:
    • Intel ASM51 assembler;
    • Assembler MCA-51 of Fiton / MicroCosm ;
    • Intel's PL / M compiler;
    • assembler and C compiler by IAR Systems ;
    • C assembler and compiler by Avocet Systems Inc./HiTech ;
    • C assembler and compiler by Keil Software Inc. ;
  • Automatic saving and loading of hardware configuration files, interface and debug options. Configuration files are compatible with the PDS-51 simulator. Project portability between the PICE-51 emulator and the PDS-51 simulator;
  • Ability to customize colors, fonts and other parameters for all windows at the same time and for each window separately;

The emulator is provided with a printed operating manual and contextual electronic manual , which describe in detail its principles of operation, commands, menus, and hot keys.

Block diagram of the emulator PICE-51

Options for completing the emulator PICE-51

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 : 80С31 / 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 : 80С31 / 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 microcontroller family 8051

Model, Supplier EMUL-51 Nohau Corporation USP-51 Signum Systems iceMASTER-8051 MetaLink PICE-5 Fiton1
8051 Emulated Microcontrollers All known species All major varieties All major varieties All major varieties
Maximum emulation rate 42 MHz 40 MHz 24 MHz 33 MHz
Maximum emulated memory 320K 256K 128K 512K
The possibility of memory redistribution between the emulator and the user's device 4K blocks 256 byte blocks 16 byte blocks Accurate to the 1st byte
Trace buffer Up to 16K 48bit frames Up to 32K 80bit frames Up to 4K 48bit frames Up to 64K frames by 64 bits
On-the-fly access to emulated memory and tracer Yes Yes Yes Yes
Computer interface ISA card slot RS-232C, up to 115 Kbaude RS-232C, up to 115 Kbaude Isolated RS-232C, up to 115 Kbaude
Design and dimensions Two cards in ISA format, 2 meter cables, PODs Housing 260x260x64 mm, cable, POD Body 178x140x25 mm, cable, POD The whole emulator is in the emulation head size 80x76x50 mm
Price for a comparable delivery configuration: support 80С51, 25 MHz, 128K RAM, trace buffer with a volume 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.


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

  • debugger;
  • CPU and memory model.

More advanced simulators contain 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 on the state of the resources of the simulated microcontroller as fully as possible, and also provide opportunities for simulating the execution of the loaded program in various modes. During the debugging process, 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 ability to start 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. With the help of the simulator, you can quickly check the logic of the program, the correctness of the arithmetic operations.

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

Some models of simulators may contain a number of additional software, such as for example: the external environment interface, the built-in integrated development environment.

In a real system, a 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 operation of a sensor in a simulator that does not have an external interface, you must manually change the current state of the model of the peripheral device to which the sensor is connected in a real system. If, for example, when receiving a byte through the serial port, a certain flag is cocked and the byte itself falls into a certain register, then both of these actions need to be performed in such a simulator manually. The presence of the external interface allows the user to create and flexibly use the model of the microcontroller's external environment, which functions and interacts with the program being debugged according to a given algorithm. The possibilities of the "real" debugger simulator will be illustrated using the example of the PDS-PIC model.


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

PDS-PIC is a convenient and flexible tool for writing and debugging programs focused on PICmicro Microchip microcontrollers.

The simulator has:

  • Built-in multi-window editor for writing source programs. The editor supports text block operations, search / replace, color highlighting of assembly language syntax;
  • Built-in project manager that supports automatic compilation of programs written for the macro-assembler PASM-PIC of the company Fiton and for the macro-assembler MPASM of the company Microchip.
  • All assembler options are set in the form of convenient dialogs. The transition from editing the source text to debugging and back is "transparent", i.e. the project manager automatically starts the assembler if necessary;
  • Extensive debugging capabilities: tracking the program execution by its source text, viewing and changing the values ​​of any variables, the built-in efficiency analyzer of the program code, breakpoints by condition and access to memory cells, viewing the subroutine call stack, the built-in assembler, accurate calculation of time intervals and much more;
  • Ability to perform the program "back" in a large number of steps, as well as in continuous mode. In this case, the state of the microcontroller model is fully restored;
  • The exact model of the behavior of microcontrollers. Simulates the work of all peripherals built into the microcontroller: timers, ADC, interrupt system, ports, etc .;
  • Developed tools for modeling 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. With the help of built-in graphical display tools, you can visually display various indicators, build graphs, simulate a keyboard;
  • System save configuration windows and settings. You can save and restore an unlimited number of configuration files;
  • Ability to customize colors and fonts and other parameters for all windows at the same time and for each window separately;
  • Context help system. While in any menu, window or dialog, you can get help related to this menu, window or dialog;
  • PDS-PIC works in the 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 firms 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.

menu system
through the environment model
at the address of the executable code
by register content
when changing the value of the expression
when the logical condition is met
Simulated events
time resolution
4 command cycles
1 cycle commands
Processor resources
PWM1 / 2
RC generator
ADC module
no delay on
only synchronous
only synchronous
without high resolution
only synchronous
registers only
time delays
without security sequence
only delays and registers
registers only
registers only
dfrequency constant
only delays
synchronous / asynchronous
synchronous / asynchronous
synchronous / asynchronous
only registers and interrupt flags
registers only
registers only
the frequency is set independently of the clock frequency
registers for analog inputs
Simulation of external influences
setting input I / O port setpoints
direct entry in registers
cyclical effects
asynchronous effects
description (setting the effects) of the environment algorithmically
external analog signals
synchronous only (according to the command cycle number)
the relationship between the input and the button in the corresponding dialog
synchronous / asynchronous
Additional features
run back (backtrace)
program code performance analyzer (profiler)
process graphic display capabilities
Speed ​​**



400 teams / sec



100,000 teams / sec

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

- select the "WINDOWS" section in the menu - select the "MODIFY" option from the submenu - select "what" (STACK, DATA or CODE) (in this case, "DATA") are going to be changed - specify the address - enter the new value - confirm the input in the dump file of the register file you will see the result of the change, but you cannot change anything in the window itself (only through the menu is an analogue of the command line).

Using the PDS-PIC, you can modify the value of the register by pressing two keys. It is just as easy to perform all the other actions to debug the program.

** Using the example from the MPLAB-sim package for 16c54, when performed on the P90 / 16RAM configuration recommended by MICROCHIP.

An obvious feature of software simulators is the fact that the execution of programs loaded into the simulator occurs on a time scale different from the real one. However, the low price, the ability to debug even in the absence of a debugged device layout, makes 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 with the help of a simulator.

Debug Monitors

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

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

The monitor program must work in conjunction with an external computer or a passive terminal, on which the debugging process is visualized and controlled. We repeat that debug monitors use the same processor, which is already on the user's board. The advantage of this approach is very low cost while maintaining the ability to debug in real time. The main disadvantage is the diversion of microcontroller resources to debugging and communication procedures, for example: the monitor occupies a certain amount of memory, interrupts, serial channel. The amount of resources diverted depends on the skill of the monitor developer. Recently, there have appeared products that practically do not occupy hardware resources of the processor, they will be described below, in the “ROM Emulators” section.

Development Boards

Development boards, or as they are commonly called in foreign literature - evaluation boards (Evaluation Boards), are the original designers for prototyping application systems. Recently, with the release of a new model of the crystal microcontroller, the manufacturer necessarily releases the corresponding development fee. This is usually a printed circuit board with a microcontroller installed on it, plus all the standard strapping it needs. On this board, they also establish communication circuits with an external computer. As a rule, there is also a free field for mounting user application schemes. Sometimes, there is a ready-made layout for installing additional devices recommended by the company. For example, ROM, RAM, LCD display, keyboard, ADC, etc. In addition to training or mockups, it became advantageous (time savings) to use such user-modified boards as single-board controllers embedded in a few serial products (5..20 pcs. ).

For more convenience, development boards are also equipped with the simplest debugging tool based on a debug monitor. However, two different approaches have emerged here: one is used for microcontrollers with an external bus, and the second for microcontrollers that do not have 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 socket 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 schemes 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 microcontroller's ROM together with the user's application codes. In this case, the application program must be specially prepared: the debugging subroutines of the monitor are inserted into its proper places. Then a trial run is performed. To make corrections to the program, the user must erase the ROM and re-record. The finished application program is obtained from the debugged by removing all calls to the monitor functions and the debugging monitor itself. Examples include Microchip's development boards for their PIC controllers. The same principle applies to the debugging boards of the 80С750 Philips microcontroller or Atmel 89C2051.

It is important to note that a plus to the monitor, sometimes development boards are also completed with debugging programs that run on an external computer in conjunction with the monitor. These programs have recently become considerably more complex and often have a highly professional set of debugging functions, for example, a debugger simulator, or various elements inherent in a purely integrated development environment. The kits supplied may also include applied programs that are most commonly encountered in practice.

The debugging capabilities provided by the development board plus monitor kit are certainly not as versatile as the capabilities of the in-circuit emulator, and some of the microprocessor resources in the debugging process are selected for the monitor to work. However, the availability of a complete set of ready-made software and hardware tools that allow you to start installing and debugging an application system without losing time is in many cases a decisive factor. Especially when you consider that the cost of such a kit is somewhat less than the cost of a more universal emulator.

ROM emulators.

The ROM emulator is a software and hardware tool that allows replacing the ROM on the debugged board, and replacing in its place RAM, into which the program can be downloaded from the computer through one of the standard communication channels. This device allows the user to avoid repeated cycles of reprogramming the ROM. The emulator ROM only makes sense for microcontrollers that are able to access external program memory. This device is comparable in complexity and cost with development fees. It has one great advantage: universality. The ROM emulator can work with any types of microcontrollers.

Early ROM emulators only allowed to load the program, start it and stop it using a general reset. Then came sophisticated models with hardware-based trace generation when a certain address was reached to the oscilloscope. Emulated memory in such products was available for viewing and modification, but very important control over the internal control registers of the microcontroller was until recently impossible.

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

Intelligent ROM emulators are a hybrid of a conventional ROM emulator, debug monitor, and fast bus switch circuits from one to another. This creates an 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 ​​software steps, approximately 4K. For example, such a device was developed by the company Phyton 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; nevertheless, it would be wrong to ignore this class of software tools that would significantly simplify and speed up the process of developing and debugging microprocessor systems.

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, work with the text editor is stopped and the cross compiler is started. As a rule, a newly written program contains syntax errors, and the compiler reports them to the operator console.
  • The text editor is restarted, and the operator must find and eliminate the errors that have been detected, while the error messages displayed by the compiler are no longer visible, since the screen is occupied by a text editor.

And this cycle can be repeated more than once. If the program is not too small and trivial, is assembled from different parts, is being edited or upgraded, then even this initial stage may require a lot of time and effort of the programmer, and significantly reduce the developer's enthusiasm.

To avoid a large amount of routine and significantly improve the efficiency of the development and debugging process, allow the so-called and quickly gaining popularity. integrated development environment (shells) development (Integrated Development Environment, IDE).

As a rule, a "good" integrated environment allows you to combine available debugging tools (in-circuit emulator, software simulator, programmer) under one wing, and at the same time ensures that the programmer works with texts of programs in the "turbo" style.

Working in an integrated environment gives the programmer:

  • The ability to use the built-in multi-file text editor, specially 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 a multi-window mode.
  • Ability to organize and conduct parallel work on multiple projects. Project Manager allows you to use any project as a template for a newly created project. The options used by the compilers 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 modules that are being edited are recompiled.
  • Ability to load the program being debugged into existing debugging tools, and work with them without leaving the shell.
  • Ability to connect to the shell of almost any software.

Recently, the functions of integrated development environments are becoming a part of the software interfaces of the most advanced emulators and debuggers-simulators. Such functionality, in combination with a friendly interface, is able to significantly ease the life of the developer and speed up his work.