Is it really necessary a RTOS?

[ennioaloisini]

Hi all,

I write to you because I would like to understand if it is really necessary to use an RTOS. I always develop projects with different ST processors (F4 and F7) without using RTOS. In those projects the F4/F7 processors communicate with many hardware components using SPI, I2C, RS232, GPIO and PWM. Now I need to increase the communication speed on the RS232, because I need do send few mega bytes of data every second and for that reason I need to integrate the USB with Full Speed or High Speed. Then in another new project I have to handle also a small OLED display. For all these reasons I'm thinking about the possibility to use Azure RTOS that seems well integrated with CubeMX, but I do not know which benefits I could obtain and if I could have some side effects both from performance point of view and also from developing time point of view.

In this situation is it really necessary a RTOS?

Which advantages and disadvantages could I have using a RTOS? 

Let me know!

Thank you very much for the support.

[ennioaloisini]

Basically start to use an RTOS could be an advantage when the program becames too complex and in my situation it is quite complex... it could be an opportunity to make this jump.

Thank you very much for the support.

[Tesla DeLorean]

The UART on most of the STM32 can support rates of a few Mbps, usable for things like HSPA/4G modems.

RTOS aren't needed.

USB expects some amount of concurrent operation, pumping the foreground tasks, see while() loops often used in main(). There are other ways to pump operation, and most time critical stuff is handled in interrupts, but other data buffer management typically needs to occur under a secondary "task" or periodic processing.

Done many things here processing data, running a radio, multiple UART, and SSD1309 OLED, without any RTOS

[Andrei Chichak · Accepted solution]

The rules of thumb that I (and other people in the embedded community) use is, if you have some sort of communications protocol going, use an RTOS. If you're doing graphics, use an RTOS.

Once you get a bunch of experience, you'll think "this customer really has no idea of the scope of this project and it's going to balloon in scope really soon now", use an RTOS.

But you could also not use an RTOS, add a feature here, another device there, rebalance the timing due to coupling that wasn't intended, decide that you need just a little bit of a kind of a scheduler looking thing, and suddenly you've written a feature poor RTOS and you say "I should have used an RTOS".

I tend to use an RTOS unless I can see that the project is going to be well bounded, small, and heavily constrained.

The amount of effort that goes into writing code goes exponential with complexity. So if you can break up your code into multiple simple cooperating tasks, you avoid complexity and avoid having your system have exponential effort growth. I've done this by using multiple processors, each running small simple programs. But you get the same effect from using an RTOS. Each task/thread/process is simple, well defined, and small, avoiding ballooning complexity.

Recently I read an article about the software architectures that actually work for multi-processor, high scalability, high performance systems. It pretty much came down to small processes and message passing. Lots and lots of message passing. 

So, you can get experience in non-embedded best practices and avoid driving yourself crazy by using RTOS'

[Tesla DeLorean]

People who can only think linearly, and have a hard time thinking concurrently, should probably use an RTOS.

It does off-load a lot of complexity, but it does bring with it a different set of issues.

It hides Time from the problem, but it won't stop you from hitting bandwidth limitations if you always take longer to process the data than the rate it arrives.

[Andrei Chichak]

So what you're saying is "it's not for me, your milage may vary"?

(or is your intent to insult?)

[unsigned_char_array]

---

@ennioaloisini wrote:

Hi @unsigned_char_array 

thank you very much for the feedback.

In one project I just need to change the RS232 with USB and maybe it could be more conveient to do not use an RTOS, but in another one I will have to handle a small OLED with a TouchGFX application and in that case I think that it could be better to use an RTOS. Is it correct?

Let me know!

Thank you very much for the support.

---

In your case I would recommend an RTOS such as FreeRTOS. It may not be needed, but it makes it easier. I currently have a large project with TouchGFX and USB and use it without an RTOS, but we have calculated and measured the CPU load and timing. We also rewrote the USB library to remove busy waiting and optimize it more. At my current job part of our coding standard is to avoid an RTOS unless it is really needed. This way we avoid things like stack overflow and since we run most things in one loop it reduces most problems with concurrency and synchronization. But RTOS is also easy (just make stack size large enough) and it's ok to be a bit lazy.
Regardless I still recommend you at least measure the CPU load by toggling some IO pins in certain parts of the code. This helps you find bottlenecks early on in development instead of surprises when you want to deliver the project.

[ennioaloisini]

Hi @unsigned_char_array 

thank you very much for the feedback.

Regarding the measure of the CPU load, do you mean to toogle a LED during all the application and see if in some situation it decreases its speed?

Regarding the possibility to integrate a GUI made with TouchGFX, Crank Software Storyboard or Embedded Wizard, is it possible to integrate it without using a RTOS?

Let me know!

Thank you very much for the support.

[LCE]

Question concerning the OS supported by ST:

Do they come with the hardware / peripheral drivers?

If yes, do they use the HAL libraries "underneath" ?

If yes, then for me this would be the reason to NOT use an OS.

[unsigned_char_array]

---

@ennioaloisini wrote:

Hi @unsigned_char_array 

Regarding the measure of the CPU load, do you mean to toogle a LED during all the application and see if in some situation it decreases its speed?

---

No. Things go to fast to see with your naked eyes. I mean setting and clearing GPIO pins in certain parts of the loop (or in certain threads if you use an RTOS) and in interrupts. And then connecting those to a logic analyzer to measure the timing. For TouchGFX there is an example: https://support.touchgfx.com/docs/development/touchgfx-hal-development/scenarios/scenarios-measure-performance . You can expand that for other processes you have and see if everything gets enough CPU time and nothing is blocking too long.

[unsigned_char_array]

---

@LCE wrote:

Question concerning the OS supported by ST:

Do they come with the hardware / peripheral drivers?

If yes, do they use the HAL libraries "underneath" ?

If yes, then for me this would be the reason to NOT use an OS.

---

FreeRTOS is just a software threading library that compiles with your code. It manages switching stacks when switching between threads and it also handles timers and communication/synchronization between threads. The only hardware it uses is the systick timer. You can use the HAL functions in your threads just like you would in a loop, just avoid accessing the same peripheral from different threads.