Overview of one Russian RTOS

    Hello!

    I have prepared a series of articles on a specific Russian RTOS, of which I am one of the creators. The result was a kind of “Knowledge Book”, an informal guide for the programmer, which, I hope, will help those who use this RTOS.

    I will talk about the features of this RTOS. If it’s about something else, it’s only because without it the features will not be clear.

    Below I will talk about the features of the RTOS in general, and the features of the RTOS MAX in particular. I will present its architecture.

    In the future, I will regularly post new publications: the second will be devoted to the core of the system, in the following I will introduce the structure of the simplest program running under the MAX MAX RTOS with code elements, tell you how to configure the MAX Max RTOS for work, and touch upon strict typing and drivers.

    Part 1. General information (this article)
    Part 2. Kernel RTOS MAX
    Part 3. The structure of the simplest program
    Part 4. Useful theory
    Part 5. First application
    Part 6. Means of synchronizing threads
    Part 7. Means of exchanging data between tasks
    Part 8. Working with interruptions

    What are real-time operating systems and features of the new RTOS MAX


    Surprisingly, the term “real-time operating system” is understood by many to be completely different. They look at the term “Operating System” through the prism of those operating systems with which they have worked, and they have worked with on PC or earlier computers. More than once or twice after talking about which OS we started to design, I heard proposals that were simply impossible to implement. All the interlocutors went along the following chain: “This is an operating system, but for weak (relatively modern PC) processors, it means it's something like DOS”, and then the suggestions coming from this wrong message went on.

    But everything is wrong there.

    To begin with, the time of single-tasking OS (what was DOS) is a thing of the past. If multitasking is not required, then it is necessary and sufficient to take some regular library for controllers. STM32 comes with several alternative libraries from the manufacturer (HAL, Cube MX, etc.), AVR also has LUFA, Arduino and many others. All of them, along with the open libraries TCP / IP, FAT, USB, EmWin and others, completely overlap DOS functions (who remembers - Int 21h, Int 13h, Int 10h). An OS is not required for this.

    Thus, to be at least somehow necessary:
    A modern OS must be multitasking.

    Consider where this OS should work. And it will not work on a general-purpose computer, but in some kind of final product, whether it be a robot, a machine tool, an intelligent switch, or something like that.

    Consequently:

    • the product does not need to run or download programs. The set of programs is permanent. They turned on the product - they started. While the product works, they also work;
    • The OS does not receive any commands from the operator. The OS itself does not require any console. All user interaction is carried out by application programs. Moreover, often the means of the interface can be specific (buttons, lamps), but there can also be a touch screen;
    • in a public computer, a delay in the execution of a thread, or indeed a process for a tenth of a second, will not create any problems. When working with equipment, such delays are unacceptable. A lot of hardware requires millisecond reactions - supporting engine speed, tracking sensors, generating step pulses, and much more: the slightest delay will cause the entire hardware system to malfunction. That is why the OS for working with the equipment are called "real-time operating systems." In such an OS, all threads are required to receive guaranteed processor time for a guaranteed period of time. In other words, in a correctly designed program, the guaranteed response time to certain events will be observed.

    In addition, in the current implementation, RTOS MAX is designed to operate on low-cost microcontrollers. They do not provide memory virtualization tools (MMU). In addition, these controllers have a large amount of flash memory, sometimes specially adapted for fast execution of programs. The amount of RAM in the controller itself is usually small, and the execution of programs in the external RAM is slower than in the built-in flash memory.

    Therefore:

    • in the RTOS MAX there is no concept of “process”. It is impossible to isolate them from each other (there is no corresponding equipment), however, then it will be shown that the concept of “process” can be realized due to the features of the MAX MAX RTOS when executed in several controllers at the same time, but it is impossible to start isolated processes within the same microcontroller;
    • The OS is compiled and compiled monolithically, together with the user program. Both of them are located in flash memory, since execution in RAM on some controllers reduces performance, and in some cases it is simply impossible (if the system does not have an external RAM chip).

    Actually, we examined the main features of all OSs running on such hardware. In principle, if you use the search engine, you can quickly find several ready-made RTOS on the Internet that also adhere to the same principles.

    Why was there one more thing to do?

    To begin with, all operating systems found at the time of the start of work are procedurally oriented. Procedural programs are poorly structured, they are difficult to maintain, it is easier to make annoying mistakes in them, but I will not dwell on the advantages of an object-oriented approach. I will only refer to the fact that giants like Microsoft have been trying for a long time to transfer their systems to an object-oriented approach, introducing .NET.

    This is not to say that the procedurally-oriented approach in the existing RTOS is caused by the features of the equipment. The Arduino object-oriented library is perfectly used on 8-bit microcontrollers. The resulting assembler code cannot be called sloppy. The object-oriented mcucpp library of Konstantin Chizhov, on the same eight-bit controllers, shows such miracles of optimizing assembler code that it is difficult to obtain even manually. And even in the 32-bit environment for which the MAX MAX RTOS is designed, it is completely impossible to talk about losing the object-oriented approach.

    Consequently, the procedural orientation of other OSs is rather a heavy legacy. Starting development in the 90th year, it is very difficult to abandon the old developments. It’s easier to make a new OS. What, in fact, we did.

    In addition, in the MAX MAX RTOS, the functions of transparent interaction between products are laid down in advance, but a separate article will be devoted to this.

    General information about RTOS MAX


    Let us consider in more detail the architecture of the Max. The figure shows the general system architecture.


    An application is a user program itself.

    The kernel schedules and interacts with the user program threads. True, the word "stream" was given for continuity with concepts from common operating systems. In the framework of the MAX MAX RTOS, they are called tasks. Therefore, it would be more correct to say that the kernel implements the planning and interaction of the tasks of the user program.

    If you are completely engaged in literary studies, then you should write not the “core”, but the “micronucleus”. The functions of these two entities are similar, but in the kernels of common operating systems there are thousands of functions, and in a microkernel it is good if there are hundreds, or maybe even tens. The microkernel is extremely simple in structure.

    OS services are separate from the kernel. At their core, they are libraries that unify the user program's access to hardware. These services may access the kernel like regular programs, or they may not even access it. In particular, lower-level drivers have no dependency on the OS kernel. This is the difference between the MAKS RTOS and general operating systems, where drivers are part of the kernel.

    In the next article I will talk about the MAX RTOS kernel and the priority of tasks.

    Also popular now: