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.
As a matter of fact, a "good" in-circuit emulator makes the process of functioning of the debugged controller transparent; 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 functioning autonomously. Stand-alone in-circuit emulators have individual computing resources, input-output facilities, do not require for their normal operation of docking with any external computing facilities, 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 debugging 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;
- the tracer;
- 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 execution of 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 debugger. The composition and volume 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, modify them.
- management of the emulation process.
More powerful debuggers, usually called high-level (Debuggers), besides this, 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 remember 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 format of its presentation 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 program being debugged, 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 tracing 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 regular breakpoints, the breakpoint processor allows you to create and monitor conditions of almost any degree of complexity, and the emulated process is not output from the real-time scale.
The profiler (otherwise the program 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 parts of the program.
Analysis of statistical information provided by the profiler makes it easy to identify "dead" or overstrained sections 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 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 actions. 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 starts 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 to proceed to the firmware of a well-functioning 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 with the example of the PICE-51 model.
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 arrays has made it possible 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 power supplies 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 the program to compiling it and debugging it. The emulator support program is aimed at debugging programs in a 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 enclosure. 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 on access to 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 signals, 8 external signals, a real-time timer, 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 timer.
- Transparent emulation - access "on the fly" to emulated memory, breakpoints, the processor of breakpoints, the trace buffer, the real-time timer.
- The 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 an exchange rate of 115 KBod.
- Built-in self-diagnosis 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 PL / M compiler of Intel ;
- Assembler and C compiler of IAR Systems ;
- Assembler and C compiler of Avocet Systems Inc./HiTech ;
- Keith Assembler and compiler of the company 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 emulator PICE-51 and simulator PDS-51 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.
The structure of the emulator PICE-51
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 Phyton1|
|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||4K blocks||Blocks of 256 bytes||Blocks of 16 bytes||To within one byte|
|Trace Buffer||Up to 16K 48-bit frames||Up to 32K frames of 80 bits||Up to 4K 48-bit frames||Up to 64K 64-bit frames|
|Access "on the fly" to the emulated memory and tracer||Yes||Yes||Yes||Yes|
|Interface with 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 with the size 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 include 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 opportunities for simulating the execution of the downloaded program in various modes. During debugging, the model "executes" the program, and the current state of the model is displayed on the computer screen.
Having loaded the program into the simulator, the user has the opportunity to run it in step-by-step or continuous modes, set conditional or unconditional breakpoints, control and freely modify the contents of 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 normally 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, 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 in accordance with a given algorithm. The possibilities of the "real" debugger-simulator will be illustrated by the example of the PDS-PIC model.
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 assembler language;
- A built-in project manager that supports automatic compilation of programs written for the macro assembler PASM-PIC of Fiton and for the Macassembler 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 code efficiency analyzer, condition breakpoints and access to memory cells, viewing the stack of subroutine calls, built-in assembler, accurate 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. The work of all peripheral devices embedded in the microcontroller is simulated: 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;
- System saving configuration 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 to line input of 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 register dump window you will see the result of the change, but in the window itself you can not change anything (only through the menu - the analog of the 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 activities.
** On the example of 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 should be emphasized 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 of application codes of the user into the memory free from the monitor
- setting breakpoints
- start and stop the downloaded program in real time
- Passing 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, on which the visualization and control of the debugging process takes place. Let's repeat that debug monitors use that processor, which already stands 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 debug and coherent 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 chip, the manufacturer necessarily produces an appropriate development fee. Usually this is a printed 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 greater 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 with an external bus, and the second for microcontrollers that do not have an external bus.
In the first case, the debugging 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 is the Intel development board for the 8051 microcontroller.
In the second case, the development board has built-in circuits for programming the internal ROM of the microcontroller, which are controlled from an external computer. In this case, the monitor program is simply written into 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 one by removing all calls of the monitor functions and the debugging 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 a 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 can 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 the in-circuit emulator. Firm Cactus even represents its virtually intelligent emulator ROM, as an in-circuit emulator of a number of microprocessors, it is so 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 take any hardware resources from the microcontroller, except for a small zone of program steps, about 4K. For example, such a device was developed by Fiton for all existing and future microcontrollers, which have a core of 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, to ignore this class of software, 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. At the end of the set, work with the text editor stops and the cross compiler starts. 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, assembled from various parts, 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, allowing 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 (an in-circuit emulator, software simulator, programmer) under one wing, and at the same time it provides a programmer with text programs in the "turbo" style.
Work in an integrated environment gives the programmer:
- Ability to use built-in a lot of 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, accessible to editing, are displayed simultaneously in a 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 a debugged program into existing debugging tools, and work with them without exiting the shell.
- 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 significantly simplify the life of the developer and speed up its work.