|
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 Modular programming of control systems on MCS48. Encyclopedia of radio electronics and electrical engineering
Encyclopedia of radio electronics and electrical engineering / Microcontrollers It is known that the same microcontroller can control both complex technological equipment and a household coffee grinder or electronic clock. Adaptation to a specific object is carried out by changing the microcontroller program, the hardware is almost not affected. The proposed article is devoted to programming techniques for MCS48 series microcontrollers, which are widely used in control systems for various purposes. Its main provisions are also valid for more modern devices. The development and modernization of control programs is greatly facilitated if they are built according to a modular principle. In this case, after gaining some experience, and most importantly, our own library of debugged modules, programming a new control system (CS) comes down to replacing some modules of an already existing and debugged program and, possibly, supplementing it with fragments that take into account the specifics of a particular system. This principle is embedded in the structure of many high-level languages (PASCAL, C++), and the programmer is literally forced to follow it. Unfortunately, ASSEMBLERS (including for MSS48), while giving the programmer greater freedom of choice of means and methods for solving problems, as a rule, do not monitor the observance of programming discipline at all. This often leads to the creation of programs so confusing that even their authors cannot figure out what was done after some time, not to mention the use of debugged fragments in other programs. Conscious adherence to common modular concepts greatly facilitates and speeds up the programming of microcontrollers. An example of a typical modular program for CS is given in the table. Its syntax corresponds to the TASM tabular ASSEMBLY for the 8048 microprocessor. As you can see, at the beginning of the program text, the EQU directives give names to the constants and assign values. Using named constants is always preferable to specifying numeric values directly in executable processor instructions. For example, the time delay implemented by one of the subroutines discussed below is defined by three numbers. They are given by the constants N1, N2 and N3. If you need to change the shutter speed, it is enough to specify new values in the EQU operators. Otherwise, one would have to look throughout the program for instructions with operands equal to these numbers, decide whether each of them refers to a time delay, and indicate new values \uXNUMXb\uXNUMXbin necessary cases. Obviously, such work requires a lot of time and often does not do without errors. It is especially complicated by the fact that some commands may not use the whole number, but, for example, its high or low byte. ASSEMBER already at the stage of translation of the program is able to calculate some constants based on the values of others. This possibility is illustrated by the calculation of the high (N3N) and low (N3L) bytes of the number NXNUMX. Next, the program allocates memory for variables. They do this with the same EQU directives, but unlike the descriptions of constants, they specify not the numerical values of the variables, but the addresses of the memory cells they occupy.
If the ASSEMBLER permits, the possibility of using macros should not be neglected. Each of them is, as it were, a new instruction that performs an operation not directly provided for by the processor's instruction system. Describing a macro instruction, the programmer gives it a name (which, of course, does not coincide with the name of any of the "real" instructions) and specifies the required actions in the form of a Sequence of machine instructions. Each time it encounters a macro instruction in a program, the ASSEMBLER will replace it with the specified sequence. In this example, two macros are used. One of them transfers the contents of the accumulator to the data memory cell specified by the macro parameter, and the other - back. After the power is turned on (or a reset signal is given), the microcontroller starts executing the program from address zero. This address is usually used to write an unconditional jump command to the actual program start point (in this case, the START label). This is necessary because hardware interrupts always transfer control to fixed addresses 3 and 7 (for other types of microcontrollers, the addresses may be different, but they are still located at the beginning of the program memory). The commands of unconditional transition to the service routines of the corresponding interrupts located at these addresses are to be "bypassed" by the main program. The next step is setting the controller operating modes (for example, selecting memory banks and registers), initializing variables and external devices. A typical mistake of novice programmers is to assume that immediately after starting the program, the variables already have some definite values. This misconception is reinforced by the fact that some high-level languages (such as BASIC) automatically set all variables to an initial value of zero. In programs in assembly language (and many other languages), the programmer himself must take care that before the first reading of the value of a variable, something has already been written to the memory cell allocated to it. Good programming style requires that initial values be assigned to variables at the very beginning of the program. In this case, this is done by the 1INIT subroutine. The external device initialization section usually looks like an alternate call to subroutines, each of which resets one of them (analog-to-digital converter, LED indicator, keypad, etc.) and can be easily replaced when finalizing and improving the system. Often, these same routines check the health of devices. Next, most control programs enter an endlessly repeating main loop, the execution of which is suspended only to handle interrupts. The cycle consists of subroutines for polling the keyboard and other sensors, checking the flags set by the interrupt handling subroutines (for example, the flag for the expiration of a specified time interval or the end of the analog-to-digital converter), processing the information received in accordance with the specified control algorithm, outputting control actions to actuators , displaying information about the state of the technological process on a liquid crystal display or other indicators. The exit from the main loop is usually provided only in emergency situations, for example, if to eliminate the consequences of a failure, it is necessary to repeat the initialization of all variables and external devices, as well as when processing interrupts. Thus, a program built on a modular basis is a set of subroutines. If, for example, a different keyboard is used in the new control system, it will be enough to replace the BUTT subroutine. In order for such a replacement to be simple and painless, certain rules should be developed and always observed. Subroutines, if possible, should save the contents of all controller registers, receive initial data and issue results in the same registers and memory cells, use the same character encoding, etc. It is necessary to fight against the natural (especially for programmers who have overcome the first difficulties and begin to feel like professionals) desire to simplify the program by moving away from strict rules and using non-standard techniques. Seemingly, at first glance, unjustified complication will fully pay off by facilitating debugging and reworking the program as a whole. Let's consider some features of subroutines. I NCREM and DESREM perform the required in many cases, the operation of increasing or decreasing by a given value of a 16-bit binary number (its high and low bytes are respectively in registers R6 and R5). The constants that specify the amount of increment are described at the beginning of the program. Since any microcontroller works much faster than technological equipment, it is very important to be able to organize time delay in the program. In this case, the processor's internal counter/timer is used. It has limited capacity and overflows in milliseconds. Each overflow generates an interrupt request. The timer interrupt service routine (TIME) counts them and, when the specified number is reached, sets the FLT timeout flag to one. All subroutines whose work depends on time, it remains to analyze the state of this flag. So it is possible to realize shutter speeds of several seconds and even minutes. In order to start counting a new interval, it is necessary to enter the initial values in the working cells of the TIME subroutine and turn on the timer. Subroutine SET2M, for example, sets the time delay to 2 minutes. The calculation of initial values has several subtleties. It is known that in microcontrollers of the MSS48 series, the pulses arrive at the input of the internal counter/timer at a frequency that is 480 times lower than the frequency of the quartz oscillator. For example, with a quartz resonator frequency of 7 MHz, the number written to the counter changes every 480/7000000 = 0,00006857 s = 68,57 µs. So the counter will overflow (and generate an interrupt request) in 68,57 -(256-N1) µs, where N1 is the number originally written to the counter. If every time you start a new count from this number, then N0,1 = 2 0,1/[7000000 (1480-N256)] overflows will occur in 1 s (minimum time delay). Obviously, the same time delay can be obtained with different N1 and N2, but since these numbers cannot be fractional, it will be implemented with some error. The task is to select such a pair of values for which the error is minimal. In the case under consideration, the best option is N1 = 13, N2 = 6. A time delay of 2 min is obtained by repeating the described procedure N3 = 1200 times. It is often necessary to use different procedures for processing the same hardware interrupts in different modes of program operation. One way to do this is illustrated by the INTER subroutine. It analyzes the interrupt type code entered by the main program in the INTT cell and, depending on its value, calls one of the interrupt service routines ISR1 or ISR2. Note that both of them end with RET, not RETR. It is easy to increase the number of processing options and even make it so that for a certain value of the code, several different subroutines will be called one after another. It is not necessary to write all the necessary subroutines in the text file of the main program. Modules debugged and repeatedly used in different programs can be located in separate files and connected to the main program using the INCLUDE directives. Each include file can contain one or more routines. The disadvantage of this method is that the names of variables, constants and labels in all used modules should not be repeated. Deprived of this defect, the method of separate translation of modules with their subsequent merging at the level of the object code, unfortunately, is not supported by the TASM ASSEMBLY. Author: D. Ryzhov, Vladimir
Machine for thinning flowers in gardens
02.05.2024 Advanced Infrared Microscope
02.05.2024 Air trap for insects
01.05.2024
▪ Eleven more moons of Jupiter ▪ The smell of the patient makes doctors wrong ▪ Lenovo Legion R7000P and R9000P gaming laptops
▪ section of the site House, household plots, hobbies. Article selection ▪ article Who led the Trojans in their fighting against the Achaeans? Detailed answer ▪ article Investigation and registration of accidents and occupational diseases. Insurance. Directory ▪ article TVZ in the lamp UMZCH. 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