Development and debugging tools for single-chip microcontrollers
Major debugging tools include:
- In-circuit emulators.
- Software simulators.
- Development fees (evaluation fees).
- Debugging monitors.
- Emulators ROM.
This list does not exhaust all types of existing debugging tools. In addition to these, there are also combined devices and kits that can compensate for the shortcomings of fixed assets taken separately.
In-circuit emulator - software hardware, capable of replacing an emulated processor in a real scheme. 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 debuggable controller transparent, i.e. Easily controlled, arbitrarily managed and modified by the will of the developer.
Functionally, in-circuit emulators are divided into interfaces with an external computer (usually IBM PC), and they operate autonomously. Autonomous in-circuit emulators have individual computing resources, input-output means, do not require for their normal operation of docking with any external computing means, but for this the user has to pay either a substantially higher price or reduced functional and service capabilities in comparison with similar ones Models that interface with the IBM PC.
Usually, the docking of the in-circuit emulator with the debugged system is performed 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 can not be removed from the debugged system, then the use of the emulator is possible only if this microcontroller has a debug mode, in which all its terminals are in the third state. In this case, a special adapter-clip is used to connect the emulator, which is connected directly to the outputs of the emulated microcontroller.
At a minimum, the emulator contains the following function blocks:
- Microcontroller emulation node;
- Emulation memory;
- Subsystem of breakpoints;
More advanced models can contain in addition:
- Breakpoint processor;
- Profiler (code efficiency analyzer);
- A real time timer;
- Software and hardware, providing the ability to read and modify the resources of the emulated processor "on the fly," i.e. In the process of executing the user's program in real time;
- Software and hardware that provide 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 accessibility 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 debugged program 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:
- To conduct symbolic debugging, because the debugger "knows" the addresses of all character variables, arrays and structures (by using special information supplied by the compiler). At the same time, the user can operate with more suitable symbolic names for the person, without bothering to memorize their addresses.
- Control and analyze not only the disassembled text, but also the source code of the 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 code, the program image in the machine codes, and the state of all resources of the emulated microcontroller.
It should be noted that a high-level debugger ensures that all its functions are performed only if a cross compiler providing full and correct debugging information is used (not all compilers, especially their pirated versions, supply such information) and at the same time the presentation format should be " Sign "to the debugger.
The presence of emulation memory makes it possible to use it in the debugging process instead of ROM in the debugged system, and moreover, to debug the program without using a real system or its layout. If you need to make changes to the debugged program, it's enough to load a new or modified program into the emulator's memory instead of reprogramming the ROM. There are emulator models that allow the user to "substitute" the ROM for emulation memory not only entirely, but also in blocks (in some models the minimum block size can reach one byte), in the order defined by the user. To do this, the user just needs 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 logical analyzer that works synchronously with the processor and fixes the flow of executable instructions 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 internal resources of the microcontroller, for example, registers. Such emulators use special versions of microcontrollers (emulation crystals).
Processor of breakpoints
The processor of breakpoints allows you to stop the execution of the program, or perform other actions, for example, start or stop the tracer, when the user-specified conditions are met. Unlike the mechanism of conventional breakpoints, the breakpoint processor allows you to generate and track conditions of almost any complexity, and the emulated process is not output from the real-time scale.
The profiler (otherwise the code efficiency analyzer) allows you to obtain the following information from the run of the debugged program:
- Number of calls to different sections of the program;
- Time spent on the execution of various sections of the program.
Analysis of the statistical information supplied by the profiler makes it easy to identify "dead" or overextended parts of programs, and as a result, optimize the structure of the program being debugged.
Integrated Development Environment
A set of software that supports all stages of software development from writing the source code of the program to its compilation and debugging, and providing a simple and fast interaction with other tools (software debugger-simulator and programmer).
The presence of the built-in editor, built-in project manager and control system in the program shell make it possible to significantly simplify the developer's work, saving him from a lot of routine activities. For the developer, the line between writing a program, editing it, and debugging is blurred. 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 launches the compilation as necessary and activates the corresponding windows of the program interface.
Equally easy is the transition to debugging a project with the help of an existing debugger-simulator, or proceed to the "firmware" of the program's debugged program.
Some models of in-circuit emulators can provide users with other additional features. Among them we note one, although quite specific, but in a number of cases of fundamental importance: the possibility of constructing multi-emulator complexes necessary for debugging multiprocessor systems. A distinctive feature of such a complex is the possibility of synchronous control (from one computer) by several emulators.
In general, various models of in-circuit emulators can provide the user with the ability to monitor and control the operation of the devices being debugged, with various limitations. For example, it may be incorrect processing of interrupts in a step-by-step mode, or prohibition of using 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 companies manufacturers of emulators deliberately go to limit the number of supported compilers, in the first place it is typical for Western manufacturers. In these cases, the emulator can only use one character format.
The possibilities of the "real" in-circuit emulator will be illustrated using the PICE-51 model as an example.
In-circuit emulator of 8-bit microcontrollers of family 8051
PICE-51 - a new generation emulator, created with the use of new technologies for the development of hardware and software.
The use of programmable high-capacity matrices allowed to dramatically reduce the size of the emulator without any damage to its functionality, minimize deviations in the electric 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.
Rebootable hardware structure of the emulator provides emulation of almost all microcontrollers of the family 8051 as domestic production, and firms: Intel, Philips, Siemens, Atmel, Dallas, Temic, OKI, AMD, MHS and others.
A powerful programming 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 it and debugging it. The emulator support program is aimed at debugging programs in the high-level language using the source text .
The emulator consists of a main board with a size of 80x76mm, a replacement adapter for a specific processor and a replaceable emulation head for a specific type of case. On the main board implemented: a tracer, a processor breakpoints . The adapter board contains an emulating processor for a particular type of microcontroller. Emulation heads provide installation of the emulator in the DIP and PLCC pads on the user's board. Power emulator is carried out from the power supply + 5V, 0.5A or directly from the device being debugged. Communication with the computer - on a galvanically isolated RS-232C channel at a speed of 115 kb. ..
- Accurate emulation - no limitations on the use of the microcontroller's resources by the user program.
- Up to 256K emulated program memory and data. Support for a banked memory model. The allocation of memory between the emulator and the user's device with an accuracy of 1 byte.
- Up to 512K hardware breakpoints for accessing program and data memory.
- Hardware support for debugging programs in high-level languages.
- Trace 8 arbitrary external signals.
- 4 synchronization outputs of the user equipment.
- A real-time tracer with a buffer from 16K to 64K in 64-bit frames with on-the-fly access. Trace address, data, control signals, real-time clock and 8 external user signals.
- Programmable trace filter.
- A hardware breakpoint processor with the ability to specify a complex emulation stop condition for a combination of address, data, control, 8 external signals, real-time clock, event counters and a delay timer.
- Four complex breakpoints that can be used independently or in combinations of AND / OR / IF-THEN conditions.
- 48-bit real-time clock.
- Transparent emulation - access "on the fly" to emulated memory, breakpoints, the processor of breakpoints, the trace buffer, the real-time timer.
- Controlled clock generator for the emulated processor. The ability to smoothly change the clock frequency from 500 kHz to 40 MHz.
- Galvanically isolated from the computer communication channel RS-232C with the exchange rate of 115 KBod.
- Built-in self-diagnostic system of the emulator.
CHARACTERISTICS OF THE SOFTWARE
- The software is designed to work in a Windows environment on IBM-compatible computers with 386/486 / Pentium processors;
- The built-in multi - window editor is intended for writing program source code. The editor supports operations with text blocks, search / replace, color selection of assembler and C language syntax;
- The built-in project manager provides automatic compilation of programs. All options are set in a dialog form. The transition from editing source code to debugging and vice versa occurs "transparently", i.e. The project manager automatically starts the compilation of the project if necessary;
- PICE-51 provides symbolic debugging and debugging on the source text for programs created with the help of the following compilers:
- Assembler ASM51 of Intel ;
- Assembler MCA-51 firm Fiton / MicroCosm ;
- The Intel PL / M compiler;
- Assembler and C compiler of IAR Systems ;
- Assembler and C compiler of Avocet Systems Inc./HiTech ;
- The assembler and the C compiler of Keil Software Inc. ;
- Automatically save and load hardware configuration files, interface and debug options. The configuration files are compatible with the PDS-51 simulator. The portability of projects between the PICE-51 emulator and the PDS-51 simulator is provided;
- Ability to customize colors, fonts and other settings for all windows simultaneously and for each window separately;
The emulator is equipped with a printed instruction manual and contextual electronic manual , which details its operating principles, commands, menus, hot keys.
Structural diagram of the PICE-51 emulator
Options for the PICE-51 emulator
|Emulated Microcontroller||Emulation of internal program memory||Contents of delivery|
|Baseboard||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;
|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 : 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||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 microcontrollers of the family 8051
|Model, Supplier||EMUL-51 Nohau Corporation||USP-51 Signum Systems||IceMASTER-8051 MetaLink||PICE-5 Fiton1|
|8051 family of 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|
|Maximum amount of emulated memory||320K||256K||128K||512K|
|The ability to reallocate memory between the emulator and the user device||Blocks of 4K||Blocks of 256 bytes||Blocks of 16 bytes||To within one byte|
|Trace Buffer||Up to 16K 48-bit frames||Up to 32K frames with 80 bits||Up to 4K 48-bit frames||Up to 64K 64-bit frames|
|Access "on the fly" to the emulated memory and tracer||Yes||Yes||Yes||Yes|
|Interface with a computer||The card in the ISA 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, cables 2 meters, PODs||Housing 260x260x64 mm, cable, POD||Housing 178x140x25 mm, cable, POD||The whole emulator is in the emulation head of 80x76x50 mm|
|The price for a comparable configuration of the delivery: support 80С51, 25 MHz, 128K RAM, the tracer buffer volume 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 available 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.
Simulator - a software tool that can simulate the operation of the microcontroller and its memory. Typically, the simulator contains in its composition:
- Model of CPU and memory.
More advanced simulators contain models of built-in peripherals, such as timers, ports, ADCs, and interrupt systems.
The simulator should be able to load program files in all popular formats, fully display information about the status of the resources of the simulated microcontroller, 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 status of the model is displayed on the computer screen.
Having downloaded the program into the simulator, the user has the opportunity to run it in step-by-step or continuous mode, set conditional or unconditional breakpoints, control and freely modify the contents of the memory cells and registers of the simulated microprocessor. With the help of the simulator, you can quickly check the logic of program execution, the correctness of performing arithmetic operations.
Depending on the class of debugger used, various simulators can support high-level symbolic debugging of programs.
Some simulation models may contain a number of additional software tools, such as: an external environment interface, an integrated integrated development environment.
In a real system, the microcontroller usually reads information from the connected external devices (sensors), processes this information, and issues control actions to the actuators. In order to simulate the work of the sensor in a simulator that does not have an interface of the external environment, it is necessary to manually change the current state of the model of the peripheral device to which the sensor is connected in the real system. If, for example, when receiving a byte through a serial port, a certain flag is cocked, and the byte itself falls into a specific register, then both of these actions must be performed manually in such a simulator. 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 a "real" debugger-simulator will be illustrated using the PDS-PIC model as an example.
Debugger-simulator for the development and debugging of programs based on microcontrollers PIC16 / PIC17.
PDS-PIC is a convenient and flexible tool for writing and debugging programs oriented to microchip microcontrollers PICmicro.
The simulator has:
- Built-in multi-window editor for writing program source code. The editor supports operations with blocks of text, search / replace, color selection of syntaxes of the assembly language;
- A built-in project manager that supports automatic compilation of programs written for the macro assembler PASM-PIC of Fiton and for the macroassembler MPASM from Microchip.
- All the assembler options are set in convenient dialogs. The transition from editing source code to debugging and vice versa occurs "transparently", i.e. The project manager automatically starts the assembler if necessary;
- Wide possibilities for debugging programs: tracking the execution of the program by its source text, viewing and changing the values of any variables, built-in program code analyzer, condition breakpoints and access to memory cells, viewing the stack of subroutine calls, built-in assembler, precise timing and Much more;
- The ability to execute 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 completely restored;
- Exact model of the behavior of microcontrollers. It simulates the operation of all peripherals built into the microcontroller: timers, ADCs, interrupt systems, 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 feet of the microcontroller, to simulate the operation of external logic. With the help of built-in graphical display you can visually display various indicators, build graphics, simulate the keyboard;
- The system of saving the configuration of windows and settings. It is possible to save and restore an unlimited number of configuration files;
- Ability to adjust colors and fonts and other parameters for all windows simultaneously and for each window separately;
- The contextual help system. Being in any menu, window or dialog, you can get help relating to this menu, window or dialog;
- PDS-PIC works in a Windows environment.
More details of the simulator are presented in the table, compiled from the results of a comparative analysis of two simulators: MPlabSIM- firm Microchip and PDS-PIC - firm Fiton. The main features and differences of MPlabSIM and PDS-PIC are due to the fact that they used conceptually different user interfaces and environments for simulation.
|Modeling of external influences|
* MPlabSIM uses the menu as an add-on above the line input of the commands for controlling the simulation process, with the ability to store and execute linear command sequences. For example, to change the contents of a register, you need to do the following:
- select "WINDOWS" in the menu - select the option "MODIFY" in the submenu - select "what" (STACK, DATA or CODE) (in this case "DATA") are going to change - specify the address - enter a new value - confirm the input In this case In the dump window of the register file you will see the result of the change, but in the window itself you can not change anything (only through the menu - analog command line).
Using PDS-PIC, you can modify the value of the register by pressing two keys. It's just as easy to do all the other debugging steps.
** On the 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 possibility of debugging even in the absence of a model of a debugged device, make software simulators a very effective means of debugging. Separately it is necessary to emphasize that there is a whole class of errors that can be detected only with the help of a simulator.
A debugging 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 task, also debugging functions:
- Loading user application codes into a memory free from the monitor
- Setting breakpoints
- Start and stop the downloaded program in real time
- Pass the user program in steps
- Viewing, editing the contents of memory and control registers.
The monitor program must work in conjunction with an external computer or a passive terminal, where the debugging process is visualized and controlled. Again, the debug monitors use the processor that is already on the user's board. The advantage of this approach is very low costs while maintaining the ability to debug in real time. The main drawback is the diversion of microcontroller resources to debugging and communication procedures, for example: the monitor takes up some memory, interrupts, serial channel. The amount of abstracted resources depends on the art of the monitor developer. Recently, there have appeared products that practically do not occupy the hardware resources of the processor, they will be described below, in the section "Emulators ROM".
Development boards, or as they are called in the foreign literature - evaluation boards (Evaluation Boards), are original designers for prototyping application systems. Recently, with the release of a new model of a microcontroller crystal, the manufacturer necessarily produces an appropriate development fee. Usually this is a circuit board with a microcontroller installed on it, plus all the necessary standard piping. On this board also establish communication schemes with an external computer. As a rule, there is also a free field for installation of user applications. Sometimes, there is already ready wiring for installing additional devices recommended by the company. For example, ROM, RAM, LCD display, keyboard, ADC, etc. In addition to educational or mock-up purposes, such user modified boards became profitable (saving time) to use 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 the debug monitor. However, two different approaches emerged: one is used for microcontrollers that have an external bus, and the second is 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 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 stored in the microcontroller ROM together with the user's application codes. The application program should be specially prepared: the calls to the debugging subroutines of the monitor are inserted into the necessary places. Then a test run is carried out. To make corrections to the user, the user must erase the ROM and re-record. A ready-made application program is obtained from the debugged program by removing all monitor function calls and the debug monitor itself. Examples include Microchip development boards for their PIC controllers. The same principle applies to circuit boards for debugging microcontrollers 80S750 Philips or 89C2051 Atmel.
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 noticeably more complex and often have a highly professional set of debugging functions, such as a debugger-simulator, or various elements inherent in the pure form of integrated development environments. The supplied kits may include programs of an applied nature, which are most often encountered in practice.
The debugging capabilities provided by the "development plus monitor" bundle are certainly not as versatile as the capabilities of the in-circuit emulator, and some of the microprocessor resources are selected for the monitor during debugging. Nevertheless, the availability of a complete set of ready-made software and hardware that allow you to start installing and debugging the application system without wasting time is in many cases a decisive factor. Especially when you consider that the cost of such a set is slightly less than the cost of a more versatile emulator.
Emulator ROM - firmware that allows you to replace the ROM on the debugged card, and substitute instead of RAM, which can be downloaded from the computer through a computer through one of the standard communication channels. This device allows the user to avoid multiple reprogramming cycles of the ROM. The ROM emulator makes sense only for microcontrollers that are able to access external program memory. This device is comparable in complexity and cost with development boards. It has one great virtue: universality. Emulator ROM can work with any type of microcontroller.
Early ROM emulators allowed only to load the program, start it and stop using a common reset. Then there were sophisticated models with hardware generation of trace signals after reaching a specific address on 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 were models of intelligent ROM emulators that allow you to "look inside" the microcontroller on the user's board and in general, to control debugging, have become similar to an in-circuit emulator. Firm Cactus even represents its virtually intelligent emulator ROM, as an in-circuit emulator of a number of microprocessors, so it is impossible to distinguish between work with both. In fact, the processor is not replaced here, but the one that is on the user's board is used.
Intelligent ROM emulators are a hybrid from a conventional ROM emulator, a debug monitor, and quick-change bus circuits from one to the other. This creates an effect, as if the debugging monitor was installed on the user's board and at the same time it does not occupy any hardware resources at the microcontroller, except for a small zone of program steps, approximately 4K. For example, such a device was developed by the firm "Fiton" for all existing and future microcontrollers, which 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 environment.
Strictly speaking, integrated development environments do not belong to the number of debugging tools, nevertheless, bypassing this class of software tools, which greatly facilitates and accelerates the process of developing and debugging microprocessor systems, it would be wrong.
With the traditional approach, the initial stage of writing the program is constructed as follows:
- The source text is typed using a text editor. Upon completion of the set, work with the text editor is stopped and the cross compiler is started. As a rule, the newly written program contains syntactic errors, and the compiler reports them to the operator console.
- The text editor is restarted and the operator must find and fix the detected errors, while messages about the nature of the errors 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 various parts, is edited or upgraded, then even this initial stage can require a lot of programmer's power and time, and substantially extinguish the developer's enthusiasm.
Avoid a large amount of routine and significantly improve the efficiency of the development and debugging process, allow emerging and rapidly gaining popularity of the so-called. Integrated development environments (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 it provides the programmer with the texts of programs in the style of "turbo".
Work in an integrated environment gives the programmer:
- The ability to use the built-in many file-based text editor, specifically designed to work with the source code of programs.
- Diagnostics detected during the compilation of errors, and the source code of the program, available for editing, are displayed simultaneously in multi-window mode.
- Possibility of organizing and conducting parallel work on several projects. The project manager allows you to use any project as a template for the 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 the edited modules are recompiled.
- The ability to load the debugged program into existing debugging tools, and work with them without exiting the shell.
- The ability to connect to the shell of virtually any software.
Recently, the functions of integrated development environments become the membership of the programming interfaces of the most advanced emulators and debuggers-simulators. Such functionality, in combination with a user-friendly interface, is able to greatly facilitate the life of the developer and speed up its work.