Experience one engineering investigation

The topic of this post was formed almost by chance, in the process of easy discussion about approaches to the development of software, in particular, and devices on the MC in general. Those interested can familiarize themselves with the discussion itself habrahabr.ru/company/coolrf/blog/222801 . Although both sides clearly remained unconvinced, nonetheless a certain challenge was thrown. I am not afraid of challenges, any challenge is good by itself, because answering it, you change something and, as a rule, for the better (a variant like “a little to drink 10 liters of beer at a time”, which obviously changes a person NOT for the better, at my age no longer rolls). So we begin.

There is some development of a dimmer (lighting control device), which should receive control signals from some device over a wireless channel, specifically ZigBee (hereinafter referred to as ZIG). And in the process of designing this device, it turned out that the main program for actually providing dimming cannot coexist on the same MC with the library of the organization of the protocol stack of the wireless interface. I must honestly admit (and I did it in the comments) that at the time of the discussion I had only a general idea of ​​the SIG (this is not quite true at the moment), but my previous engineering experience categorically objected to the fundamental possibility of the existence of such an insoluble conflict .

Let's make some assumptions about the possible nature of the conflict. First, general considerations: how can you change the degree of illumination (up to complete shutdown) of the incandescent lamp or other lighting device? For this, a lower voltage should be applied to the lamp than the one for which it is designed. The variant with static voltage drop on the damping element (linear regulation) will not be considered due to the considerable power that is given off on this element. All that remains is dynamic control (pulse modulation), that is, the use of a key element, and a decrease in the average value of the voltage on the lamp due to the fact that the key element is closed some of the time. If we were dealing with a constant voltage, then the method of regulating this would have been exhausted, the options are possible: pulse-width or frequency-pulse modulation. However, since we are dealing with alternating voltage, we can apply cyclic transmission / blocking of voltage or blocking within one cycle (period) of the input voltage (which is a variant of frequency-pulse modulation). This option has an undoubted advantage over pulse modulation in that the switching of the state of the regulating element can be carried out at the moment of voltage transition through zero, that is, in the case of a resistive load at zero current, which significantly reduces switching losses. Since the cycle restriction has a significant drawback in the form of flicker, the variant with partial voltage cut-off within the cycle (usually half the period) is more often used. The cut-off can be implemented both at the beginning of the cycle (power-on delay) and at the end (advanced shutdown). Since the first version is easily implemented on the triac (the shutdown takes place automatically when going through 0), we will accept it as a working one.

Sketch up the pseudo-code for a simple implementation of the cycle-wise dimming algorithm with a turn-on delay:
')

while (1) { _; timer=_; while (timer) { if ~signal() { timer++}; timer--;}; //     0 timer=_; while (timer) { timer--}; //    ; _ ; ;  ; timer=_; while (timer && ) { timer--}; //      }; 

With this implementation, the second and third lines (and the fourth) of the main cycle are critical sections, since the observance of their execution time determines the positioning accuracy of the trigger pulse relative to the beginning of the cycle, therefore, we control these times by disabling interrupts. That is, we have quite a long time intervals during which interruptions are prohibited, and we will not be able to communicate with peripheral devices, including the SIG. What are the possible problems here? It is completely possible (I’ll emphasize once again that I am not familiar with the specifics of the ZIG at the time of writing this post) that some exchange operations on the radio interface require strict restrictions on time parameters. A candidate for such operations can be all sorts of "handshakes" (confirmation of the operation). And indeed, a cursory acquaintance with the description of the library shows that there is a call requirement of 65 microseconds. Since we have prohibited interruptions for a longer time, we cannot fulfill this requirement, which leads to a collision. Before we start looking for ways to solve the problem, you need to find out if it really exists.

Suppose that we really can not provide the required processing of the ZIG. So what? The standard was developed by intelligent people (always consider the interlocutor no more stupid than yourself, until he proves you otherwise, and even in this case, you may be mistaken), who know perfectly well what is ether in the 2.4 GHz range, and I will never believe that this standard does not provide for measures to re-transmit and correct failures, including by time parameters. Therefore, what threatens us with the omission of a message about changing the parameters of the lamp glow? The fact that we will take it in the next cycle, when interrupts are resolved, or in the next, and so on. That is, the delay in changing the glow of the lamp can be (I am generous) up to 10 work cycles, that is, 10 * 1/50/2 = 1/10 seconds. I do not really understand how such a delay can be marked by the user.

Now suppose that the library we use (from ATMEL, by the way) is made by Krivoruk programmers (although this contradicts my principles, but what you will not do as a mental experiment), and it really drops if you don’t call it within 65 µs after the arrival of the message. That is, we cannot guarantee the duration of execution of lines 1 and 2 when receiving control information from the ZIG. So what? That is, when we receive information about the need to change the luminosity of the lamp, we may incorrectly issue the next control cycle (we can shorten the glow period until it is completely turned off). If the information is transmitted only when it needs to be changed, then again I cannot imagine a user who will notice a change in the luminosity of the lamp caused by such a rare failure.

Now suppose that everything is really bad, that is, information falls to us quite often and we are obliged to process it as soon as possible after reception, that is, the execution time of our pseudocode becomes completely unpredictable (in the direction of increasing duration). The situation is really unpleasant, and we have no choice but to abandon the simple and understandable implementation. What can we do without putting additional MK (sarcasm) nearby. Well, to begin with, remember about the existence of such things as interrupts, timers, and PWM modulators associated with the timer (there is an abundance of all this in this MK). I propose the following solution: we determine the cycle duration and set one of the timers for the corresponding duration in the autoload mode or in the one-time mode (by a time slightly shorter than the cycle time). Configure the PWM mode and use the output signal to control the triac. We synchronize the timer with the cycle voltage. We set a signal to go through 0 to an interrupt and set a timer correction routine for it (for autoloading) or restarting the timer (for one-time). Since this handler is obviously uncomplicated and short-lived (long operations to calculate the true time of arrival of an interrupt (do not forget about the capture mode), calculations of the average and so on can be assigned to the lower half of the handler), we meet the requirements for starting the library. In general, everyone is happy, everyone laughs.

Nevertheless, I would seriously think about the future use of a library that places such stringent requirements for the development of shared software. The only thing that comes to mind: after all, such restrictions were not incorporated into the library by the developers, but were the result of the not quite correct interpretation of its description by those programmers who used it. I would rate the ratio of the probabilities of the first and second options as 2 to 8, especially if we take into account the mention in the description of the MC of the extended mode of operation of the equipment, which “reduces the requirements for allowable delays”. But here we come to the shaky ground of guesswork and assumptions, although I was interested in the subject of SIG, and I am thinking about learning it more deeply with writing the corresponding library. True, despite the statements of some participants in the discussion, such a library (for the case of a simple device, this is a ZIG term) in the source code from ATMEL is freely available.

Probably, such a solution has disadvantages that are not obvious to me, since they were not implemented by the developers of the company, whose post gave rise to the discussion. I would be glad to get acquainted with them, since this will undoubtedly broaden my horizons as a developer of embedded devices.