Need for an RTOS on an STM32?

Question

I am starting a project which uses LittleVGL as its GUI library.

I'm using an STM32H743, running at 480MHz. (It's rather over-powered, but only $1/15% more expensive than something half as fast with less RAM and flash, which would itself need external flash at additional cost.)

The worst case screen draw is 10ms. This will get considerably better when I implement LittleVGL's blitting and filling hooks with ChromART/DMA2D.

None of the board's non-GUI operations would suffer if delayed by up to 20ms.

If the screen drawing was slower, and needed to be interrupted by a more urgent operation, the need for an RTOS would be obvious.

Are there reasons to use an RTOS, rather than a single infinite loop, when all operations are quicker than the deadline of the most urgent?

(I am not familiar with FreeRTOS, and, most importantly, have no experience of debugging a FreeRTOS project.)

Answer 1

I start with picking the main question out of the question block:

Are there reasons to use an RTOS, rather than a single infinite loop, when all operations are quicker than the deadline of the most urgent?

Yes, there are. Most important of all: An RTOS is a means to partition a complex software into pieces that are easy (or even trivial!) to maintain. This partitioning considers the time a CPU spends on the present piece of software. You can apply it trivially whenever your software does several unrelated things on the same CPU/controller. I'd like to compare this to splitting up a big monolithic source code into small modules and functions that take care of a small fraction of the memory and program code. In contrast, each RTOS task takes care of one thing to be done by the controller firmware.

This was the trivial part of the reason, and I took the freedom to answer a bit imprecise to highlight the main point. Now for the less-trivial reasons:

Using an RTOS, you can also split parts of the software that do not run independently but represent different stages of processing from input data (measurements) to output data (set values). On a realistic embedded system, you often have to take care of so many requirements that implementing all in a single main loop would end up (or crash along the way) in some program code that you can write down once, but which you can hardly maintain (by fixing smaller and bigger bugs, by extending the software to some new ideas and requirments) if you return to the code more than a week later.

For me, the main motivation to use some RTOS (it doesn't have to be freertos, but that one isn't a bad start at all) in order to decompose a monolithic software into parts my head is able to handle.

Your question originally points to a different aspect:

I am starting a project which uses [...] GUI [...]

I'm using an STM32H743, running at 480MHz. (It's rather over-powered, but only $1/15% more expensive than something half as fast with less RAM and flash, which would itself need external flash at additional cost.)

The worst case screen draw is 10ms. [...] None of the [...] operations would suffer if delayed by up to 20ms.

If the screen drawing was slower, and needed to be interrupted by a more urgent operation, the need for an RTOS would be obvious.

You are right, another reason to use an RTOS is to interleave different processes on the system in a more or less dynamic way so that every task is finished before its deadline. I didn't investigate all the circumstances of your concrete case (see my elipses in the citation), but I feel convinced that this argument does not apply in your present situation. Just a few caveats to this perspective:

• You compare the end prices for single pieces of µC hardware, probably soldered to some ready-to-use eval board. This is a good idea, I'm doing the same for private projects. But as soon as you make professional embedded software for commercial products, you have to consider the price for multiple controllers (depending on your industry branch, some tens to some billions), and the price for the µC itself because it is soldered to a PCB that just fits the product you are programming. Then it might happen that nobody will grant you an STM32H7-something unless you really prove that this is the controller class you need to implement all the software requirements.

• You only described to us the screen/GUI driven by the STM32, but not the purpose of the screen. Usually, the device purpose implies some real-time requirements on the peripherals tied to the controller's I/O. Then, you may be forced to process some parts of your program with less latency than 10-20 ms. This leads you first to using interrupts, then (unless you want to handle every data transfer between contexts with lots of manual interrupt suppressions) to using an RTOS.

Maybe I am wrong, and you don't have any constraints to perform any reaction faster than 20 ms, or to replace the STM32H7 some day against a cheaper STM32. Then, the only argument that remains is handling complexity. Of course you can try to go on with a main loop. You will be successful as long as the requirements are simple enough that you can handle all with a kind of "all-in-my-head" architecture.

Credits to those who contributed parts of this answer in earlier comments: @Lundin, @Clifford