|
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 We design devices on microcontrollers. Encyclopedia of radio electronics and electrical engineering
Encyclopedia of radio electronics and electrical engineering / Microcontrollers Between the initial idea of creating a device based on a microcontroller (MC) and the development of its program, there is an important stage - drawing up a block diagram of the algorithm. It is often forgotten or worse, neglected. Programming is carried out "heuristically", in essence - by trial and error. The result is a cumbersome program that somehow works, is not fully understood even by its creator, and is difficult to modernize. However, quite simple methods have long been known and used by programmers, which allow, starting with the verbal formulation of the algorithm, to correctly design its block diagram. The professional interests of the author of the article lie in the field of developments on the MK of the Z8 series, but the material presented by him equally applies to MKs of other types. The interaction of any MC system with the operator and the control object can be represented as shown in Fig. 1 scheme [1]. In the general case, the control object is equipped with actuators and sensors. The human operator acts on the MC with the help of master devices and receives information about the state of the object from the readings of the display devices. The former are switches, buttons, variable resistors, the latter are light (including graphic and alphanumeric) indicators, sound-emitting and other signaling devices.
All the functional nodes and connections shown in the diagram are required only in complex interactive control and management systems. In the so-called open-loop control systems, the MC operates "blindly", without receiving any information about the state of the object. Sometimes he does not even give the operator any information about the work (both his own and the object), especially if it is possible to evaluate the results of control by observing the object itself. In closed control systems, the MC corrects the control actions on the object depending on the readings of the sensors, but display devices are not required here either. Control systems do not contain actuators, and with the help of setting devices, the operator only selects controlled parameters or switches the operating modes of indicators. The methodology for designing systems on MC [2, 3] includes the formulation and analysis of the problem, its engineering interpretation, the development of a flowchart of the algorithm and the text of the application program. In such systems, they tend to assign the maximum number of functions to software tools. The required amount of memory, speed and reliability of the system in the circuit ultimately depend on the effectiveness of their implementation. Of course, the development of the concept and the design of the product itself is still to be done, but we will touch on them only to the extent necessary for the development of the MK program. The problem statement is a verbal formulation of the requirements for the system being designed. First of all, they describe its purpose, characteristics of the control object, sensors, indicators, actuating and setting devices. Next, you should talk in detail about the desired behavior of the system in all possible situations, including "abnormal" ones. In no case can you rely on the error-free actions of the operator. For example, having heard an emergency signal, he may well press the START button instead of the prescribed "STOP" button or randomly press all the buttons in a row. Of course, it is impossible to foresee all such situations, but this must be strived for. Be sure to specify the numerical values of the parameters of the system being designed. First, the task is formulated, as a rule, "at the user level". For example, the initial task for the development of a fan control system may sound like this: "Turn the fan on and off, adjust the intensity of the air flow and change its direction (exhaust / discharge)". Engineering analysis will reduce this task to controlling the speed and direction of rotation of the fan drive - a DC motor. Since the power of the output signals of the MK is obviously insufficient for direct control of the engine, a special driver device will have to be installed between them, which generates signals of the required power, and the task is solved by the MK. limited to the supply of control actions to the driver. We will not dwell on the choice of power controls, sensors and devices for their interface with the MC. Today, specialized microcircuits are produced for these purposes, which are much more efficient to use than building a system from discrete components. Assume that the integrated DC motor driver LMD18200 from National Semiconductor will be used. A typical circuit for its inclusion is shown in fig. 2. It contains a bridge of high-power MOSFETs, in the diagonal of which the motor is connected.
The driver is controlled by three logical signals. Rectangular pulses are fed to the PWM (Pulse Width Modulation) input, the ratio of the duration of which to the repetition period (duty cycle) determines the engine speed. The logic level of the signal at the input DIR (direction - direction) sets the polarity of the voltage supplied to the motor, therefore, the direction of its rotation. By setting the log level. 1 at the BR input (brake), the engine is stopped, and if at that time the PWM input has a log. 0, the motor power circuit will simply be open, otherwise the motor outputs will also be connected to each other, which will provide emergency braking. Two sensors are built into the driver. One of them generates a current flowing from the CUR (current - current) pin and is proportional to the motor current with a factor of 377 µA/A. Temperature sensor output TF (Thermal Flag - temperature flag) - discrete open collector. It goes into the log state. 0. if the driver crystal is heated above 145 °C. Let us formulate the requirements for the fan motor control device, and in essence, the motor driver. The control device must be equipped with buttons, by pressing which the operator (user) can turn the engine on and off, change direction, increase and decrease its speed. There should be an indication of the direction of rotation of the engine with light signals of different colors and an audible alarm about an accident (overheating or overload). After applying the supply voltage, the device must, without turning on the motor, wait for a command that sets the direction of rotation. Its receipt should be confirmed by a light signal. On the "START" command, the motor must be turned on and begin to rotate in the specified direction with an average frequency (duty cycle of the PWM signal = 0.5). According to the commands "SLOWER" and "FASTER", the duty cycle must decrease or increase accordingly, without going beyond 0.2 ... 1. The "STOP" command must immediately stop the engine, after which it can be restarted by issuing the "START" command. If the permissible value of the consumed current is exceeded, which may be the result, for example, of a mechanical jamming of the motor shaft, the latter must be turned off and an intermittent sound signal with a frequency of 1000 Hz in the form of short bursts (duration of them and pauses between them is 1 s). When the microcircuit overheats, it is necessary to stop the engine and give a sound signal with long bursts (the duration of bursts and pauses is 2 s). The audible alarm must remain on until then. until the operator issues a "STOP" command, which returns the device to its original state. Until such a command is given, it shall not respond to any others. Already at this stage, one should abstract from details that are not essential for the development of the MC program. For example, in this case, it doesn't matter. that the control object (motor) serves as a fan drive, the type of ventilation (exhaust or supply) depends on the direction of its rotation, and the intensity of the air flow depends on the frequency. Moreover, when developing an algorithm, you can generally forget about the motor and its driver, focusing on the formation of PWM control signals. DIR, BR and signal processing of CUR and TE sensors. Analyzing the formulated task, it is desirable to immediately identify some problems that will inevitably manifest themselves in the next stages. For example, should the system respond to a "Run" command if the direction of rotation is not predefined? If yes. in which direction should the motor rotate in such a case? Should the set frequency and direction of rotation be maintained after stopping and restarting the motor? What about after the emergency? All such questions must be answered as soon as possible. Based on the verbal description, lists of input and output signals of the MC are compiled. The first of them includes commands given by the operator, and sensor signals: "EXHAUST". "PUSHING". "START". "FASTER". "SLOWER". "STOP". "OVERLOAD" (CUR). "OVERHEAT" (TF). In the second, control signals for the engine driver and indicators: PWM - rotational speed. DIR - direction of rotation, BR - turn off the engine. G - turn on the green LED. Y - turn on the yellow LED. S - sound. In view of the foregoing, it can be concluded that what is required by MC. having at least 14 pins for connecting external circuits (eight inputs and six outputs). Since the CUR signal is analog, you will need a comparator to compare the sensor readings with an acceptable value and generate the logical signal "OVERLOAD". Therefore, MK is preferred. equipped with a built-in comparator. Suitable, for example, is the minimum 18-pin modification of the Z86 series MK. The cheapest option is a microchip. Z86E02. That's all for now. regarding the hardware of the device. The distribution of input and output signals over the outputs of the MK at this stage is not significant. Further, it is recommended to depict the verbally given algorithm in the form of a so-called finite automaton graph. A discrete device is considered a finite state machine if it is possible to enumerate all states in which it can be, all events (external influences) that lead to state changes, and all generated output signals. These are the devices based on the MK. An example of an automaton graph is shown in fig. 3.
The states are represented by the nodes (vertices) of the graph. In this case, there are four of them: A. B. C and D. The vertices are connected by arcs equipped with arrows showing the direction of the transition, the event Xi that causes this transition is indicated above the arc, and below it is the set Yi of output signals generated by the automaton at this moment and unchanged until the next transition. Theoretically, exactly so many arcs should come out of each vertex of the graph. as many different external influences on the automaton as possible. If some event does not change the state of the automaton, the corresponding arc is shown entering the same vertex from which it left. However, in order not to clutter up the drawing, in practice only those of such arcs are left. which are associated with changes in the output signals. For example, from the graph shown in Fig. 3. you can delete the arcs A-A and B-B. In ordinary language, this means that the automaton in states A and B does not respond to the X3 event. Events affecting the automaton implemented as a MK program. are not only "direct", caused by changes in the logic levels of the signals applied to the external outputs of the MK, but also "indirect". The latter include, for example, a certain result of comparing the calculated and given values of a certain parameter or the completion of some lengthy operation. The line between direct and indirect events is sometimes difficult to draw. For example, such a common event as the operation of the timer built into the MK can be considered indirect if it is fixed. analyzing the number in the corresponding register, or direct, reacting to the signal generated by the timer at the end of the count. The output signals can also be indirect, not directly changing the logic levels at the outputs of the MK. Often, when transitions between states of an automaton, certain values are only assigned to program variables. Returning to the problem being solved, let's build a graph of the engine control automaton. Analyzing the task, the following states can be distinguished:
The constructed graph is shown in fig. four.
It is easy to see that it is impossible to change a randomly set wrong direction of rotation without turning on and then turning off the engine. In addition, to start it, you always need to give two commands - direction and start. By refusing the START command, the STOP2 state can be excluded. and direct the arcs of the "PRESSURE" and "EXHAUST" commands directly to the WORK state. As a result, there will be one button less on the control panel, one MK input will be released. and the engine will turn on immediately after pressing any of the buttons that set the direction. Strictly speaking, for any change in the specified control algorithm, the consent of the customer or the future user of the device must be obtained. But in amateur practice, the customer, performer and user are often one person and it is enough to "consult with oneself." It is striking that the graph does not reflect the way the variable duty cycle PWM signal is generated. In the general case, this can be done by a special device controlled from the MK. But we strive to implement everything purely programmatically, so we will have to split the WORK state into two. In the first of them (WORK) PWM=0, in the second one (WORK 1) - PWM = 1. Now let's provide events that cause transitions between them - alternate firing of two timers, one of which sets the duration of the PWM pulses, and the second sets the pauses between them, and each timer, having worked, starts the other. Due to the fact that in this case the "logical" timers never work simultaneously, they can be implemented using one "physical" timer, programmatically changing its time delay after each operation. The "FASTER" and "SLOWER" commands adjust the time delays of the timers, leaving their sum unchanged and equal to the specified PWM pulse repetition period. The automaton can respond to these commands in both considered states. However, to simplify the algorithm, it is permissible to restrict the reaction to only one of them. Due to the short duration of these states, the execution delay will remain imperceptible to the operator. Another necessary clarification is checking the admissibility of time delay values. According to the job, the duty cycle of the PWM signal. equal to T1/(T1+T0). where T1 and T0 are the time delays of the timers, it must always remain in the interval 0,2 ... 1. Therefore, after each command to change the speed, the machine must go to the CHECK state and only from it return to the WORK state along one of the two arcs. The first one corresponds to a positive result of the check; when you go through it, new shutter speeds are set. The second - the result is negative, the excerpts that were in effect before remain unchanged. Continuing to analyze the graph, we pay attention that the OVERHEAT and OVERLOAD states differ only in the repetition period of the sound signal. It's a good idea to combine them into one, calling it ACCIDENT. The audio signal S can be generated using two timers, similar to the PWM signal discussed above. Moreover, it is desirable to use the same "physical" timer, which in this state remains idle. To make the sound intermittent, you can use another timer, but it's easier to do without it, counting the periods of the generated signal using a counter implemented in software, turning the output signal on and off after a certain number of them. All this will require to provide for additional states of the automaton and transitions between them. The developed graph of the automatic control of the engine is shown in fig. 5.
Please note that the verbal formulations of the actions to be performed are replaced by assigning certain values to variables. For example, instead of the phrase "turn on the yellow LED", Y = 1 is indicated and it is specified that the green LED should be turned off, G = 0. In addition to the previously mentioned output signals and timer delays, the constant T is the PWM pulse repetition period and the variable N is the number of pulses S remaining until the end of the formed interval of the sound signal. The next step is to transform the graph into a block diagram of the MC operation algorithm. First of all, all graph vertices (automaton states) should be numbered. The order of numbering is very important in the hardware implementation of the automaton. By choosing it correctly, you can significantly simplify the device. For software implementation, this is not so significant, and in most cases the numbering can be arbitrary. The program necessarily provides for the so-called "state variable", which in the course of work is assigned values equal to the numbers of the current states. In complex programs, there may be several such variables. Many programming languages allow you to give numeric values symbolic names. This can be widely used, as a line in a program that assigns the value RABOTA to a variable is much more descriptive than a line that assigns the value 6, for example. On fig. 6 a typical block diagram of the control algorithm is presented in the most general form. After initialization, the program runs cyclically. After parsing the state variable, it executes the corresponding procedure in each cycle. A change in the state of the automaton is indicated by assigning a new value to the state variable, as a result, another procedure will be performed in the next cycle.
The procedures that implement each of the states of the automaton are built according to block diagrams similar to those shown in Fig. 7. First of all, external influences (events) are analyzed. Next, the process is divided into as many branches as there are arcs coming out of the corresponding vertex of the automaton graph, each of them provides for the execution of the functions necessary to implement this transition, and finally, the state variable is assigned a value equal to the number of the vertex to which the arc is directed. Another approach is also possible: first, the arcs entering the vertex are implemented, and then they react to the impacts. Its main drawback is that the program must "know" from which state the automaton passed into the given state, which was not required in the previous case.
Please note that in fig. Figure 7 shows two possible exits from the state procedure. In the first one, events are analyzed cyclically until one of them is found that causes an exit from this state. In the second - if none of these influences is present. the procedure ends as shown by the dashed line. If there are few external influences and the reaction to them in each state is specific, the event detection procedures are included in the state processing blocks. For example, it is possible to check whether the "START" button is pressed only in the state in which the machine should respond to it. Often, the event filtering procedure is placed in the main loop (in Fig. 6 it is shown by a dashed line) and a variable is provided, which is assigned a value that is uniquely associated with the event that occurred. For example, the result of polling the keyboard is the code of the pressed key. In the state processing block, performed according to the second of the above options, only analyze the value of this variable. In contrast to the theoretical model, real events often occur simultaneously. In such a situation, the automaton must first of all react to the event that has the highest priority. The easiest way to prioritize is to choose the right sequence for analyzing events. For example, according to the block diagram shown in Fig. 7, event X1 has the highest priority. the lowest - at HZ. If high-priority events occur much more often than low-priority events, the queue may never reach the last ones. To avoid this, rare events should be given the highest priority. Sometimes the distribution of the latter has to be changed while the program is running, for example, by placing each newly processed event at the end of the queue. The unpredictable behavior of the system on the MK is often due to noise or bounce of the contacts of the controls. Such false events must be "screened out" using software filters. Most often, to recognize an event as having taken place, it is enough to make sure that the logical level of the signal at the corresponding input of the MK remained unchanged for a certain time. In critical cases, more complex procedures are used. Among the many events, it is often possible to single out "emergency", the reaction to which should be immediate. A typical example. In order not to miss the moment when the timer expires, the program has to constantly check the state of its register, not being able to do anything else until the expiration of the timer. The interrupt request signal generated by the timer at the end of the count solves the problem. By accepting it. The MC immediately (at least much faster than during normal software processing of the same event) proceeds to the execution of the interrupt service routine, the address (vector) of which must be specified in specially allocated program memory cells. The apparatus of priority vector interrupts of the program being executed is provided in the vast majority of microcontrollers. Interrupts can be either external or internal. In the latter case, the interrupt request input does not have an external output, but is connected to a request source located directly on the MK chip. Usually, internal interrupts are provided not only from the timer, but also from other devices built into this MK: serial port controllers, analog signal comparators, analog-to-digital converters. Often one of the internal interrupts of modern MKs is associated with the so-called watchdog timer (Watch Dog), which serves to protect against accidental failures. This timer requires constant initialization by writing a specific code to a specific location in the address space. The MC program is built in such a way that during its normal course, such a procedure is performed quite often. If the MK "hangs", the initialization of the watchdog timer stops and after a while it submits its interrupt request, the processing of which is designed to restore the normal operation of the system. Typically, the response to a watchdog interrupt is the same. as an external signal that sets the MK to its original state. Interrupts are controlled by enabling or disabling them depending on the state of the implemented automaton. If the same interrupt in different states needs to be processed differently, the processing procedure is built like the main program loop, providing for state analysis in it. The difference is. that such a procedure is not closed in a ring. Having completed it, the MK will continue to execute the program from the place where it was interrupted. This is fraught with failures, since in a state that has changed as a result of interrupt handling, continuing interrupted actions may give an incorrect result. They protect themselves from such errors by disabling interrupts during the execution of critical sections of the program move, which. undoubtedly slows down the reaction of the system. If there are more interrupt request sources in the system than the MC inputs provided for them, a group request is implemented in hardware by combining the outputs of several sources according to the OR scheme. By accepting such a request. The MC is obliged to find out who sent it and process it accordingly. The entire algorithm of the device is sometimes implemented by a set of interrupt handling routines. In this case, the main loop degenerates into several machine instructions, up to a single unconditional jump instruction to itself. Many MKs specifically provide HALT or IDLE commands for which they. essentially stop working (sometimes even the clock generator turns off). Only the received interrupt request can bring the MK out of this state. Finished processing the request. The MC performs the unconditional transition to the stop command provided in the main loop and "falls asleep" again. This mode is very economical, since the power consumed by the stopped MK decreases many times, increasing only during the reaction to external influences. The block diagram of the fan motor control algorithm developed taking into account the above consists of two parts shown in Fig. 8 (main loop) and fig. 9 (handling the interrupt from the timer). Both of them basically correspond to the typical block diagrams discussed above, except that the same operations are combined that are performed when processing different events. The timer interrupt handler generates PWM and S signals. Upon transition from the STOP state to the RUN state, the interrupt is enabled, and when returning to the STOP state, it is disabled.
The program now has a state variable ST, which is assigned string values for clarity - the names of the corresponding states. As mentioned above, in the program these will be numbers - state numbers or their symbolic names. The values assigned to the variable N0 are chosen based on the assumption that the repetition periods of the generated pulses PWR and S are the same and equal to 1 ms. If it's not. the block diagram will have to be slightly modified.
Now you can proceed to the choice of MK, the distribution of input and output signals on its outputs and the development of a complete circuit diagram of the device. Having determined to which external circuits the bits of a particular I / O port of the MK will be connected, and the logical levels of the signals in these circuits, the programmer can begin to develop the program. Literature
Author: M. Gladshtein, Rybinsk
Machine for thinning flowers in gardens
02.05.2024 Advanced Infrared Microscope
02.05.2024 Air trap for insects
01.05.2024
▪ Found a planet where it rains from precious stones ▪ Notebook Eurocom M4 with screen 13,3" 3200x1800 ▪ High Voltage MOSFETs for High Speed Switching Devices
▪ section of the site Audio Art. Article selection ▪ article Jomini da Jomini, but not a word about vodka. Popular expression ▪ article How did ancient astronomers imagine the universe? Detailed answer ▪ article Snake knot. Tourist tips ▪ article Glue for gluing rubber to metal and wood. Simple recipes and tips ▪ article Quality multiplier. 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