Microcontrollers (the old beautiful name is single-crystal micro-computers) currently have incredibly many applications. From industrial automation to household appliances, from managing nuclear stations to children's toys, from secret military systems to switching channels in your radio. In a word, it’s easier to list where they are not applied.

The invention and further development of microcontrollers has revolutionized digital electronics. Not only the circuitry and the element base have changed, but also the very principles of building systems. The development cycle has undergone significant changes. Entire classes of devices have appeared, the existence of which would have been impossible without controllers.

But any technology, however good it may be, always has a downside. These include difficulties that are imperceptible at first glance; problems generated by the new approach; limitations to be reckoned with. New opportunities that technology provides can find the most unexpected applications, and not always aimed at the benefit.

This article aims to provide an overview of both the positive and negative aspects of the widespread use of microcontrollers.

Bright side

Simplification of circuitry

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

The implementation of all work algorithms is now the task of the controller program, and writing a program is much less time-consuming than synthesizing a digital circuit. With the increasing complexity of tasks, this advantage becomes more apparent. The growing size of the program code is offset by its structured nature, as well as the introduction of additional levels of abstraction. Embedded OS and standard libraries are widely used, which makes it possible to separate the code that works with the 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 feasible to produce several dozen types of controllers instead of hundreds of varieties of logic circuits (and thousands of specialized ones).

Several devices with different functionality can have the same circuit, but differ only in the program. The most striking examples are industrial PLCs (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 software part is responsible. Thus, from a small set of building blocks, you can build any necessary system.

Easy to make changes

In order to change the algorithm of operation of the scheme 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 provides much more flexibility. To make changes to the algorithm of the device, just download the new firmware. Most modern electronics support flashing in a service center, and often even by the user. Nowadays, you can easily update the software of your phone, printer, or camera. In the near future, you can do the same, say, with a washing machine or coffee maker. As more devices get access to the network, it’s logical to expect the spread of the auto-update mechanism, similar to what is used today for computer programs.

Dark side

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

Decrease in reliability

Reliability theory includes many different aspects, but in the “everyday” sense, when they talk about the reliability of technology, they usually mean resistance to failures and malfunctions. Failure is a fatal malfunction, as an example, a blown bulb. Failure is a violation that is resolved on its own, or with minimal operator exposure. An old TV that is being repaired by a fist is an example of a malfunctioning system.

The more elements a system consists of, the more likely the occurrence of a failure of any of them. In this regard, the controller integrated circuit, containing millions of transistors, at first glance loses to hard logic, where there are only a few hundred transistors per chip. However, the level of reliability in microelectronics today is quite high. All suspicious crystals were rejected at the production stage. The weaknesses are printed circuit boards, interconnecting microchips and passive elements. Thus, in the failure rate caused by internal causes, microcontroller circuits even win.

They lose in failure tolerance. Failures, as a rule, are caused by external influences: temperature, electromagnetic interference, radiation. The controllers are especially sensitive to electromagnetic influences, which cause freezes and spontaneous reboots. To ensure the noise immunity of microcontroller circuits, special measures are required: separation of power buses, watchdog timers, additional metallization layers on the board, etc. See details in [1] .

Often a badly debugged firmware becomes the source of failures. Or the reason for the unreliable work lies at the junction of the software and hardware. For example, writing to the same flash memory multiple times sooner or later leads to the exhaustion of the cell's resource, and the data begins to get corrupted. The microcontroller can provide the level of reliability needed for most tasks, but only with a competent approach to design. By the way, this is worth mentioning separately.

Apparent ease of development

Before you engage in the development of electronics, you need to accumulate a significant amount of knowledge. The circuitry of digital devices is a rather voluminous institute course. Plus, it is desirable to know electrical engineering, the basics of analog circuitry and discrete mathematics. In short, the entry threshold for the development of electronic circuits is high enough.

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

Likewise, the entry threshold for developing devices on controllers is low. Now it is full 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 goodEmbedded Programmer - Relative Rare? The fact is that in addition to directly the ability to write code, he must know all the features of his architecture. He needs to imagine how digital devices work, to understand signal coding, to know how the device will behave in any non-standard conditions. The programmer working with controllers is much closer to the hardware than the application programmer. Accordingly, he can not do without knowledge of the principles of operation of this iron.

It turns out that the ease of development for controllers is just an illusion. A microcontroller is much more sensitive to programmer errors than "large" computers. The limited amount of memory, the requirements for speed “by clock” and the almost complete absence of “foolproof” require highly skilled developers.

Functional congestion and inconvenient interfaces

- What does the perfect interface look like? One button that says "Do me good."
- No, no buttons, just the inscription "You are already fine."

A joke with some truth.

To solve a particular problem, the microcontroller is always selected with a margin of parameters. Accordingly, part of the controller’s resources (sometimes up to 90%) remains free. This leads to the fact that you can add several additional functions almost "free", 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 design priorities. It turns out the device, most of the capabilities of which are never used, and about half of them the user does not even know.

Having unnecessary functions is just the tip of the iceberg. It would seem that it is not used - and okay, it might someday come in handy ... But the functional complexity leads to the complexity of user interfaces. There are two possible ways. You can try to “squeeze” the control of all functions into a limited set of input-output elements. So there are menus with N-eleven levels of nesting, or buttons with dozens of alternative actions. As an example of twilight engineering genius in this direction, you can bring the phone-caller ID "Rus." Whoever had this unit knows that its setup 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 your own button for each function. This option is already better, but the dimensions are increasing, the battery life is reduced, the reliability of the device is reduced. And do not forget about the price. Even if production costs increase slightly, the presence of a “super-duper screen with 5,000,000 colors” allows you to wind up +50 ... 250% of the final cost of the device without undue remorse.

Undocumented Functions

In a large shopping mall, for no reason, smoke exhaust transoms open (large electric windows) and issue a malfunction to the control relay. At night they promised rain; do not fix it - it will flood a half of the complex.
I am calling a specialist from the company who has programmed this relay. He is alone in the city, an infection, he solders and puts everything. Described a problem; he answered, they say, everything is clear, now I’ll come and do it.
Arrives, with a confident gait, goes to the relay, removes the board from it, pokes into the adapter. Some kind of editor opens - everything is in hexadecimal code, not a damn thing to understand. What, I think, will he do? I observe a random movement of the mouse in the lower right corner - I brought it in, Kanalya, looked at the date, opened the converter, translated some numbers into hex, searched for them in the code and replaced them with others. “What,” I ask, “did the timer work?”

IThappens.ru

After analyzing the scheme of the device on rigid logic, you can restore the entire algorithm of its operation. It is much more difficult to do the same with a microcontroller device. First of all, you need to remove the firmware, which is not always possible, modern controllers have good protection. The resulting file must then be disassembled, deobfuscated, and only then analyzed.

What is the likelihood that in addition to the main functions, there are no additional features in the firmware? This can be sending statistics to the manufacturer, an intentionally made mistake, a data interception module, 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 introduced its code into the PLCs of nuclear enrichment plants [2] . If you do not enrich uranium, this does not mean that you are not in danger. Already developed attack mechanisms on printers [3] and routers [4]using firmware change. Given the ease with which most devices are flashed, in the near future we should expect the emergence of new "software and hardware" viruses and varieties of attacks.

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

Conclusion

During the reading of this article, especially the second part, it may seem that I urge to abandon the widespread use of controllers. This is by no means the case. Firstly, technological 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 advantages of the microcontroller.

The main conclusion that I would like to draw — and it is suitable for any technology — is to skillfully use the advantages that this technology provides, but not to forget about their flip side. Thank you for your attention, and may the Force be with you!

Literature

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