The diverse world of embedded systems and the place of Embox in it

The Embox project has already turned 9 years old, but many do not understand what it is and why it is eaten, why it is needed. Some of those who have heard about the project and know that this is an operating system, believe that Embox is a “native OS”. Indeed, Embox was conceived as an attempt to make “its own” OS with “blackjack and boats”, but the main thing is “blackjack and boats”. That is, some characteristics or their combination, which were lacking in other projects, were put at the forefront.

Of course, no one was going to write a universal OS even with some chips. The Embox slogan - “Essential toolbox for embedded development” - implies that the project is aimed at embedded systems. However, this concept is very broad, it includes: the Internet of Things (IoT) and robots, various raspberries (RaPi) and onboard systems, arduinks and ACS-TP, .... The list, as you understand, can be continued for a very long time, there are places in it where Linux lives beautifully, and there are places where Linux is redundant and various small RTOS are used. In this article I would like to talk about the embedded-world in all its diversity, and of the place of Embox in it.

Single Board Computers

Industrial computers

Let's start with single-board computers. Many of them are made in industrial design. Most are built on processors with ARM and x86 architectures. Many people think that x86-processors are not used in this segment, and everything is limited to raspberries , bigbleboards , bananas and so on. But long before RaPi, there were other single board machines aimed at the industrial PC segment, the so-called PC / 104 form factor. They were inferior in performance to ordinary desktops, because they were intended for tasks in which reliability prevails over functionality. For the same reason, Linux was not often used as an OS for these hardware platforms, there were various proprietary OS with real-time properties ( VxWorks , QNX , LynxOS, and so on ). I didn’t write “RTOS” (to which I include all three of the operating systems) from the considerations that quite often Windows CE and its development Windows Embedded were located on these hardware platforms. And carry this whole zoo to the RTOS, my language does not turn.

Consumer Single Board

Malinki also set a completely different trend. They, in fact, are aimed not at industrial real-time systems, but at the consumer segment, in which the price / functionality ratio is valued, but by this parameter the raspberries (and analogs) are significantly ahead of their competitors. After all, when you buy for the conditional 30-50 dollars, you get a full-fledged system integrator, with the help of which you can easily make a device with quite complex functionality using Linux. This is very useful for prototyping or DIY. Plus, of course, the raspberry can be used as a PC or a small server. Therefore, often, as the OS, ready-made Linux distributions are used, first of all, of course, Raspbian - Debian for Raspberry Pi, or a distribution with a funny name for the Russian-speaking Pidora - Fedora for RaspberryPi. For other similar platforms, there are also ready-made distributions provided by both hardware manufacturers and OS communities (producers). Agree, when it is necessary to make a prototype, the easiest way is to take ready, set packages, write a functional in python. As a result, quickly get a working prototype. An example is a robot that recognizes a line using OpenCV .

Linux in embedded devices

But the embedded world is much wider than standard ARM-based single-board devices. Moreover, they make up a relatively small part of the devices, and their main contribution is the popularization and simplification of the entry into the development of devices of this class. Serial devices are created on the basis of the same processors (systems on a chip) or similar, but the boards are designed for the task (project, device). Consequently, standard distributions are at least redundant, because they often use some kind of package manager, and you can easily deliver a lot of interesting things (but not necessary to solve a specific task). Embedded devices, however, usually come with complete functionality, and even this is called firmware (firmware). There is another class of Linux distributions for creating firmware. Such distributions allow you to “install” the necessary packages statically - by assembling them into the root file system, rather than dynamically - using the package manager from the repository. Typically, these distributions can be assembled not only for applications and libraries, but also for the kernel in a given configuration. And often also a cross-compiler, because compiling on the device itself is at least not efficient.

Yocto project

Today, the most famous similar distribution (project to create distributions) is the Yocto project . It, in turn, is based on another well-known project, OpenEmbedded , which is a kind of build system for Linux distributions. If you want to use the Raspberry Pi not as a ready-made small system integrator, but as a customizable device with Linux, then Yocto or its analogs would be an excellent option. Personally, I don’t see strong advantages in using non-standard Linux distributions with standard hardware, but if you plan to develop similar devices or have a desire to master the technologies themselves, then this approach looks the most promising. After all, while a specialized piece of hardware is being developed, programmers can develop and debug their parts of the system (algorithms, drivers, libraries, ...). That greatly reduces the development time, and hence the notorious TTM (time to market).

Openwrt

Another well-known Linux-based firmware development project is OpenWRT . I am sure that those who have fun with customizing routers have heard about it. On the basis of this project, firmware is made for various routers, which are one binary, including both the kernel and the root file system. Using firmware (and not universal distributions) in embedded systems is associated with the idea that the functionality of the final system is known at the time of its development, that is, even if the version of the router is updated, the firmware changes completely with all the functionality (or some of this firmware is replaced ). Installing, for example, office suites is usually not necessary, and is often prohibited at all, since this may introduce its own uncertainty. This approach allows, among other things, significant savings in hardware. The same routers, for example, have a far less powerful processor and far less memory than universal hardware.

Real time systems

Returning to the topic of industrial calculators, it is necessary to discuss the term “real-time system”. Many believe that real-time systems are faster. It's a delusion. It is probably related to historical background. After all, the term itself arose when the cars were slow. And the user noticed that the reaction of the system may lag behind his actions. The term “real time” meant that the system had to be responsive to any impacts, including operator actions. But on modern computers, the user (operator) is unlikely to notice the inhibition. In the overwhelming majority of cases, when you click on the menu, icon, button, we immediately see a redraw of the screen, unless of course everything is in order (the Internet is there, the process is not frozen, etc.). But if something unexpected happened, for example, the connection is gone, we will see the difference between the real-time systems (should be different). We will just reboot a regular smartphone. But if this system controls the power plant, then you know, this is not always possible. Hence we conclude that a real-time system should predictably, rather than quickly, respond to any event or set of events, regardless of its state or environment.

Linux on real-time systems

Naturally, there were (there are and will be) attempts to make a real-time system from Linux. The most famous is RTLinux , initially it was a patch for Linux, replacing the original “ completely honest scheduler ”, or rather inserting its own, which was set by one of the tasks by the Linux scheduler. This scheduler worked on static priorities of tasks, respectively, worked much more predictably. But it was no longer Linux, or rather the Linux functionality was not real-time.

ARINC-653

Another approach to provide real-time, somewhat similar to the RT patch for Linux, is the approach required by the ARINC653 standard or the so-called MILS approach. This approach implies that the system is projected in layers, the lower layer implies a very lightweight hypervisor, on the basis of which tasks of different degrees of criticality are performed in statically defined sections. I called the hypervisor very easy because it means that it has the highest criticality and therefore its code (algorithms) should be checked as completely as possible (ideally, the absence of unprocessed situations should be mathematically provable). Hence the code should be as small as possible. Well, Linux, as you probably understood, is located in its own section.

uCLinux

Attempts to use Linux in embedded systems began long ago. One of the first was an attempt to use Linux on systems where there is no hardware support for virtual memory (MMU). This project was called uCLinux and its contribution to the Linux kernel was the NOMMU or MMU-less mode.

Linux on real-time systems

Summing up a small summary of the attempts to use Linux on real-time systems, you need to answer the question of why this is happening. That is, on the one hand, Linux is not particularly (at the moment and in its pure form) adapted for real-time systems, but on the other hand, attempts are constantly being made to do this. And this happens due to the introduction of restrictions (replacement of the scheduler, introduction of the hypervisor, restrictions on the use of virtual memory, and so on). The answer, in my opinion, lies in the presence of a giant Linux code base. These are drivers, functional applications and libraries. Obviously, if you want to create a reliable system, you should use ready-made parts as much as possible, because the development of new ones, be it functional logic or driver, always contains the probability of introducing an error. And since modern real-time systems impose quite high demands on functionality, the reuse of ready-made functionality from Linux is becoming more and more enticing. In other words, the refinement of Linux to a real-time system no longer seems so expensive compared to the development of functionality, albeit based on a real-time operating system, because the entire system should have reliability, and not just part of it as an operating system kernel.

Windows in embedded devices

I want to go back to Windows for a while. At the dawn of my career, I had a discussion with a more experienced developer that Windows could not be used in reliable systems. To which he objected that if you test an already completed system with the necessary functional software, and prohibit any changes: updates, software installation, etc., the system will be reliable enough for many tasks, including the one we have decided. Now I have no doubt that my opponent was right, not me. Moreover, even ancient MS-DOS has been used in industrial systems for a long time. The fact is that multitasking, which seems so necessary, introduces uncertainty. And if you run software that completely controls the entire system, you can achieve much more deterministic behavior. In other words, if an indefinite number of tasks spin in the system, then it is unlikely that it will be possible to achieve certainty in the operation of all functions of the system. Therefore, the easiest way to increase the predictability of the system is to limit its functionality, and therefore - the rejection of universality during execution. What we, in fact, see in the above-mentioned examples of using Linux in real-time systems.

Microcontrollers

The example of MS-DOS as the base OS for industrial real-time systems leads us to the idea that if you use only your software, you can achieve predictable behavior of the entire system. And indeed it is! True, you need to make a reservation that this is possible only if the functionality of the system is small and clearly fixed. If all the functionality of the system is to control the motor using GPIO and receiving (transmitting) a limited set of commands via the UART interface, then it is not necessary to use the OS, you can create firmware (what is called bare-metal). This approach is quite often used in microcontrollers. But since microcontrollers became big (32-bit ARM with several KB of RAM versus 8-bit AVR-ok with a hundred bytes of RAM), the queries on functionality increased. Now, when developing firmware, at least software from manufacturers is used, which allows using some ready-made examples for working with a microcontroller, for example, the STM32Cube .

RTOSes

But since the requirements for functionality are constantly growing, firmware for microcontrollers are increasingly made on the basis of so-called RTOS. Unlike large real-time operating systems, these are relatively small open projects that provide full access to all code in the system. That is, there is a combination of concepts: on the one hand, the ready-made code is used, and on the other hand, the developer has full access to everything in the system, one can say, bare-metal firmware.

RTOS for microcontrollers is quite a lot. Therefore, to tell all about it will not work. I will highlight only a few, in my opinion, interesting projects and briefly tell you about their features.

FreeRTOS

Probably one of the most popular RTOS projects now is FreeRTOS . Some say that this is not a full-fledged OS, but only a scheduler. But if we take into account the reasoning above about bare-metal, a large number of supported microcontrollers and what many application software is written and integrated, then a small functionality looks more like a virtue than a disadvantage. This allowed to become a de facto standard for microcontrollers, as written on the project website.

Contiki

Contiki is an RTOS developed by Adam Dunkels , creator of such famous TCP / IP stacks as lwIP and uIP. I would say that the whole OS is built around the network stack. The availability of IPv6 support and small resource requirements make this project interesting for creating various kinds of wireless devices.

RTEMS

RTEMS Real-Time Executive for Multiprocessor Systems. Originally developed for the military, the acronym stands for Real-Time Executive for Missile Systems, and then Real-Time Executive for Military Systems. Pretty old, but still lively open project. A prominent representative of the libOS approach. When the software being developed is linked from an already assembled OS, which is not only the kernel, but also all the available services. It compiles and ships as a library to the compiler, which is quite convenient in the early stages of development.

eCos

eCos Embedded Configurable Operating System. It is also quite an old project, previously very popular. The main idea is to make a very configurable OS, that is, to include in the kernel only what is needed.

Other RTOSes

The list can go on for quite some time. I will mention another NuttX project below. And for those who are interested in a more detailed list, I advise you to look at Wikipedia . For microcontrollers, I would also mention ChibiOS / RT , MicroC / OS (µC / OS) , Nut / OS , RIOT . But of course, it all depends on the task.

Arduino

I think talking about embedded would be incomplete without mentioning the Arduino. After all, like RaPi, they are very common and have greatly contributed to the popularization of microcontrollers. I myself am rather skeptical about the topic of arduino, so I will miss the criticism of fans of this technology. But about the fact that this is a very interesting technology, I can give an example of a bread machine, described in Habré . Very pleasant decision. Well, or already given example with a robot that recognizes the line on openCV , but it also uses arduino.

Microkernel

I have never mentioned the concept of a microkernel, which, as many know, makes the system reliable and predictable. On the one hand, this is true, but on the other, as always, not quite. More precisely, of course true, but the belief that this concept (architecture) will immediately turn your system into a hard real-time system is a delusion. It is rather a marketing slogan: “we are a real-time system because we are built on the principle of a microkernel”. But the microkernel principle only makes it possible to simplify software development, since most of the parts are taken out into user space. But what to do if you have a server that is broken for work? You will restart it, but it takes time, and if you do not have it? In addition, the classic micronuclear architecture has its drawbacks! It is, for example, slow, since there are a lot of system calls (message transfers between servers and application software).Otherwise, everyone would have long since switched to pure micronuclear architecture, and who, for example, saw projects on L4 , but they exist. Well, of course, many people remember the controversy between Linus Torvalds and Andrew Tanenbaum .

That is, the concept of a microkernel is not a silver bullet. But as a very good idea is applied to one degree or another in most modern operating systems. And the creation of a reliable system in the end still depends on the end developer and the possibilities that the operating system provides for its construction.

Embox location in the world embedded systems

I have already talked a lot about various aspects of the embedded-world, but I never got to the place of Embox in it. Well, I can say that in the examples described above, it is possible that there is no need to use Embox. Moreover, we usually ask users why they need Embox? If the use of Embox does not give any advantages, we recommend trying something from the list above or something else (for example, Android). But there are a number of cases in which the use of Embox gives a tangible gain.

System for the development of equipment

I'll start with the first use of Embox. At that time, it was not even Embox, but it was some C and an assembler code that allowed it to run very quickly and execute the utilitarian code. At that moment it was a project to help engineers debug hardware developed on FPGAs. He was able to run very quickly, much faster than similar code written using the already mentioned RTEMS. This is important because it was also used during the on-stage simulation. Plus, they began to use it on real hardware, for this a small interpreter was written, who knew how to call user commands. Later, this direction was developed, and the TCL interpreter was ported, since it is familiar to FPGA developers.And since, in a specific configuration, teams have direct access to the equipment (to the entire address space), the developers were able to do fairly complex tests.

Сертифицируемый Linux

One of the first third-party applications was the rather specific requirement for code certification. There was some kind of device with limited functionality, including: working with sockets (UDP), a file system, and some other functionality. All the functionality was implemented by the customer as software based on Linux. This device was not x86 or ARM. It had its periphery. It was necessary to certify the code that is used in the device, since the certified distributions could not be used there. An attempt to cut the Linux kernel led to about 500 thousand lines of code, plus there were problems with #ifdef and other macros. And the customer, assessing the cost of certification of this product, asked to consider other options. Embox at that time already had a network stack,file system and it was decided to modify it to meet the requirements of certification. So we had a language for describing Mybuild modules, we to some extent solved the problem with macros, some other problems. As a result, we have achieved that in the final image we have only the code used (stated in the configuration), and it is usually not very much required for a specific task.

Linux without Linux

Direction with certification is generally quite popular. Quite often, customers have code under Linux, but for some reason they cannot use this OS on their device. Embox has the ability to easily transfer application software from open source projects under Linux. Thus, a number of popular projects were ported, even Qt (embedded version) or the SIP phone already described on the Habré . In this case, since when using Embox only the required modules are included, the resources required for launching are much less.

The idea to run POSIX-applications on systems with small resources is the main for another open project - NuttX. At some points, this project is superior to Embox, at others - vice versa. Examples with Qt and SIP-phone, as far as I know, NuttX is too tough. But the project is really very interesting.

It is also worth noting that part of the RTOS also adds a POSIX layer. For example, FreeRTOS or RTEMS, which today fully complies with POSIX Profile 52, meaning “one process, many threads, file system” . On RTEMS, they even make successful experiments on Qt launch on microcontrollers.

Secure linux

If, on the other hand, we look at the static assembly of the image of small RTOS, that is, determine all the functionality at the time of creation, then you will notice that it turns out natural protection against malicious code, that is, viruses. Of course, in Linux you can make a very good security system, but still the main security problems are related to the human factor (weak passwords, loss of passwords, elevated user rights, etc.). That is, when obtaining rutovy rights, all protection, in fact, becomes irrelevant and you can install anything anywhere. In the case of a static assembly, an attacker can use only the existing functionality. Yes, he may be able to get statistics or make some kind of customization, but, you see, this is far less evil than in the case of installing malware. A plus,on universal systems, the cost of the protection system, let's say, is not zero. In our case, this is much cheaper, since it was already laid at the design stage.

Real-time Linux

I have devoted quite a lot to the issue of using Linux as a real-time system. Explained why this is difficult to achieve, as well as why attempts are being made. So, back to the already mentioned link to an article about a robot with line recognition on OpenCV . If you looked at the link, then you probably noticed that OpenCV is spinning on RaPi, and the motors are controlled on a separate Arduino board. There are a couple of reasons for this: the first is the scheduler, the second is that it comes from user mode, and Linux does not have access to the hardware in it. As you probably guessed, in Embox both problems can be solved much easier than in Linux. And on the same board with sufficient resources, you can start OpenCV and manage the motors.

There were several devices that combined Linux functionality and real-time operation. An example is a CNC machine that was controlled via a web interface, briefly described by me in an article . Well, if we make robots on several boards, then these are multi-agent systems .

Internet of things

Embox, like virtually all RTOS for microcontrollers, has low resource requirements. Here isAn example of a toy on stm32vl-discovery already described on Habré. Embox even started on a 16-bit MSP-430 with 512 bytes of RAM. But if you look, for example, at the code from an article with a toy, you will notice that it uses not the standard POSIX streams, but its own implementation of light threads. Naturally, if you go further and implement all the code yourself, I’m sure you can achieve better results in memory costs. But smart sensors are only one part of the IoT. They transfer data to some more powerful nodes. And they do it according to some protocol. But if Embox will also be running on this node, and the library code implementing the communication protocol will be common, this will simplify development. Indeed, first, the code is common, and even if there is an error in the implementation of the protocol, it is leveled bythat the same code will work on both sides of the conversation. And secondly, the code can be debugged on a platform with large resources, which is much more familiar and simple.

A little more about the difficult fate of the project can be found by watching the video from one of our first first performances on CodeFreeze .

Conclusion

This article reveals only a small segment in a diverse embedded world. Such important topics as household appliances, automobiles, instrument making, industrial control systems are not mentioned. But as I said at the beginning, in the article I just want to “talk” about the features of embedded. I hope the article was quite interesting, and after reading it, you learned something new! And let's discuss the features of this area in the comments.

PS Well, yes, Embox is not only “embedded”, but also “ opensource ”. So, we invite you to use the project and of course participate in it!