Zhelezyachniki vs. Programmers

Hello!

I am one of the founders of the open project Embox , and part-time I am the CEO of Embox LLC. As it is not difficult to guess, its main goal is to provide commercial services based on our project.

Actually, the blog is a kind of my gift to the project. The reason for this was the appearance of the fifth user, ready to pay for our services. As a result, it seemed to me that there could be other companies with problems that can be solved with the help of our project.
')
This article is the first in our blog, and it seems to me that it would be appropriate to tell not so much about the technical solutions and findings that we apply in our project, this will certainly be in subsequent articles, but to make a kind of greeting article. And since Embox is an operating system for embedded solutions, the article will focus primarily on the sphere of embedded systems. In fact, in the article I want to share my view on the possible direction of development of embedded software, of course, I will support all this with real situations that we encountered in the process of working on a project. Therefore, those who are interested in embedded systems and who are not too lazy to read a couple of pages of complaints about a difficult childhood reasoning, please under the cat.

As I have already noted, our field of activity mainly concerns embedded systems, but, as you know, this concept hides a very large class of systems. I would even say that everything that is not desktop, server or mobile systems, in one way or another can be attributed to the built-in. Perhaps this is what led to the emergence of two large, pronounced clans. On the one hand - people who came from the side of iron, ironworks. They work on controllers, count every byte and processor clock. On the other hand, there are programmers who came from the world of Linux, with its huge functionality, but at the same time with high costs for memory and processor. Both those and others have their own arguments why it is their approach that is correct. In my opinion, these arguments are well described in an article from Black Swift . Since their board is OpenWRT, they identified the benefits of the Linux world, namely:

And the result is not Arduino, which doesn’t know about anything, not ESP8266, which, for all its cheapness, is unlikely to allow you to create a web interface with PHP, sockets, women and gambling - but a device with functionality that fully complies with modern understanding. smart things. "

To the shortcomings in this article, they rightly attributed the lack of qualities that the iron workers are proud of:

Yes, Black Swift has limitations - there is no work in hard real time, there is no hardware PWM, there is no ADC.

And in the comments such phrase slips:

Via sysfs, the minimum quantum is 3 ms, direct work with registers is 100 nsec.

That is, it turns out that to change the state of one pin from the user mode it takes 3 ms, and this is despite the fact that it is done much faster and more predictably on the same mentioned arduino, despite the much lower performance.

Here, iron workers usually state that there is nothing more to talk about, that programmers have thought out all sorts of unnecessary whistles for themselves, but forgot about the main function of the device. This ends the conversation, and I certainly understand them. But after some time, they still come to the programmers with the words: “We would have to screw our console with a shell to our device, well, another file system, preferably a network one, and tcl, I’m used to it.” This is an excerpt from a real conversation, though the hardware program was not programmed on controllers, but on FPGAs, but this does not change the essence of the matter.

Yes, in general, zhelezyachniki never questioned the benefits of the rich functionality of the device. The question is what you have to pay for.
Just imagine: you have a device whose main purpose is to control the engine of a valve. To tie the web interface to it, you need to install Linux on it, as a result of which the response time of the main function of your device will drop to 3 ms. And then you involuntarily think, and do you really need this web interface?

But today's realities are such that everyone understands: even simple devices must be networked, convenient to use, and therefore must be multifunctional, and using arduino, let's say, it is difficult to achieve this.

We, for example, encountered this when creating a device for controlling LEDs . In addition to the standard modbus protocol for such devices, the customer wanted him to have a convenient and understandable web interface, through which an ordinary operator could manually control the ports and configure the device.

I will give one more illustrative example from one company independently producing equipment for automation. We provided support for the program part. There is a small laboratory of automation in the city of Novokuznetsk, they have conceived to make a control card CNC machine. Everything suited them, the algorithm worked quickly, and the machine smoothly. But in order to be different from amateur counterparts, they decided to add convenient controls to their devices: screw the web interface and so on. Actually, with the web interface, through which it was necessary to download programs for the machine, calibrate, configure, diagnose, and most importantly, transmit the status over the network at the time of the machine operation, they turned to us. After all, they themselves are not programmers, and such functionality, no matter how simple it may seem, requires some effort, and it was easier for us, as programmers, to do it. Of course, the main thing is that the main functionality should not be affected, the machine should work just as smoothly. And here our OS is different in a positive way from Linux: after all, our applications can run in the same context as the kernel, so you can write directly to the registers, without additional overhead.

Someone might say that these costs for Linux are a fee for versatility and security. But we are not developing a device for all occasions, but a specialized device with a previously known functionality, and to give at least a potential opportunity for the operator to put a headscarf so as not to get bored while the machine is running the program, is somehow not very good. And as a result, posts appear “What is an IT specialist to do in the army ...“ . No, I certainly admire the intelligence and ingenuity of our military IT specialists, as a result, sometimes we get a useful result , but still it is rather an exception.

In addition, certification is often required in the field of specialized systems. For example, one of the customers chose us because his device had to be tested by the FSB for undeclared capabilities. That is, if there is a program code in the final firmware image, then the conditions for its calling and functionality should be described and checked for compliance with the requirements of the certification committee. The first thing that comes to mind is to create software without an operating system, but then it turns out that the functionality is needed, and quite rich: a web interface, a file system, remote access based on ssh, firewall, and so on. We once faced this dilemma too, then we tried to prepare the Linux kernel for certification with a minimal set of user tools. The task, I want to tell you, is not pleasant. As a result, for Embox, we came up with a language for describing modules, which allows us to build static models of the system and on the basis of them to generate a distributive suitable for certification. This distribution contains only the necessary source, make- and header files.
This approach allowed us to solve another problem, which is typical for the field of embedded systems. Namely, the use of those same controllers with a small amount of resources on board and the lack of virtual memory. If you think that such systems are no longer needed, because the Raspberry Pi is not much more expensive, then you are mistaken. First, not much, but still more expensive. Secondly, do not forget about power consumption, because quite often you need power from a battery / battery, or PoE (power over ethernet). Well, reliability, which is also greatly appreciated for such devices. After all, I hope there is no need to explain that several soldered chips (processor, memory, ...) are a less reliable design than a single chip containing both a processor, and memory, and peripherals.

Moreover, if earlier the main mass of controllers were eight-bit mega - and pics, and it was difficult to deploy rich functionality in the form of web servers, a file system on an SD card, etc., now powerful mobile ARM controllers are available Cortex M3 / 4 Series. The latter generally contain dsp commands, a floating point, and can operate at frequencies close to 200 MHz. In general, there is where to build a complete multi-functional system. It was on one of these controllers, the STM32F407, containing 1 MB flash and 192 kB, we made the mentioned controllers for LEDs, and on our advice in the automation laboratory they make a CNC machine and other devices for which properties on one side are important on the other hand, the benefits of programmers.

Due to memory limitations, it is still impossible to install Linux on these mobile ARM controllers, unless, of course, external chips are used. Therefore, the most common OS is FreeRTOS. This is certainly a good OS RV, but it is a follower, albeit more functional, of various iron projects. That is, the developers of this project were repelled by iron values, the so-called “libOS” approach, when the system is developed, essentially, from scratch, naturally using the OS itself as the base library. As I said, this approach has its advantages: the developer fully controls the entire system. But at the same time, this approach is difficult to fit into the idea of ​​reusing the code. This is already a rather serious drawback, because the transfer of some POSIX-compatible software, say sshd or httpd, is very laborious, since such operating systems use their own API to save money.

The idea of ​​running Linux / POSIX on platforms with limited resources has been known for quite some time, one of these projects was ucLinux. His main idea was to launch applications written for Linux on a hardware platform without MMU. As far as I know, now the project's developments have joined the main Linux, and as a result, Linux can be configured as a NOMMU system. But the problem of the monolithic kernel remains, that is, even if you disable all unused drivers, all system calls will be present in the kernel, and, therefore, all subsystems, even if in a minimal amount. Therefore, in the memory limits that I brought (192kB), Linux again does not fit, and you need to install external memory. The minimal computer running Linux is Picotux , it contains 8 MB of RAM. In fact, I found a mention of running Linux on a board with an x86 processor and only 2.5 MB of RAM , but even after such a feat, external memory is still needed.

Another, in my opinion, promising project is eCos . At one time it was very popular in the field of embedded systems. Its main idea lies in the title of the project, eCos: embedded configurable operating system. This system had a fairly decent compatibility with POSIX, so it could to some extent use a wide range of Linux applications, and at the same time it could run on platforms with hundreds of kilobytes of memory. Why she did not win the entire podium and did not become the de facto standard for embedded systems, I do not quite understand. Perhaps because supporting multithreading, eCos could have only one process , and in Linux they very often use processes. Perhaps it was not possible to agree with the manufacturers of controllers. Perhaps, as I have heard several times from manufacturers of equipment, there was not enough support for the project. In general, I do not know, but I see that, on the one hand, this project is being supplanted by FreeRTOS, and on the other hand, by Linux.

But at the same time, it seems to me that the ideas of eCos, together with ideas from ucLinux, can make a difference in the field of embedded systems in the near future. After all, as I have already noted, controllers (systems on a chip) have now appeared, allowing to build effective multifunctional systems. The only obstacle, in my opinion, is the strong difference in approaches adopted in the worlds of hardware and programmers, and the reluctance to understand each other.

Summarizing my reasoning, I will give several characteristic features in the field of embedded software today:

• Limited resources - Today, as before, there are significantly less resources in the field of embedded systems than in desktop ones. This is due not so much to the cost of resources, which has greatly decreased in recent times, but rather to reliability, power consumption, and other regional requirements.
• Specific hardware platforms - Closely intertwined with the previous item statement. Here I want to note that systems not only use a different architecture than x86, but also use processors without hardware support for virtual memory.
• Unique software - Often embedded software is designed without using the OS at all or using an OS that has its own API that is not compatible with other platforms.
• High requirements for functionality - Recently, the requirements for embedded devices are increasing, at a minimum, they must be networked, have a convenient and familiar interface, which leads to the use of Linux, Android and other full-featured universal operating systems.

The first points are characteristic for the previous stages of development of the industry, but the last one became widespread relatively recently (5–10 years) and is gaining more and more popularity, but this contradicts traditional requirements and often results in architectural solutions such as using different hardware in one system: one works in real time, for example, on a FPGA or controller without an OS, and another one is responsible for the general purpose and works on a full-fledged Linux and some “big” ARM. This not only reduces reliability and increases the cost of the device, but also requires the involvement of both hardware developers and programmers in the development, which, of course, increases development time.

We, in the Embox project, treat programmers, and, like normal programmers, we seemed insignificant (easily solved) problems of iron ore workers, but constantly faced with these problems, we had to reconsider, albeit slightly, our views, and attempts to solve them to the emergence of our project. As an advertisement, I will even quote from the automation laboratory about our project:

The fact that Embox is something we dreamed about for a long time is a fact ...

Therefore, we believe that our project can help solve similar problems for other users.

PS For those who follow the project, I inform you that we have released version 0.3.9 .
PPS We switched to github . This, according to many project participants, will facilitate the connection of new contributors. So we are waiting for an influx of those wishing to plunge into the mystical world of OSDev! :)