Overview of one Russian RTOS
Hello!
I have prepared a series of articles devoted to a specific Russian RTOS, of which I am one of the creators. It turned out a kind of "Book of Knowledge", an informal guide for the programmer, which I hope will help those who use this RTOS.
I will talk about the features of the work of this RTOS. If it is about something else, it is only because without it the features will be incomprehensible.
')
Below I will talk about the features of the RTOS in general, and about the features of the MAKS RTOS in particular. I will introduce 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 the MAKS RTOS with code elements, tell you how to configure the MAKS RTOS for work, and address the issues of strong typing and drivers.
Part 1. General information (this article)
Part 2. Core MAX MAX
Part 3. The structure of the simplest program
Part 4. Useful theory
Part 5. The first application
Part 6. Thread synchronization tools
Part 7. Means of data exchange between tasks
Part 8. Work with interruptions
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 the OS, with whom they had to work, and they had to work on a PC or earlier computers. Not once or twice after the story about what OS we started designing, it was possible to hear 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 something like DOS,” and then there were suggestions based on this wrong message.
And everything is wrong there.
Let's start with the fact that the time of single-tasking OS (what DOS was) is a thing of the past. If multitasking is not required, then it is necessary and sufficient to take any regular library for controllers. Several alternative libraries from the manufacturer are attached to the STM32 (HAL, Cube MX, etc.), for the AVR there are also libraries LUFA, Arduino and many others. All of them, along with the open libraries of TCP / IP, FAT, USB, EmWin and others, completely overlap the functions of DOS (who remembers - Int 21h, Int 13h, Int 10h). OS for this is not required.
Thus, to be at least somehow necessary:
Modern OS should be multi-tasking.
Consider where this OS should work. And it will work not on a general-purpose computer, but in some final product, whether it be a robot, a machine, an intelligent switch or something like that.
Consequently:
In addition, the RTOS MAX in the current implementation is designed to work on low-cost microcontrollers. They do not provide a means of memory virtualization (MMU block). 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 external RAM is slower than in the built-in flash memory.
Therefore:
Actually, we examined the main features of all the OSes running on such hardware. In principle, if you use a search engine, you can quickly find several ready-made RTOSs on the Internet, which also adhere to the same principles.
Why do another one?
To begin with, all the operating systems found at the time of the start of work are procedurally oriented. Procedural programs are poorly structured, they are difficult to maintain, they are easier to make annoying errors, but I will not dwell on the advantages of the object-oriented approach for a long time. I’ll only cite the fact that giants like Microsoft have long been trying to translate their systems to an object-oriented approach, introducing .NET.
It cannot be said that the procedural-oriented approach in the existing RTOS is caused by the hardware features. The object-oriented library Arduino is perfectly used on 8-bit microcontrollers. The resulting assembly code can not be called cumbersome. The object-oriented library mcucpp of Konstantin Chizhov, on the same eight-bit controllers, shows such wonders of optimizing assembly code that are difficult to get even manually. And in the 32-bit environment for which the MAKS RTOS is designed, the loss of the object-oriented approach cannot be said at all.
Consequently, the procedural orientation of other operating systems is rather a heavy legacy. Starting the development in the 90th year, it is very difficult to quit the old developments. Easier to make a new OS. What, in fact, we do.
In addition, in the MAKS RTOS, the functions of transparent interaction between products are laid down in advance, but a separate article will be devoted to this.
Let us consider in more detail the architecture of the MAKS RTOS. The figure shows the overall system architecture.
An application is actually a user program.
The kernel schedules and interacts user program threads with each other. True, the word “stream” was cited for continuity with concepts from common use operating systems. In the framework of the MAKS RTOS, they are called tasks. Therefore, it would be more correct to say that the kernel performs the planning and interaction of the tasks of the user program.
If you take up literalism entirely, you should write not a “core”, but a “microkernel”. The functions of these two entities are similar, but there are thousands of functions in the cores of common-use operating systems, and in a microkernel it’s good if there are hundreds, and maybe even dozens. The microkernel is extremely simple in structure.
OS services are separated from the kernel. In essence, they are libraries that unify the user program's access to hardware. These services may access the kernel as normal programs, or they may not even access. In particular, lower level drivers have no dependency on the OS kernel. This is the difference between RTOS MAX and general operating systems, where drivers are part of the kernel.
In the next article I will talk about the core MAX RTOS and the priority of tasks.
I have prepared a series of articles devoted to a specific Russian RTOS, of which I am one of the creators. It turned out a kind of "Book of Knowledge", an informal guide for the programmer, which I hope will help those who use this RTOS.
I will talk about the features of the work of this RTOS. If it is about something else, it is only because without it the features will be incomprehensible.
')
Below I will talk about the features of the RTOS in general, and about the features of the MAKS RTOS in particular. I will introduce 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 the MAKS RTOS with code elements, tell you how to configure the MAKS RTOS for work, and address the issues of strong typing and drivers.
Part 1. General information (this article)
Part 2. Core MAX MAX
Part 3. The structure of the simplest program
Part 4. Useful theory
Part 5. The first application
Part 6. Thread synchronization tools
Part 7. Means of data exchange between tasks
Part 8. Work 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 the OS, with whom they had to work, and they had to work on a PC or earlier computers. Not once or twice after the story about what OS we started designing, it was possible to hear 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 something like DOS,” and then there were suggestions based on this wrong message.
And everything is wrong there.
Let's start with the fact that the time of single-tasking OS (what DOS was) is a thing of the past. If multitasking is not required, then it is necessary and sufficient to take any regular library for controllers. Several alternative libraries from the manufacturer are attached to the STM32 (HAL, Cube MX, etc.), for the AVR there are also libraries LUFA, Arduino and many others. All of them, along with the open libraries of TCP / IP, FAT, USB, EmWin and others, completely overlap the functions of DOS (who remembers - Int 21h, Int 13h, Int 10h). OS for this is not required.
Thus, to be at least somehow necessary:
Modern OS should be multi-tasking.
Consider where this OS should work. And it will work not on a general-purpose computer, but in some final product, whether it be a robot, a machine, an intelligent switch or something like that.
Consequently:
- the product does not need to run or unload programs. The set of programs is permanent. Turned on the product - they started. As long as 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. In this case, the interface tools can often be specific (buttons, lamps), but there can be a touch screen;
- in a public computer, the delay in the execution of a stream, and indeed of this or that process for a few tenths of a second will not create any problems. In working with the equipment such delays are unacceptable. A lot of hardware things require millisecond reactions - supporting engine speed, tracking sensors, generating step pulses, and much more: the slightest delay will lead to a malfunction of the entire hardware system. That is why the OS for working with hardware is 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 properly designed program, the guaranteed response time to certain events will be observed.
In addition, the RTOS MAX in the current implementation is designed to work on low-cost microcontrollers. They do not provide a means of memory virtualization (MMU block). 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 external RAM is slower than in the built-in flash memory.
Therefore:
- in the MAKS RTOS there is no concept of “process”. They cannot be isolated from each other (there is no appropriate equipment), although it will later be shown that the concept of “process” can be implemented due to the features of the MAX RTOS when running in several controllers simultaneously, but it is impossible to start isolated processes within one microcontroller;
- The OS is compiled and assembled monolithically, along with the user program. Both of them are located in flash memory, since the execution in RAM on some controllers reduces performance, and in some cases it is simply impossible (if there is no external RAM chip in the system).
Actually, we examined the main features of all the OSes running on such hardware. In principle, if you use a search engine, you can quickly find several ready-made RTOSs on the Internet, which also adhere to the same principles.
Why do another one?
To begin with, all the operating systems found at the time of the start of work are procedurally oriented. Procedural programs are poorly structured, they are difficult to maintain, they are easier to make annoying errors, but I will not dwell on the advantages of the object-oriented approach for a long time. I’ll only cite the fact that giants like Microsoft have long been trying to translate their systems to an object-oriented approach, introducing .NET.
It cannot be said that the procedural-oriented approach in the existing RTOS is caused by the hardware features. The object-oriented library Arduino is perfectly used on 8-bit microcontrollers. The resulting assembly code can not be called cumbersome. The object-oriented library mcucpp of Konstantin Chizhov, on the same eight-bit controllers, shows such wonders of optimizing assembly code that are difficult to get even manually. And in the 32-bit environment for which the MAKS RTOS is designed, the loss of the object-oriented approach cannot be said at all.
Consequently, the procedural orientation of other operating systems is rather a heavy legacy. Starting the development in the 90th year, it is very difficult to quit the old developments. Easier to make a new OS. What, in fact, we do.
In addition, in the MAKS 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 MAKS
Let us consider in more detail the architecture of the MAKS RTOS. The figure shows the overall system architecture.
An application is actually a user program.
The kernel schedules and interacts user program threads with each other. True, the word “stream” was cited for continuity with concepts from common use operating systems. In the framework of the MAKS RTOS, they are called tasks. Therefore, it would be more correct to say that the kernel performs the planning and interaction of the tasks of the user program.
If you take up literalism entirely, you should write not a “core”, but a “microkernel”. The functions of these two entities are similar, but there are thousands of functions in the cores of common-use operating systems, and in a microkernel it’s good if there are hundreds, and maybe even dozens. The microkernel is extremely simple in structure.
OS services are separated from the kernel. In essence, they are libraries that unify the user program's access to hardware. These services may access the kernel as normal programs, or they may not even access. In particular, lower level drivers have no dependency on the OS kernel. This is the difference between RTOS MAX and general operating systems, where drivers are part of the kernel.
In the next article I will talk about the core MAX RTOS and the priority of tasks.
Source: https://habr.com/ru/post/336308/
All Articles