The whole truth about RTOS from Colin Walls

    The whole truth about RTOS. Article # 1.

    Real-Time Operating Systems: An Introduction

    This series of articles is devoted to a thorough study of all aspects of Real-Time Operating Systems (RTOS). Articles are targeted at developers who are curious to find out how RTOS works and how to use them. The starting point will be a discussion of real-time systems in general, then we will discuss how RTOS can simplify their implementation and make the resulting code more reliable.

    Looking inside the RTOS, we will see how the task scheduler works. Thanks to multithreading, it seems that the CPU performs several operations simultaneously. This is not magic; an understanding of how a task scheduler works is available even to an inexperienced software engineer. We will also talk about other RTOS objects: interaction between tasks and synchronization, real-time mode, memory management, etc., everything will be accurately described and supported by code examples.

    For the developer, the key aspect of the RTOS is the API, a set of procedure calls that provides access to the RTOS functionality. The series will feature articles on this topic on how the API works, what standards are available and how to switch from one API to another.

    Below is a list of topics we will cover shortly:

    • Program structure and real time
    • Real Time Operating Systems
    • Tasks and planning
    • Interaction between tasks and synchronization
    • Other operating system services
    • Nucleus SE
    • Scheduler
    • Tasks
    • Memory sections
    • Signals
    • Event flag groups
    • Semaphores
    • Mailboxes
    • Queues
    • Channels
    • System time
    • Software timers
    • Interruptions
    • Diagnostics and error checking
    • Initialization and launch

    The series of articles is not tied to any specific real-time operating system, most of the material is applicable to the publicly available implementation options for RTOS. According to the author, the use of ready-made, commercial OS with existing support is the most reliable and most productive way to work. One of the articles will be devoted to a detailed discussion on the topic “make vs buy” and other methodologies for choosing a RTOS.

    However, in order to explain the internal structure of the RTOS, examples of the real product code — Nucleus SE — are used.

    Source: http://www.embedded.com/design/operating-systems/4442729/Introducing--RTOS-Revealed

    The whole truth about RTOS. Article # 2


    RTOS: Structure and Real-Time Mode
    Program Structure and Real-Time Mode

    This series of articles is about embedded systems and, in particular, about software running in embedded systems. Let's start with the definition. What is an embedded system? In 1986, when I wrote the first book on this topic, such a term did not yet exist. The concepts of “dedicated system” or “micro system” were used, but they, of course, did not reflect the whole essence. A few years later, the word “embedded” came into use, and all specialists began to actively use it.

    Returning to the definition of an embedded system. In an attempt to explain to friends and family what I’m working on, I came to the following explanation: an embedded system is any electronic device that has a processor, but which is not usually described as a computer.

    The operating system (OS) is always on the computer; in modern embedded systems, only some types of operating systems are used. Despite the fact that the use of the kernel prevails in high-performance (32-bit and 64-bit) systems, one can also benefit from its use in low-power devices. The focus of these articles is on operating systems, both in general and with the specifics of implementation.

    Why bother to use the operating system?

    Let's see why the operating systems are applied in principle. There are many explanations, some of which depend on both the human factor and technical characteristics. I remember the story. In one of our offices there was a kitchen corner where you could make coffee. On the door hung a sign saying: "Please do not close the door." Under it, someone wrote: "Why not?", To which someone else replied: "Because." A very shortened version of the phrase “because we tell you to do it that way.” For the same reasons, operating systems are used in some systems, simply because they have to do this.

    Another explanation is in the use of desktop applications. How do you get started writing software for PC or Mac? You turn on the computer, start Windows / Linux or macOS and start programming. The presence of the operating system is a predetermined condition, and it provides a number of useful services. It is unlikely that you decide to start from scratch by programming the “bare” hardware. Therefore, it is not surprising that an engineer who has experience in writing software, but for whom the firmware is new, will count on having an operating system in the system he is developing.

    It is worth noting a key aspect of the desktop OS that users are aware of - the user interface (English User Interface, UI). Ask someone what Windows is and you will be told that these are windows, menus, dialog boxes, icons, but the file system, inter-program communication and the ability to interact with other systems are hardly mentioned. This is the main difference between the desktop and the embedded system: there may be no user interface in the latter, and if there is one, then it is fairly straightforward. This is the first of many key differences:

    • An embedded system typically runs one software application from power up to shutdown.
    • Embedded systems have limited resources. The amount of memory can be quite large, but not the fact that it can be expanded; The processor has limited power.
    • Many embedded applications work in real time. More on this - just below in this article.
    • The firmware development tools are specialized and run on the host computer (for example, on a PC), and not on the target system.
    • Firmware upgrade is a complex process. Despite the emerging opportunities due to the connected devices, firmware updates during operation are still not the norm (as opposed to regular updates and patches (patches) used for desktop software).

    Before we consider how to structure embedded applications, let's look at the concepts used on computers to run programs using the operating system.

    First, there is the execution of DOS-style programs, when programs are executed alternately.



    Each program is launched, implemented and terminated. We use, say, program 1, then program 2, then maybe take a break, turn to program 3, and then go back to program 2. The second use of program 2 starts anew: the launch does not start from where we left off this (except when the application itself does not provide such an opportunity).

    After DOS, much has become more complicated, as Windows has become commonplace. Running Windows-style programs involves running multiple programs in multi-threaded mode.



    In this mode, it seems that programs run simultaneously, and this illusion is controlled by Windows. Program 1 starts first, then program 2 starts at the same time, then program 3. Program 2 ends, programs 1 and 3 are still running. Program 3 ends, only Program 1 remains. Later, Program 2 resumes, and Program 1 ends, only Program 2 remains. This is a realistic course of events when using Windows as a regular user. The operating system allocates resources so that all programs correctly use the processor. It also provides simple communication between programs (for example, the clipboard) and controls the user interface.

    Some portable devices require more flexibility than DOS can offer, but given the limited resources, lower overhead is required than with Windows. As a result, we have the execution of programs in the style of iOS, namely:



    Programs are started one by one, but their status is automatically saved so that you can continue from the same place at closing. For example, program 1 starts, then pauses to use program 2, then, for example, the device turns off for a while. When resuming, program 3 is loaded (the state of program 2 is saved automatically), and then the user returns to program 2, continuing to work in it. I understand that the execution model of an iOS application is much more complicated than the one described above; nevertheless, this description is only a summary of the user's primary perception.

    Most built-in applications do not match any of the above models. As a rule, the device starts the program at power on and continues to work only with this software for an indefinite amount of time. The structure of such a code should be carefully considered.

    Embedded Models

    Desktop systems are almost all the same. From the point of view of an application program, all personal computers with Windows are identical. Embedded systems are unique: each is different. Differences may be technical: processor type, memory size, number of peripherals. Priority aspects of applications may also differ in execution speed, energy consumption, security and reliability. There may be commercial differences that affect pricing: production volumes and the choice between customized or standard hardware.

    These differences are important to developers of embedded software. For example, the choice of development tools (compilers, debuggers, etc.) depends on the type of processor. Many factors influence the choice of the operating system or even the decision itself to apply it. The software structure (software model) must be carefully selected for each individual embedded application.

    Depending on the requirements of the application, embedded software may have different structures of different levels of complexity, for example:



    The simplest form is a closed structure in which the same sequence of actions is repeated. If the application is simple enough to be implemented in this way, this is ideal: simple code is reliable and straightforward. However, this structure is extremely sensitive to the part of the code that may take too much processor time, that is, some commands are executed so long that they delay the execution of other application tasks. In addition, this model does not scale well: improving the code can be a problem, because add-ons can affect the performance of old code.

    If something more complicated is required, you can try to place a non-time-critical part of the code in the main loop, and a time-sensitive part in the interrupt handler (English Interrupt Service Routines, ISR). Interrupt handler actions are generally fairly short, performing only critical tasks and marking parts of the main loop to complete work at the earliest opportunity. Difficulties can arise when it is necessary to distribute the work between the main loop and the interrupt handler (as well as between several developers).

    For maximum flexibility, applications will need to be divided into several separate, relatively independent programs (let's call them tasks or threads) that will be executed in multi-threaded mode. Smaller interrupt handlers can also be included in the system, but will mostly notify about tasks or trigger an action. To achieve this, you need an operating system, or at least a kernel. The use of multithreading not only provides a flexible distribution of functionality in the software, but also facilitates the distribution of work among developers.

    What is real time?

    Earlier, I wrote that many embedded applications work in real time. In this context, it is customary to talk about real-time operating systems, and not about a simple OS. We define the terminology.

    “A real-time operating system is a system in which the correctness of the calculations depends not only on the logical correctness of the calculations, but also on the time in which the result will be achieved.

    If the temporary restrictions of the system are not met, it is considered that a system failure has occurred. "

    An important feature of such a system is its predictability or, as they often say, determinism.

    The real-time operating system is not necessarily very fast, “real time” does not always mean “really fast time”. This means that any necessary action will be performed in a timely manner. That is, rather quickly, but at the same time and not too fast (that is, rather slowly).

    The RTOS (when used correctly) provides very precise control over the allocation of processor time to perform tasks and, therefore, makes applications completely deterministic. The only thing that can spoil this picture is interruptions. There are RTOSs that fully control interrupts. Their job is to manage interrupt service as part of the task scheduler. In spite of the fact that this would have led to predictable behavior, this mechanism is rather complicated and contains a high overhead.

    Most RTOSs simply allow the interrupt handler to "steal" time from a task running at the time of the interrupt. This, in turn, forces the programmer to write the interrupt handler code as short as possible. As a result, we have the permissible error of real time. The only difficulty is making calls to RTOS services as part of a handler task. Some calls may be quite harmless, while others will cause a context switch when returning from an interrupt. Such a situation should be specifically addressed, which is possible with the help of various RTOS.

    Source: https://www.embedded.com/design/operating-systems/4442900/Program-structure-and-real-time

    When we worked on our own real-time operating systemThe MAKS RTOS (previously published articles about it) , our team “stumbled” on the blog of Colin Walls (Colin Walls), an expert in the field of microelectronics and embedded software of Mentor Graphics. The articles seemed interesting, they were translated for themselves, but in order not to “write to the table” they decided to publish. I hope they will also be useful to you. If so, then we plan to publish all the translated articles of the series.

    About the author: Colin Walls has been working in the electronics industry for more than thirty years, spending a significant amount of time on embedded software. He is now an embedded software engineer in Mentor Embedded (a division of Mentor Graphics). Colin Walls often speaks at conferences and seminars, author of numerous technical articles and two books on embedded software. Lives in the UK. Colin's professional blog: http://blogs.mentor.com/colinwalls , e-mail: colin_walls@mentor.com

    Article 3 is published here.

    Also popular now: