Microcontrollers (the old beautiful name - single-crystal micro-computers) currently have an incredibly many applications. From industrial automation to household appliances, from control of nuclear stations to children's toys, from secret military systems to channel switching in your radio. In short, it is easier to list where they do not apply.

The invention and further development of microcontrollers produced a real revolution in digital electronics. Not only the circuitry and the element base have changed, but also the very principles of building systems. Significant changes undergone a development cycle. There were whole classes of devices, the existence of which would be impossible without controllers.

But every technology, no matter how good it is, always has a downside. These include imperceptible at first sight difficulties; the challenges posed by the new approach; restrictions that have to be considered. New opportunities offered by technology may find the most unexpected applications, and not always directed towards good.
')
This article is intended to provide an overview of both positive and negative aspects of the widespread use of microcontrollers.

Bright side

Simplification of circuitry

If we compare the circuitry of devices on rigid logic and on controllers, then the latter is much simpler. During development, it is only necessary to determine which functional blocks the device will consist of, which interfaces to combine them with, and which element base to select. Instead of mapping the future of the device from individual parts, block design is now applied. The microcontroller allows you to create a complete block on one crystal, or even several.

The implementation of all algorithms of work is now the task of the controller program, and writing the program is much less laborious than the synthesis of the digital circuit. As the complexity of tasks grows, this advantage becomes more pronounced. The growing size of the software code is compensated by its structuredness, as well as the introduction of additional levels of abstraction. Embedded operating systems and standard libraries are widely used, which makes it possible to separate the code that works with hardware and the code that defines the behavior and algorithms.

Unification

Separation of software and hardware allowed to unify the element base. The same controller can be used to create many different devices. Unification leads to lower production costs. It is economically advantageous to produce several dozen types of controllers instead of hundreds of varieties of logic circuits (and thousands of specialized ones).

Several devices of different functionality may have the same scheme, and differ only in the program. The most striking example is industrial PLC (programmable logic controllers). They are assembled from standard modules: input devices, output devices, computing and interface modules. For the interaction of the modules with each other and the algorithms of the system as a whole, the program part is responsible. Thus, any necessary system can be built from a small set of standard blocks.

Easy to make changes

In order to change the algorithm of the scheme operation on rigid logic, it is necessary to connect its elements in a different order, remove some of them, or add new ones. Often this can be done only during the prototyping process, and when the device is ready, the only way to make changes is to release a new version.

The microcontroller in this regard gives much more flexibility. To make changes to the algorithm of the device, just download the new firmware. Most modern electronics support flashing in terms of a service center, and often even by the user. Nowadays, you can easily upgrade your phone, printer or camera software. In the near future, you can do the same, say, with a washing machine or a coffee maker. As more devices gain access to the network, it is logical to expect the auto-update mechanism to spread, just like the one used today for computer programs.

Dark side

If the positive aspects of the ubiquitous use of microcontrollers are obvious and do not require detailed consideration, then the problems associated with it are hidden deeper and unnoticeable at first glance.

Reduced reliability

The theory of reliability includes many different aspects, but in the "everyday" sense, when they talk about the reliability of technology, they usually mean resistance to failures and failures. Failure is a fatal malfunction, as an example you can bring a light bulb. Failure is a violation that resolves on its own, or with minimal operator exposure. An old TV that is “repaired” with a fist kick is an example of a malfunctioning system.

The more a system consists of a larger number of elements, the more likely the occurrence of a failure. In this respect, the integrated circuit of the controller, containing millions of transistors, at first glance loses to rigid logic, where only a few hundred transistors per chip. However, the level of reliability in microelectronics today is quite high. All suspicious crystals are discarded at the production stage. The weaker places are printed circuit boards, interconnecting chips and passive elements. Thus, in terms of the frequency of failures caused by internal causes, microcontroller circuits even benefit.

They lose on failure resistance. Failures, as a rule, are caused by external influences: temperature, electromagnetic interference, radiation. Controllers are especially sensitive to electromagnetic effects, which cause lags and spontaneous reboots. To ensure the immunity of microcontroller circuits, special measures are required: power bus separation, watchdog timers, additional layers of metallization on the board, etc. For details, see [1] .

Often the source of failures becomes poorly debugged firmware. Or the reason for unreliable work lies at the junction of software and hardware. For example, multiple entries in the same flash cell sooner or later lead to the exhaustion of the cell resource, and the data begins to be damaged. The microcontroller can provide the level of reliability required for most tasks, but only with a competent approach to design. By the way, this is worth mentioning separately.

The apparent ease of development

Before you develop electronics, you need to accumulate a significant amount of knowledge. Digital devices circuitry is a rather lengthy institute course. Plus, it is desirable to know electrical engineering, the basics of analog circuitry and discrete mathematics. In short, the entry threshold for developing electronic circuits is quite high.

The input threshold for programming is much lower. You can learn the basics of any language in one evening and learn how to write “Hello world” s. It is clear that there is a huge gap between the “programmer” and the “good programmer”, but the ease with which you can start writing is captivating.

Likewise, the entry threshold for device development on controllers is low. Now there are a lot of excellent Arduino-like kits, a huge selection of peripheral modules for them, it remains to spend that evening on the development of IDE (development environment) - and you can start your first project.

So why is a good embedded programmer a comparative rarity? The fact is that besides the ability to write code, he must know all the features of his architecture. He needs to be aware of how digital devices work, understand how to encode signals, and know how the device behaves in any non-standard conditions. A programmer working with controllers is much closer to the hardware than an application programmer. Accordingly, without knowledge of the principles of the work of this iron he can not do.

It turns out that the ease of development for controllers is just an illusion. The microcontroller is much more sensitive to programmer errors than the "big" computers. The limited amount of memory, speed requirements "in tact" and the almost complete absence of "fool protection" require highly skilled developers.

Functional congestion and uncomfortable interfaces

- What does the perfect interface look like? One button labeled Do It Good.
- No, no buttons, just the inscription "You are already well."

Joke with some truth.

To solve a problem, the microcontroller is always selected with a margin in parameters. Accordingly, part of the controller's resources (sometimes up to 90%) remains free. This leads to the fact that you can add a few additional functions practically “for free” by adding a couple of dozen lines in the firmware code. And this opportunity is often abused. As a result, the KISS principle is violated, declaring the simplicity of the system one of the main priorities in design. It turns out the device, most of the capabilities of which are never used, and the user does not even know about half of them.

The presence of unnecessary functions - only the tip of the iceberg. It would seem that it is not used - well, maybe it will come in handy someday ... But the functional complexity leads to the complexity of user interfaces. There may be two ways. You can try to "squeeze" the management of all functions in a limited set of I / O elements. So there are menus with N-15 nesting levels, or buttons with dozens of alternative actions. As an example of a twilight engineering genius in this direction, you can bring the phone-AON "Rus". Whoever had this unit knows that its setting is similar to programming in machine codes.

The second way is to make the interface user-friendly by applying a large color screen (preferably a touch screen) or adding a button for each function. This option is better, but the dimensions increase, the battery life decreases, the reliability of the device decreases. And do not forget about the price. Even if the production costs increase slightly, the presence of a “super-duper screen with 5000000 colors” allows you to wind +50 ... 250% of the final cost of the device without any remorse.

Undocumented features

In a large shopping complex, for no reason at all, the smoke exhaust windows (large electric windows) open and give a fault to the control relay. It promised rain at night; if we do not fix it, it will flood the complex.
I call from the company a specialist who programmed this relyuhi. He is alone in the city, an infection, he solders everything and sets it up. Described the problem; he answered, they say, everything is clear, now I will come and do it.
He arrives, walks confidently to the relay, removes her fee, pokes at the adapter. Opens some editor - all in hexadecimal code, do not understand the damn thing. What, I think, he will do? I observe how the random movement of the mouse in the lower right corner - brought, canal, looked at the date, opened the converter, translated some numbers into hex, searched for them in the code and replaced them with others. “Che, I ask, did the timer work?”

IThappens.ru

After analyzing the scheme of the device on rigid logic, you can recover the entire algorithm of its work. Doing the same thing with a microcontroller device is an order of magnitude more difficult. First of all, you need to remove the firmware, which is far from always possible, modern controllers have good protection. The resulting file must then be disassembled, deobfuscated, and only then analyze.

What is the probability that in addition to the basic functions, there are no additional features in the firmware? This may be sending statistics to the manufacturer, a deliberately made mistake, a data interception module, a backdoor - anything. Moreover, the "bookmark" is not necessary to add during development, you can make changes to the firmware of any existing device. An example is the StuxNet worm, which injected its code into the PLCs of nuclear processing plants [2] . If you do not enrich uranium, this does not mean that you are not in danger. Already developed mechanisms of attack on printers [3] and routers [4] , using a change of firmware. Considering the ease with which most devices are reflashed, in the near future we should expect the emergence of new "software and hardware" viruses and types of attacks.

Are you sure that right now your microwave is not watching you? :)

Conclusion

In the course of reading this article, especially the second part of it, you may get the impression that I urge you to abandon the wide use of controllers. This is by no means the case. First, technical progress cannot be reversed. Secondly, for many tasks, controllers are the only alternative, and there is nothing to replace them with. And finally, thirdly, the described negative aspects in no way outweigh the merits of the microcontroller.

The main conclusion that I would like to make - and it is suitable for any technology - you need to skillfully use the advantages that this technology gives, but do not forget about their downside. Thank you for your attention, and may the Force be with you!

Literature

[1] - G. Goryunov. "Why some microcontrollers are more reliable than others."
[2] - "How Symantec Hacked Stuxnet." Habrahabr
[3] - "Tens of millions of HP LaserJet printers are vulnerable." Hacker.
[4] - “Trojan in a router: infection of D-link 500T at home”. Hacker №7 / 10