|
Arabic
Bengali
Chinese
English
French
German
Hebrew
Hindi
Italian
Japanese
Korean
Malay
Polish
Portuguese
Spanish
Turkish
Ukrainian
Vietnamese|
ENCYCLOPEDIA OF RADIO ELECTRONICS AND ELECTRICAL ENGINEERING Microcontrollers for beginners and beyond. Encyclopedia of radio electronics and electrical engineering
Encyclopedia of radio electronics and electrical engineering / Microcontrollers FIRST MEETING First, a few words for those to whom the theme of the cycle, judging by its title, seems a priori uninteresting or "foreign". Perhaps you have not yet used microcontrollers in your designs (hereinafter referred to as MK for brevity) and you think that in the foreseeable future you will be able to do without them. It is also possible that you assume that building a microcontroller system to solve your problem would be too cumbersome and not economically viable. Do not rush: especially for you, we want to give a few facts and some statistics. For example, let's take the closest relative of MK - a personal computer - and compare the intensity of their use. According to analyst firm Loewenbaum & Co. Inc. (USA), the number of personal computers released in the world in 1997 reached approximately 20 million units. Agree, this is a lot. Now imagine that this gigantic number is only 0,2% of the global production of MK. According to the analytical company IC Insights Inc. (USA) the world market in 1998 absorbed more than 13,5 billion of them! The conclusion suggests itself. If even today it is difficult to find a field of human activity where the computer would not be effectively used, then what can we say about MK? Why have they become so popular and literally indispensable? The answer lies in the very structure of the microcontroller. As a first approximation to the definition of this concept, we can assume that the MC is a computer located in a single microcircuit. Hence its main attractive qualities: small dimensions, consumption, price; high performance, reliability and the ability to be adapted to perform a wide variety of tasks. MK differs from a microprocessor in that, in addition to the central processing unit (CPU), it contains memory and numerous input / output devices: analog-to-digital converters, serial and parallel information channels, real-time timers, pulse-width modulators (PWM), programmable pulse generators and etc. In its structure and principle of operation, the MK, in essence, does not differ from a personal computer. Therefore, the words microcontroller and microcomputer are synonymous. However, the first term (from the English word control - manage) is more common, because it reflects its main purpose - use in automatic control systems built into a variety of devices: credit cards, cameras, cell phones, stereos, TVs, VCRs and camcorders, washing machines. cars, microwave ovens, burglar alarm systems, gasoline engine ignition systems, locomotive electric drives, nuclear reactors, and much, much more. Embedded control systems have become such a mass phenomenon that a new branch of the economy has actually been formed, called Embedded Systems (embedded systems - English). Currently, thousands of varieties of MK are produced in the world. They are supplied in packages with 8 to 356 pins, operate at temperatures from -55 to +125oC at frequencies from 32 kHz to 200 MHz, are capable of operating at a supply voltage of 1,2 V, while consuming a current not exceeding a few microamperes. . The price of products is also constantly decreasing. Some eight-bit MCUs already today cost no more than 50 cents, which is comparable to the cost of one "hard logic" chip. All this has led to the fact that today it is more and more difficult to find an area of human activity where MC would not find application, and the process of their distribution has an avalanche-like character. We hope that the above facts have already set you up for a respectful attitude towards the main character of our story. Indeed, MC has become a global event, invading almost all types of human activity. What provided such a rapid growth in the popularity of these products, which appeared a little over 25 years ago? What are these devices and what are their capabilities and prospects? If you have not yet used MC or systems based on them in your activities, then. maybe it's time to think about it? And if you decide to apply MK, then what should be the sequence of your actions? What difficulties may await you, what can help you along the way? We will try to answer these questions in the proposed series of articles. MOORE'S LAW AND THE FIRST MK Back in 1965, Gordon Moore, one of the future founders of the powerful Intel Corporation, drew attention to an interesting fact. Having plotted the performance growth of memory chips, he discovered an interesting pattern: new models of chips appeared every 18 to 24 months, and their capacity approximately doubled each time. If this trend continues, G. Moore suggested, then the power of computing devices will increase exponentially over a relatively short period of time. G. Moore's prediction was subsequently brilliantly confirmed, and the pattern he discovered is observed today, and with amazing accuracy, being the basis for numerous forecasts of productivity growth. In the 28 years that have elapsed since the advent of the 4004 microprocessor (1971), the number of transistors on a chip has increased by more than 12 times: from 000 to 2 in the Sorrettué chip. Well, in 1976, the exponential development of semiconductor technology led to the creation by Intel of the first MK - 8048. In addition to the CPU, it included program memory, data memory, an eight-bit timer and 27 I / O lines. Today, the 8048 is already history, but the next product, released by Intel in 1980, is still alive and well. This is MK 8051. ARCHITECTURE MK 8051 This MK can be considered a classic model, in the image and likeness of which many other products were later created. Its block diagram is shown in fig. 1. CPU - the main node of the MK. It is associated with such an important concept as a command system.
The instruction set is a unique set of binary codes specific to a given CPU that defines a list of all its possible operations. Each such code defines one operation and is called an operation code or command. The more codes used in the instruction set, the more operations the CPU can perform. MK 8051 is eight-bit, so its opcodes are 8 bits in size. Theoretically, there can be a total of 256 eight-bit opcodes. 8051 uses 255. Depending on the number of operation codes used, the instruction systems are divided into two groups: CISC and RISC. The term CISC means a complex system of commands and is an abbreviation of the English definition of Complex Instruction Set Computer. Similarly, the term RISC means a reduced instruction set and comes from the English Reduced Instruction Set Computer. The command system MK 8051 can be attributed to the C15C type. However, despite the widespread use of these concepts, it must be recognized that the names themselves do not reflect the main difference between the CISC and RISC command systems. The main idea of the RISC architecture is a careful selection of such combinations of operation codes that could be executed in one cycle of the clock generator. The main gain from this approach is a sharp simplification of the hardware implementation of the CPU and the ability to significantly increase its performance. Initially, it was possible to implement such an approach only by significantly reducing the set of commands, hence the name RISC was born. For example, the instruction set of the MK of the Microchir PIC family includes only 35 instructions and can be classified as RISC. Obviously, in the general case, several instructions of the RISC architecture must correspond to one instruction of the CISC architecture. However, the performance gains from the RISC architecture usually outweigh the losses from the less efficient instruction set, resulting in a higher efficiency of the RISC system as a whole compared to the CISC. So. the fastest command MK 8051 is executed in 12 cycles. Even if three RISC controller instructions need to be executed for each instruction, in the end, the RISC architecture will provide a fourfold increase in performance. Along the way, RISC-architecture allows you to solve a number of tasks. Indeed, with the simplification of the CPU, the number of transistors necessary for its implementation decreases, therefore, the area of \uXNUMXb\uXNUMXbthe crystal decreases. This results in a reduction in cost and power consumption. At this point, one could exclaim: the future belongs to the RISC architecture! However, the line between these two concepts is rapidly blurring. For example. Atmel's AVR-family MCUs have a 120-instruction instruction set, which corresponds to the CISC type. However, most of them are executed in one cycle, which is a hallmark of the RISC architecture. Today it is generally accepted that the main feature of the RISC architecture is the execution of instructions in one cycle of the clock generator. The number of commands in itself does not matter anymore. The clock generator generates pulses to synchronize the operation of all nodes of the device. The frequency of their repetition can be set by a quartz resonator or an RC circuit connected to the outputs of the MK. In some MKs, a clock generator operation mode is provided without the use of external elements. In this case, the frequency of the clock pulses depends on the parameters of the crystal, which are determined during its production. ROM is a read-only memory device designed to store programs, so this memory is often called code or program memory. Until recently, there were two main types of ROM - masked and programmable. Information is entered into mask ROMs during the manufacturing process of the MC using technological templates - masks. It cannot be changed after the end of the production cycle. Such ROMs are used only in cases where the quality of the program is beyond doubt and there is a massive need for MK with this particular program. The advantage of mask ROMs is the lowest cost in mass production (from several thousand pieces). Programmable ROM information is written using a device called a programmer. MK with such ROMs are of two types: once and repeatedly programmable (reprogrammable). The first, as the name itself says, allow only one-time programming, after which it is no longer possible to erase the information (MK with OTP memory - from the English. One Time Programmable). They are used in small-scale production (up to 1000 pieces). when the use of mask MK is not economically justified. Repeatedly programmable microcircuits are divided into MK equipped with ROM with erasure by ultraviolet irradiation (available in packages with a "window"), and MK with electrically reprogrammable memory. The disadvantage of MC with ROM with erasure by ultraviolet irradiation is a very high cost and a relatively small number of write / erase cycles (depends on the total dose of crystal irradiation and usually does not exceed 15 ... 20) Currently, a new technology for the implementation of ROM is becoming more and more popular - Flash-memory. Its main merit is that it is built on the principle of electrical reprogrammability. i.e., it allows multiple erasing and recording of information using programmers. The minimum guaranteed number of write/erase cycles usually exceeds several thousand. This significantly increases the life cycle and increases the flexibility of MC systems. since it allows you to make changes to the MC program both at the stage of system development and during its operation in a real device. RAM is a random access memory used to store data, so this memory is also called data memory. The number of read and write cycles in the RAM is not limited, but when the supply voltage is turned off, all information is lost. The architecture of the MK 8051 involves the separate use of program and data memory and is called Harvard. Typically, this architecture is used to improve system performance by separating program and data memory access paths, but in the 8051 it was used to achieve program and data memory that did not require the same size. The antipode of Harvard - the von Neumann architecture - involves the storage of programs and data in a shared memory and is most typical for microprocessors designed for use in computers. An example is the x86 family of microprocessors. Timers TO, T1 are sixteen-bit programmable timers/counters that can be programmed to perform a variety of functions. They can be used for accurate formation of time intervals, counting pulses at the outputs of the MK, forming a sequence of pulses, clocking the transceiver of a serial communication channel. Timers/counters are capable of generating interrupt requests, switching the CPU to service them on events and freeing it from the need to periodically poll the state of the timers. Since the main application of MK is found in real-time systems, timers / counters are their indispensable element. In some modifications, the number of timers reaches 32. The serial port is a channel for information exchange between the MK and the outside world. Such communication channels occupy a minimum number of crystal pins, providing communication over significant distances with minimal hardware costs. The 8051 implements a universal asynchronous serial transceiver (UART) that supports the RS-232C standard protocol, which makes it possible to organize communication between this MK and a personal computer. In addition to RS-232C, the most popular protocols in the world of embedded systems are RS-485. I2C (two-wire bi-directional bus). SPI (XNUMX-wire serial peripheral interface). Bitbus (serial control bus), CAN (inter-controller network interface), USB (universal serial bus) and some others. For almost any type of serial channel, today you can find an MK that has a corresponding serial port in its composition. Parallel I/O ports are also an essential part of any MCU. Usually they are used to communicate with the immediate environment - sensors and actuators. An important feature of the MK parallel ports is the ability to be programmed to perform several functions. For example, on the 8051, port pins P0 and P2 can be used either as normal static I/O registers, or as an address and data bus for connecting external devices such as additional program memory, data memory, I/O devices. This gives MK architectural flexibility. The RXNUMX port can either be used as a static I/O register, or perform special functions for the operation of a serial channel, timers, interrupt controller, etc. The reprogrammability allows you to use all the outputs of the MC in the designed device with maximum efficiency. The interrupt system is one of the most important parts of MK. A feature of real-time systems is that for them an extremely important parameter is the response time to external events. Let's explain with a simple example. When you make a mathematical calculation on a computer, you usually run a program designed to perform these calculations, and after it is loaded into the computer's memory, enter the problem statement and wait for the result. The waiting time in this case is not of fundamental importance (within reason, of course) - the slow operation of the computer can be annoying, but this will not affect the result. The real-time system assumes a very specific, calculated at the development stage, the speed of the control system's response to external events. Delays beyond the calculated ones are simply unacceptable here - they can lead to catastrophic consequences. Problems of quick response to events are solved by organizing a system of interrupts. It implies that for each such event a separate "piece" of code is developed, which forms the MK's reaction to it. This "piece" of code is called an interrupt request routine (the term interrupt routine is often used for brevity) and is placed in program memory at a known address. At the moment of occurrence of a given event, a signal about this is sent to the input of the interrupt controller. The latter is a device that establishes a one-to-one correspondence between the input signal about an event that has occurred and the program memory address at which the entry point to the interrupt request processing routine from this event is located. The controller interrupts the CPU execution of the current program and initiates its transition to the execution of the interrupt service routine. The time elapsed from the moment the event occurred to the beginning of the execution of the first instruction of the interrupt routine is called the response time of the MC to the event. After processing is complete, the CPU automatically returns to the execution of the interrupted program. Another function of the interrupt controller is to prioritize events. The concept of priority means that a running interrupt routine can only be interrupted by another event if it has a higher priority than the current one. Otherwise, the CPU will move on to processing a new event after finishing processing the previous one. The interrupt controller, which is part of the MK 8051, has five event inputs: two from external devices, two from timers and one from the serial channel. Usually, when they talk about any MK, they always mention the family to which it belongs. One family includes products that have the same core, which is understood as a set of such concepts as a system of instructions, a CPU operation sequence diagram, organization of program memory and data memory, an interrupt system, and a basic set of peripheral devices. In fact, in Fig. 1 shows the core, which became the basis for the creation of hundreds of other modifications of the 8051 family. The differences between its various representatives are mainly in the composition of peripheral devices and the amount of program or data memory. Since the range of tasks solved by MK. extremely wide, their manufacturers are trying to release as many modifications to satisfy the most diverse consumer needs. In many families, the number of modifications approaches a hundred or even exceeds this value. The most important feature of the family is software compatibility at the level of the binary code of all MKs included in it. This allows system developers to replace one family of microcontrollers with others without losing their software developments. Naturally, the greater the number of varieties included in the family, the more likely it is to choose the best option, the more attractive this family is for the developer. The question of the right choice of a MC family for a new development is a strategic one, since the problem of software transfer between products of different families is extremely complex, and even the use of high-level languages does not always allow solving it without great losses. We will return to the issue of selection criteria in the following articles of the cycle. Program development is one of the most important stages in the creation of a MK-based device. Without it, he is "dead", does not respond to external influences and does not issue control signals. When the power is turned on, the MCU immediately starts executing the program located in the program memory (usually ROM) connected to it. Its execution starts from some fixed address, most often zero. An address is simply a ROM cell number. The process is as follows: the MCU reads a number stored in program memory and, depending on its value, called machine code, performs certain actions on the contents of the ALU registers. memory, ports, etc. For example, by reading the number 32H from the program memory. MK "understands" that you need to read the value from the input port number 2 and place it in the accumulator register. Often one byte is not enough to describe the action, and then the MK reads additional bytes from the memory. After performing the action, the MK reads the value from the next memory cell in order, etc. The set of bytes describing one action performed by the MK is called a machine command (instruction), and the set of such commands that the MK “understands”. - its command system or instruction set (Instruction Set). MKs of different families have different command systems, i.e., their machine codes have different meanings, although they perform similar actions. So, the program for MK is a sequence of numbers, the values of which indicate to it what actions to perform. The result of developing a program is a computer file containing these machine codes. With the help of a ROM programmer, it is entered (“sewn up”) into the MK program memory. How is the composition of this sequence of machine codes - a program for MK? Does the developer really need to remember the values of machine codes and manually set their sequence? The first programs for MK were created in this way. and it was called programming in machine codes. It is clear that this way of developing programs is very time consuming and inefficient. The first step in facilitating the process of creating programs was a computer program - the so-called translator from assembly language. The idea was to express the actions performed by the MK in a more human-readable language and then convert these expressions into machine codes. In the above example machine instruction that reads the value of port 2 and puts it in the accumulator, the action taken can be roughly denoted as MOV A.P2. Here the word MOV (from the English move), called the instruction mnemonic, denotes the transfer of a value, and A and P2, called operands, indicate where to get the value from and where to put it. This notation is called assembly language. program written on it. processed by a translator that converts assembly language constructs into machine codes. Assembly language programming is widespread to this day. Assembly language translators for all popular microcontroller families are free. Despite the obvious advantages of programming in assembler over programming in machine code, in many cases the assembler is not efficient enough to implement the developer's tasks. The fact is that the MK is able to perform only the simplest operations like arithmetic operations on integers, transfers, comparisons, etc. For more complex tasks, for example, operations on floating point numbers, developers had to write special routines that are inconvenient to use. and cumbersome. The next step in the development of programs for MK was the creation of special computer programs - translators from high-level programming languages, or compilers. The most widely used programming language is C. With the advent of translators, the development of programs for MK has been dramatically simplified. If, for example, you need to add two numbers in the program, then now it’s enough just to write a = b + c. and the translator converts this expression into the necessary sequence of machine instructions depending on the types of variables a, b and c. The use of a high-level language allows the developer to abstract from the command system of a particular microcontroller and operate in categories that are simpler and more understandable to a person. The developer is only required to know the general architecture of the microcontroller. principles of operation of embedded peripheral devices necessary for solving the task and programming skills in C language. The functional content of the program is implemented using the C language tools. which contains a large number of various subroutines (functions): arithmetic, for working with character strings, and many others. Consider the process of creating a program for MK in the C language. The development process will require a personal computer. After understanding the task, the developer writes the source code of his program in the C language using any text editor. It then runs the C translator program. which converts the source text into an intermediate object file. The translator is controlled by a set of keys (their description can be found in its documentation) that are specified on its command line. If the developer made syntactical errors while writing the program, the translator displays a list of them on the screen with an indication for each line number in the source text file. The developer must fix all bugs. After successful translation, the object files must be processed by the linker (linker), which generates the program file in machine codes. There is one problem when using a high-level language. The compiler is responsible for converting language constructs into machine codes, and this conversion can be performed with varying degrees of efficiency. The efficiency criteria are the size of the machine code (the smaller it is, of course, the better) and the speed of the machine code. The task of generating compact and fast code is very difficult, and the overall quality of the compiler depends on its solution. Modern C compilers use multi-level optimization, architecture features of a particular MK, allow you to create mixed programs in which some of the subroutines are written in assembler. The described process looks rather cumbersome: the developer must manually launch various programs (text editor, C compiler, linker to remember control keys, search for errors in the program by line numbers in the file. The latest step to date in facilitating the work of the developer of programs for MK has been the emergence of integrated environments development (Integrated Development Environment. IDE).Integrated development environment is a computer program that links together all the stages of program development.It combines a text editor for writing source code, translators from assembler and C, a linker, a debugger, reference information on MK and other tools necessary for the developer.Configuration of translators, linker and other components is performed not by specifying switches on the command line, but in the form of dialog boxes where you only need to check the boxes in the right places. . The emergence of integrated software development environments further increased the efficiency of creating programs for MC, allowed the developer to focus on the essence of the problem being solved and abstract from the specific details of its implementation. Integrated software development packages are produced by several companies. Packages from different manufacturers are similar in function, but differ in service capabilities, ease of use, and quality of generated machine code. The main characteristics of the most popular development kits are shown in the table.
SYMBOLIC DEBUGING OF PROGRAMS FOR MK With rare exceptions, programs for MK, due to the errors they contain, do not start working the first time and require debugging. Developers deal with debugging issues in different ways. Some of them believe that it is enough to carefully analyze the source text, see with an oscilloscope what is happening on the MK outputs, and all errors can be corrected. This method is applicable if the developer has extensive experience, knows the MK used perfectly and has a translator that always generates the correct code (usually an assembler), and sufficient time. Others use home-made debug monitors in their practice - sets of special subroutines that are loaded into the MK along with the main program. The latter calls the monitor subroutines at checkpoints, and they provide information about the state of the MK resources. Almost any program can be debugged this way, but it has drawbacks that can be significant. Firstly, the debug monitor must be provided with a part of the MC resources for work: at least a part of the address space of the code and a certain number of stack cells, and as a maximum, also a part of the RAM and peripheral devices of the MC. used by the monitor to display information. It can be difficult to allocate resources to the debug monitor if the main program itself is actively loading the MK. For example, the PIC 16С5х (Microchip) MK has only two stack cells, and it is difficult to use debug monitor subroutine calls. Secondly, monitor calls take time from the main program and, therefore, it cannot be called from time-critical parts of the program. Thirdly, creating a debug monitor, in itself, takes time. The most effective way to debug programs for MK is to use specialized professional debugging tools, which include simulator debuggers and in-circuit emulators. Before talking about the possibilities provided by such debuggers, it is necessary to touch on the choice of compiler, with the help of which the source texts of programs are converted into machine code. In the vast majority of cases, programming in a high-level language is preferable. The use of assembler is necessary if very strict requirements are imposed on the size and speed of the generated code. Currently, such cases are becoming less and less, since you can almost always take a "faster" MK with more memory. In addition, modern cross-tool packages make it easy to write mixed programs, where some of the modules are written in C. and the most performance-critical parts are in assembler. C compilers also allow assembly instructions to be inserted into source code. What are the advantages of programming in C compared to programming in assembler? Briefly, they are as follows:
In order to effectively debug programs written in a high-level language, the developer must have at his disposal debugging tools that provide adequate opportunities for displaying the data used in the program, as well as for tracking the execution of the program from its source code. Two conditions are necessary for this to be possible:
Now let's consider how the debugger should interpret symbolic information and what options should be provided to the user in connection with this. TRACKING THE EXECUTION OF THE PROGRAM ACCORDING TO ITS SOURCE TEXT In general, one line of source text is converted by the compiler into several machine instructions. Even an assembler program almost always contains macros that expand into several processor instructions when translated. It is inconvenient to debug such a program using the disassembler of its code, so compilers insert a table of line numbers into the debug information. It contains information about the correspondence of source text line numbers and source text file names to absolute addresses of the program code. The debugger displays the source code of the program on the screen. following this table, it can execute the program "line by line", executing in one step all the machine instructions generated by the compiler for the current line. The line number table also allows you to perform contextual actions with the program text, for example, execute it "to the cursor", i.e., to a user-specified place in the source text, set breakpoints on specified lines, etc. Contextual actions are convenient because the developer does not need to know the addresses corresponding to the lines of the source text: the debugger itself will determine them from the table. The debugger must also "know" the addresses of subroutines, functions, and code labels, and be able to find the source text of a function by its name. DISPLAYING DATA USED IN THE PROGRAM YOU DEBUG For full debugging, the developer needs to be able to view the data manipulated by the program at any time. The debugger must "be able" to display any data used by the program in the most appropriate way. As a rule, developers use named data in programs, that is, each object that is used in the program is given a name. Objects can be of varying complexity - from simple memory cells to complex structures of high-level languages such as structures, arrays, etc. DATA IN ASSEMBLY PROGRAMS Assembly programs use mostly simple data, i.e. memory cells. Arrays are also used. To correctly display simple data, the debugger needs to "know":
With the above information, the debugger should, after receiving the name of the object from the user, display its value according to the type. The most "advanced" debuggers can additionally display the rest of the object's attributes. DATA IN PROGRAMS IN HIGH-LEVEL LANGUAGES Displaying objects used in high-level languages is much more difficult due to the variety of object structures, ways in which they are stored in memory, and scopes. For examples, we will use the C language, as the most popular among developers. STRUCTURE OF OBJECTS In addition to simple variables of different lengths, C programs also use floating-point variables, structures (struct), unions or unions (union), pointers, one-dimensional and multidimensional arrays. The latter can consist of both simple objects and complex ones (structures, unions, pointers). Using complex objects in programs is certainly convenient. However, due to the complexity of their structure, it is highly desirable to be able to adequately display it at the debugging stage. In Fiton's debuggers, complex objects can be displayed both in a compressed (list of element values) and in expanded form, indicating the address, value and type of each array element and/or structure member. Implementation of pointers in different compilers is different. The fact that the MK usually has several address spaces creates additional difficulties, since when working with a pointer, in addition to the address, the address space where the pointer points to must be known. In some implementations, the address space identifier is part of the pointer value; in others, the compiler "knows" this in advance and generates the appropriate code. In addition, the address component in a pointer can be 8 to 32 bits in size. When displaying pointer values, the debugger must "know" all the details of their implementation in each compiler. METHODS OF LOCATION OF OBJECTS IN MEMORY In addition to static objects, the addresses of which do not change during the execution of the program, in a program written in a high-level language, there may be so-called automatic objects, memory for which is temporarily allocated in the MK stack. The addresses of such objects are not absolute, but are determined dynamically at the stage of program execution. They are usually measured from the current value of some static variable called the stack frame pointer (Base Pointer or BP). Since the value of BP is generated dynamically by the program at runtime, the values of automatic objects are only available within their scope, that is, with a valid BP value. The debugger, when displaying the values of automatic objects, must "know" the way addresses are determined, as well as monitor the correctness of the BP value It is also possible to temporarily place variables in MK registers. In this case, the debugger must "know" which variables are placed in which registers and for how long. And, finally, there is often a situation when the same object during its lifetime changes the way it is placed in memory, and more than once. This can happen, for example, when a function receives one or more parameters in registers and then pushes them onto the stack. OBJECT FIELD OF VISIBILITY As in assembler programs, C programs have global objects that are accessible by name from any module, and objects that are localized in the module (these objects are declared static). However, automatic and register variables make it more difficult for debuggers to display their values. The fact is that. firstly, the lifetime of an automatic object is limited by its scope, and secondly, enclosing scopes can have their own automatic objects with the same names. Let's illustrate this with an example of a function that has several nested scopes:
The variable named "a" exists as long as the function f is being executed, but depending on which part of the function is being executed, the name "a" stands for different variables. When tracing the function f, the debugger must, depending on which variable is active, correctly show its value. When creating a program, the developer does not care about the details of the implementation of the concepts that he used in the program. In terms of "for granted" categories, he often does not suspect how difficult it was for developers of compilers and debuggers to implement them. The latter have to solve the problem of combining in one shell at the same time a simple and intuitive interface, a wealth of functionality and a detailed study of everything related to the implementation of the architecture features and functioning of a particular MK. If the debugger does not provide the developer with debugging tools adequate to the complexity of the problem being solved, then the developer inevitably loses productivity. Who among us has not had to spend hours and days looking for an annoying error or typo in the source text?! In the process of developing and creating a microprocessor system, sooner or later there comes a moment when it is finally embodied in hardware and begins to show signs of life. However, in most cases these signs turn out to be unpredictable, the system begins to live its own life. Many programmers would probably agree that every new program contains bugs. This is partly why the new MK at first behaves like a "black" box. In order to facilitate the process of debugging systems, a whole class of tools has been developed. Their main purpose is to make the process of functioning of the debugged MK "transparent", i.e., easily controlled, arbitrarily controlled and modified at the will of the developer. A good professional toolkit can additionally provide the developer with many services, thereby greatly facilitating his work, eliminating routine operations. Major debugging tools include in-circuit emulators, software simulators, development boards (evaluation boards), debug monitors, and ROM emulators. There are also combined devices and sets. IN-CIRCUIT EMULATORS An in-circuit emulator (ICE) is a hardware-software tool that can replace an emulated processor in a real device. VSE is the most powerful and versatile debugging tool. Functionally, VEs are divided into those connected to an external computer (usually an IBM-compatible PC) and functioning autonomously. The latter have their own computing resources and input/output facilities, therefore, with equal capabilities, they are much more expensive than the former, and at the same price, they are significantly inferior to them in terms of functionality and service capabilities. With the system being debugged, the VSE is usually connected by a cable to a special emulation head. Relatively recently, VSE models have appeared in which such a head is structurally combined with the main unit and is inserted into the system being debugged instead of the MK. If the latter cannot be removed (the pins are soldered to the board), the use of the VSE is permissible, provided that this MC has a debug mode in which all its pins are in the third (high-impedance) state. In this case, to connect the VSE, a special clip adapter is used, which is connected directly to the outputs of the emulated MK. Least. VSE contains a debugger, a MK emulation node. emulation memory and breakpoint subsystem. More advanced TSEs may additionally include a tracer, a breakpoint processor, a profiler (program code efficiency analyzer), a real-time timer, software and hardware tools that allow you to read and modify the resources of the emulated processor "on the fly", software and hardware tools that provide synchronous management and necessary for emulation in multiprocessor systems, an integrated development environment. The debugger is a kind of bridge between the developer and the debugging tool. A good debugger ensures that the programs being debugged are loaded into the system memory, the statuses and contents of all registers and memory (and, if necessary, their modifications) are displayed on the monitor, and the emulation process is controlled. More powerful debuggers (commonly referred to as high-level or High-Level Debuggers) allow this as well.
Such a debugger allows the user to simultaneously control 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 a high-level debugger provides the performance of all its functions only if a cross-compiler is used that supplies complete and correct debugging information (not all compilers, especially their pirated versions, are capable of this), and at the same time the format of its presentation " familiar" to the debugger. Emulation memory is used in the debugging process instead of the ROM of the system being developed. Moreover, it allows you to debug the program in the absence of a real system or its layout. If you need to make changes to the program being debugged, it is enough to load a new or modified program into the emulator's memory, rather than reprogramming the ROM. There are VSE. which allow the user to "substitute" emulation memory instead of ROM not only in its entirety, but also block by block (in some models, the minimum block size is 1 byte). in the order specified by the user. To do this, it is enough for him to set the distribution of data memory and program memory, in accordance with 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 TSE. Such memory is usually called memory with the possibility of mapping. The tracer is a logic analyzer that works synchronously with the processor and captures the flow of instructions being executed and the state of selected external signals. There are VSEs that allow tracing not only external signals, but also the states of the internal resources of the MC. e.g. registers. In such devices, special versions of MK (emulation crystals) are used. The breakpoint processor makes it possible to stop program execution or perform other actions (for example, start or stop the tracer) when user-specified conditions are met, unlike the usual breakpoint mechanism, the processor allows you to form and track conditions of almost any complexity at the hardware level, while being emulated the process is not deduced from the real-time scale. In some VSE models, the breakpoint processor can optionally be used to dynamically control the tracer. The profiler (program code efficiency analyzer) allows, based on the results of running the debugged program, to obtain information about the number of calls to various sections of the program and the time spent on their execution. Analysis of the statistical information supplied by the profiler makes it possible to identify "dead" or overstressed sections of programs and, as a result, optimize the structure of the program being debugged. An integrated development environment is 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 provides simple and fast interaction with a software debugger-simulator and programmer. The presence of a built-in editor, project manager and control system in the VSE software shell greatly facilitates the work of the developer, saving him from a lot of routine actions. For him, the line between writing a program, editing it and debugging is blurred. The transition from source text editing to debugging and vice versa is carried out "transparently" and synchronously with the activation of the corresponding windows. The Project Manager automatically starts compilation as needed and activates the corresponding program interface window. You can just as easily proceed to debugging the project using the existing simulator debugger or start flashing the ROM with a debugged program. Some ITUs provide users with other additional features. Among them, one should especially 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 synchronous control (from one computer) of several emulators. In the general case, the ability of the TSE to control and manage the functioning of debugged devices can be limited (for example, incorrect interrupt handling in step mode, a ban on the use of a serial port, etc.). It is also necessary to remember that each VSE model has its own list of supported microcontrollers and compilers. However, for the majority of popular microcontrollers, VSEs have been developed that do not have restrictions on the use of resources of debugged crystals. We will illustrate the possibilities of such an ESS using the PICE-51 model of the Fiton company as an example. PICE-51 is a device created using a programmable logic IC (FPGA). This made it possible to drastically reduce the size of the VSE, minimize the deviations of its electrical and frequency characteristics from the characteristics of the emulated MC, and thereby achieve maximum emulation accuracy at frequencies up to 33 MHz at supply voltages from 3,3 to 5 V. emulation of almost all MKs of the MCS-51 family. Software support works in the Windows environment. PICE-51 consists of a main board, a replaceable adapter for a specific MK group and a replaceable emulation head also for a specific case type. A tracer and a breakpoint processor are assembled on the main board, and an emulating processor for a specific type of MK is installed on the replaceable adapter board. The emulation heads allow the device to be installed in DIP and PLCC sockets on the user board. Power is supplied from a block with an output voltage of +5 V (0,5 A) or from a device being debugged. Communication with a computer - via a galvanically isolated RS-232C channel at a speed of 115 kbaud. Other features and capabilities of the PICE-51 are as follows:
Such a wide range of functionality makes VSE the most powerful and versatile debugging tool. SIMULATORS Simulator - a software tool that can simulate the operation of the MK and its memory. Typically, it consists of a debugger, a CPU model, and memory. More advanced devices contain models of built-in peripheral devices (timers, ports, ADCs and interrupt systems). The simulator must "be able" to load program files in all popular formats, display information about the state of the resources of the simulated microcontroller as fully as possible. and also provide opportunities for simulating the execution of the loaded program in various modes. During debugging, the model runs the program, and the current state of the model is displayed on the computer monitor screen. By loading the program into the simulator. the user can 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 microcontroller. The simulator allows you to quickly check the logic of program execution, the correctness of arithmetic operations. Depending on the class of debugger used, some simulator models support high-level symbolic debugging of programs. The simulator may also contain a number of additional software tools, such as an external environment interface. The presence of such an interface allows you to create and flexibly use a model of the external environment of the MC. functioning and affecting the debugged program according to a given algorithm. In a real system, the MC is usually "engaged" in reading information from external devices (sensors) connected to it, processing it and issuing control signals to actuators. In order to simulate the operation of a sensor in a simple simulator, you need to 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 via a serial port, a certain flag is set, and the byte itself falls into a certain register, then both these actions must be performed manually in the simulator. In some models, this problem has been solved: simulators have built-in tools for creating models of external devices connected to the MK, including tools for graphical display of information. An obvious feature of software simulators is that that the programs loaded in them are executed in a time scale other than real time. However, the low price, the ability to debug even in the absence of a mock-up of the device being debugged, make software simulators a very attractive debugging tool. It should also be noted that there is a whole class of errors that can only be detected using a simulator. DEBUG MONITORS A debug monitor is a special program that is loaded into the memory of the system being debugged. It forces the MK to perform, in addition to the applied task, also debugging functions:
The monitor program works "in conjunction" with a computer or a passive terminal, on which the visualization and control of the debugging process take place. The advantage of this approach
DEVELOPMENT BOARDS Development boards, or, as they are usually called in foreign literature, evaluation boards (Evaluation Boards). - original constructors for prototyping of applied systems. Recently, many manufacturing firms, releasing new models of MK. offer and corresponding development boards. Usually this is a printed circuit board with an MK installed on it and all the elements necessary for its normal operation, as well as communication systems with a computer. As a rule, the board provides free space for mounting the user device being developed. Sometimes there is also a ready-made "wiring" for installing additional devices recommended by the company (ROM, RAM, LCD display, keyboard, ADC, etc.). Boards modified by the user can be advantageously used as single-board controllers built into small-scale products (5...20 pcs.). For the convenience of the user, development boards are also equipped with a simple debugging tool based on the debug monitor. Two different approaches have emerged here: one is used for MK. having an external bus, and the second - for MKs that do not have it. In the first case, the debug monitor is supplied as a ROM chip. which is installed in a special socket on the development board. The board also has RAM for user programs and a communication channel with a computer or terminal. An example is the development board developed by Intel for the MK MCS-51 family. In the second case, the development board contains built-in programming systems for the internal ROM of the MK. which are controlled by a computer. The monitor program is entered into the ROM of the MK along with the application prepared accordingly (calls of the monitor debugging routines are inserted in the right places). Then a test run is carried out. To make corrections to the program being debugged, it is erased from the ROM and the corrected one is written into it. The finished application program is obtained from the debugged one by removing the monitor and all calls to its functions. Development boards for MKs of the PIC-micro (Microchip), 80C750 (Philips), 89C2051 (Atmel) families are designed for such a debugging algorithm. Development boards are sometimes 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 (for example, a debugger-simulator) or various elements that are inherent only in integrated development environments in their pure form. The kits may also include applied programs that are most often encountered in practice. The debugging capabilities of the "development board plus monitor" kit are not as universal as those of the ESS. in addition, some of the MC resources in the process of debugging are selected for the monitor to work. Nevertheless, the availability of a complete set of ready-made software and hardware tools that allow you to start installing and debugging the applied system without loss of time is in many cases a decisive factor. Especially when you consider that such a kit costs several times less than a more versatile emulator. ROM EMULATORS A ROM emulator is a software and hardware tool that allows you to replace the ROM of the device being debugged with RAM. into which you can download the program from your computer via one of the standard communication channels. It allows the user to avoid multiple cycles of flashing the ROM. The ROM emulator is used only for debugging MK programs that are able to access external program memory. In terms of complexity and cost, this device is comparable to development boards. It has one big advantage - versatility. The ROM emulator can work with any MK. The first ROM emulators only allowed a program to be loaded, run, and stopped using a master reset. Then there were complicated models with hardware generation of trace signals to the oscilloscope upon reaching a certain address. The emulated memory in such products was available for viewing and modification, but control over the internal control registers of the MK was until recently impossible. Recently, so-called intelligent ROM emulators have appeared. They allow you to 'look' inside the MC on the user's board and are similar in debugging control to the VSE. Cactus even presents its actually intelligent ROM emulator as the VSE of the MK series, it is so impossible to distinguish between working with one and the other. In fact, the processor in this case does not is replaced, and the one on the user's fee is used. The smart ROM emulator is a hybrid of the normal ROM emulator. a debug monitor and a system for quickly switching the bus from one to another. This creates the effect as if the debug monitor was installed on the user's board, and at the same time it practically does not take up hardware resources from the MK, except for a small (about 4 KB) zone of software steps. Such an emulator was developed, for example, by the Fiton company for all existing and future MKs that have the 8051 core, but are additionally saturated with various input / output devices. The product supports many different MCs from Philips, Siemens. OKI. INTEGRATED DEVELOPMENT ENVIRONMENTS Strictly speaking, integrated development environments are not among the debugging tools, however, it would be wrong to ignore this class of software tools that greatly facilitate and speed up the process of developing and debugging microprocessor systems. With the traditional approach, the initial stage of writing a program is constructed as follows. The source text is typed using a text editor. Upon completion of typing, work with the text editor stops and the cross compiler starts. As a rule, a new program contains syntax errors, and the compiler reports them to the operator console. Then the text editor is started again, and the operator looks for and eliminates the identified errors. At the same time, messages about their nature, displayed by the compiler, are no longer visible, since the screen is occupied by a text editor. This cycle may repeat more than once. And if the program is relatively complex, is assembled from various parts, is subject to editing or modernization, then even this initial stage may require a lot of effort and time of the programmer. To avoid a large amount of routine work and thereby significantly increase the productivity of a programmer, the so-called integrated development environments (shells) of development (Integrated Development Environment IDE) that have appeared and are rapidly gaining popularity allow. As a rule, a good integrated environment combines the available debugging tools (in-circuit emulator, software simulator, programmer) and provides the programmer with "Turbo" style program texts. The integrated environment allows:
Recently, the functions of integrated development environments have become part of the programming interfaces of the most "advanced" emulators and debuggers-simulators. Such functionality, combined with a friendly interface, significantly speeds up the programmer's work. Thus, when choosing debugging tools, it is advisable to take into account the following set of indicators: the list of supported microcontrollers, restrictions on the resources of emulated / simulated microcontrollers, the possibility of symbolic debugging, the list of supported compilers, and, finally, service capabilities. Authors: Yu.Zobnin, Sh.Kobakhidze, Moscow
Machine for thinning flowers in gardens
02.05.2024 Advanced Infrared Microscope
02.05.2024 Air trap for insects
01.05.2024
▪ Alternative to silicon for microcircuits ▪ Why do dinosaurs have a long neck ▪ Integral four-channel ULF Toshiba TCB701FNG
▪ section of the site Reference materials. Article selection ▪ article And who knows what he blinks. Popular expression ▪ What animal are the Canary Islands named after? Detailed answer ▪ article by Ungerniy Viktor. Legends, cultivation, methods of application ▪ stepper motor controller. Encyclopedia of radio electronics and electrical engineering
Home page | Library | Articles | Website map | Site Reviews
www.diagram.com.ua |
See other articles Section 
Latest news of science and technology, new electronics:
All languages of this page