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.
An in-circuit emulator is software and hardware capable of replacing the emulated processor in a real circuit. The 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 modifiable at the behest of the developer.
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 either a significantly higher price or reduced functionality and service capabilities compared to similar models docked with the IBM PC.
Usually, docking of the in-circuit emulator with the system being debugged is performed using an emulation cable with a special emulation head. The emulation head is inserted instead of the microcontroller into the system being debugged. If the microcontroller cannot be removed from the system being debugged, 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:
- microcontroller emulation node;
- emulation memory;
- breakpoint subsystem;
More advanced models may additionally contain:
- breakpoint processor;
- profiler (software code efficiency analyzer);
- real time timer;
- software and hardware that provides 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 volume 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:
- load 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 text 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.
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, which allow the user to “substitute” instead of ROM emulation memory not only entirely, but block by block (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 set 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 tracing 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).
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 specified 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, a 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;
- the time spent on the implementation of various parts of the program.
The analysis of the statistical information supplied by the profiler makes it possible to easily identify "dead" or overstressed sections of the 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 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 an 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 incremental 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 has dramatically reduced the size of the emulator without any damage to its functionality, minimizing the deviations of the electrical and frequency characteristics of the emulator from the characteristics of the emulated processor and, thus, achieve maximum emulation accuracy at frequencies up to 30 MHz at supply voltages from 3.3V to 5V.
The reloadable 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 its compilation and debugging. 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: tracer, breakpoint processor . 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 from the + 5V, 0.5A power supply or directly from the device being debugged. Communication with a computer is via a galvanically isolated RS-232C channel at a speed of 115 Kbaud.
CHARACTERISTICS OF EQUIPMENT
- 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 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 condition for stopping emulation 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 the emulated memory, breakpoints, breakpoint processor, trace buffer, real-time timer.
- Managed clock frequency 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-diagnostic equipment emulator.
SPECIFICATIONS OF THE SOFTWARE
- 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 ;
- assembler and C 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 simultaneously 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;
|No||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||No||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 the 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||Enclosure 260x260x64 mm, cable, POD||Enclosure 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: http://www.phyton.ru
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:
- 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. In the process of 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 ability 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. With the help of the simulator, you can quickly check the logic of the program, the correctness of arithmetic operations.
Depending on the class of debugger 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: an external environment interface, a 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 specific register, then both of these actions must be performed in such a simulator manually. The presence of the interface of the external environment allows the user to create and flexibly use the model of the external environment of the microcontroller, 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 syntax constructions of assembly language;
- 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" on 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 operation of all peripherals embedded in the microcontroller: timers, ADC, interrupt system, ports, etc .;
- Developed tools for modeling the "external environment", i.e. devices connected to the microcontroller. It is easy to set various periodic and non-periodic external signals on the legs of the microcontroller, to 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;
- The ability to customize 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 that 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.
|Simulation of external influences|
* 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 need to do the following:
- 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 running 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, low cost, 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 be detected only with the help of a simulator.
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 as well:
- 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 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 cohesive procedures, for example: the monitor takes up some 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, or as they are commonly called in foreign literature - evaluation boards (Evaluation Boards), are 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 that are built into 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 right 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 debugging boards for Philips 80С750 microcontrollers 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 often encountered in practice.
The debugging capabilities provided by the development board plus monitor kit are certainly not as versatile as the capabilities of an 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.
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 reprogramming cycles of 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: versatility. 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, more sophisticated models appeared with hardware-based trace generation upon reaching a specific address on the oscilloscope. The emulated memory in such products was available for viewing and modification, but a very important control over the internal control registers of the microcontroller was until recently impossible.
However, models of intelligent ROM emulators have appeared, which allow you to “look inside” the microcontroller on the user's board and, in general, for debugging control, have become similar to an in-circuit emulator. Firm Cactus even presents its actually intelligent ROM emulator, like 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 debugging 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 as follows:
- The source text is typed using any text editor. Upon completion of the set, work with a 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 generated 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 various 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 the available debugging tools (in-circuit emulator, software simulator, programmer) under one wing, and at the same time ensures that the programmer works with the 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 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 the edited modules are recompiled.
- Ability to load the program being debugged into the available 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.