RTOS in STM32 MCU Development

可乐zzZ

RTOS in STM32 MCU Development [Copy link]

Many STM32 MCU beginners start with bare metal, and bare metal can indeed develop good products. However, as an embedded software engineer, and not using low-end MCUs like 51, it is definitely not enough to only use bare metal to develop products.

It takes a process to change from bare metal thinking to RTOS (Real Time Operating System) thinking, and it will be painful at the beginning. But after a while, when you understand some of the content and can write some demos, you will find that RTOS is not difficult.

Now FreeRTOS can be directly configured and used in the CubeMX tool, which is quite convenient.

Why do we need an RTOS?

Why do we need RTOS? Just like when we first learned C programming, the teacher told us that pointers are very important. At that time, you must have a big question: what are the benefits of pointers?

I kept thinking: Can I write a program without pointers? Now think about it, if there are no pointers in C language, will it be "impossible to move forward"?

Back to the topic, why do we need RTOS?

The general programming idea of simple embedded devices is as follows:

main

{

{Processing transaction 1};

{Processing transaction 2};

{Processing transaction 3};

.......

{Process transaction N};

}

isr_server

{

{handle interrupt};

}

This is the most common idea, and it is certainly sufficient for simple systems, but such systems have poor real-time performance.

For example, if "Transaction 1" is a user input detection, when the user inputs, if the program is processing the transactions under Transaction 1, then the user input will be invalid, and the user experience is "this button is not sensitive, this machine is very slow". If we put the transaction into the interrupt for processing, although the real-time performance is improved, it will lead to another problem, which may cause the interrupt to be lost. This consequence is sometimes more serious and worse than "a little slower"!

For example, if transaction 2 is a task that only takes 1 second to process, then it is obvious that transaction 2 will waste CPU time.

Improvement ideas

Did you see the limitations of bare metal development above?

At this time, we may need to improve our programming ideas. Generally, we will try to adopt the "time slice" method. At this time, the programming will become the following method:

main

{

{When the time slice of transaction 1 expires, process transaction 1};

{When the time slice of transaction 2 expires, process transaction 2};

.......

{When the time slice of transaction N expires, process transaction N};

}

time_isr_server

{

{Judge whether the time slice of each transaction has arrived and mark it};

}

isr_server

{

{handle interrupt};

}

It can be seen that this improved idea makes it possible to control the execution time of transactions, and transactions will only be executed after their own time slices arrive. However, this method still cannot completely solve the "real-time" problem, because after the time slice of a transaction arrives, it cannot be executed immediately. It must wait until the time slice of the current transaction is used up and the time slice of the subsequent transaction has not arrived before it has a chance to obtain "execution time".

At this time, we need to continue to improve our thinking. In order to ensure that a transaction can be executed immediately after the time slice arrives, we need to change the return position of the program after determining the time slice in the clock interrupt so that the program does not return to the position where it was just interrupted, but starts executing from the transaction that has obtained the latest time slice. This completely solves the real-time problem of transactions.

We have made improvements on this idea. We need to save the current state of the CPU and some data used by the current transaction before entering the clock interrupt each time. Then we enter the clock interrupt to perform time slice processing. If we find that a new and more urgent transaction time slice has arrived, we change the return address of the interrupt, restore the scene of this more urgent transaction in the CPU, and then return to the interrupt to start executing this more urgent transaction.

Benefits of Using an RTOS

The above paragraph may be difficult to understand for beginners.

In fact, this is because it is somewhat complicated and troublesome to implement this process. At this time, we need to find an operating system (OS) to help us do these things. If you can implement this process with code yourself, you are actually writing your own operating system.

In fact, it can be seen from here that the principle of the operating system is not so mysterious, but some details are difficult for you to do well. Our common RTOS is basically such an operating system, which can help you complete these things, and it helps you complete them very elegantly!

In fact, the usefulness of RTOS is far more than helping you complete the "transaction time slice processing". It can also help you handle various timeouts, perform memory management, complete communication between tasks, etc.

With RTOS, the program hierarchy is clearer and it is easier to add functions to the system. This is even more obvious in large projects!

丨The article is organized to spread relevant technologies, the copyright belongs to the original author丨

丨If there is any infringement, please contact us to delete丨

15537940969

Arteli 32-bit MCU, alternative