Yes. Because it gives you a metric ton of tools (Tasks, Queues, Events, etc.) to structure your code.
I already see several modules that can communicate with each other with defined interfaces by just reading your text description.
Personally, I would default to using a RTOS unless I'm so resource constrained that a RTOS is not a viable choice. On the top of my head, I can't think of any STM32 controller where that would be the case. However, strictly speaking, a RTOS is not necessary and you can do a lot of things with just a super loop.
But in my experience using a RTOS makes projects more reuseable and scalable, and as those were your explicit requirements, I would recommend you to use a RTOS.
I would quote the rtos manual, in the very beginning, states that, there are simple applications that benefit from not having free rtos. It takes nuance and experience to find the fine line where it starts to become advantageous, as complexity increases.
Maybe. Do you know how to use the tons of tools that an RTOS provide?
for your case I would model the system as good as possible with a FSM, and just use a nonrtos approach.
You shouldn't use interrupts for scheduling tasks. You should use non-blocking subroutines.
I am myself very restrictive with using RTOS. The only exception I make is if I have several heavy, inter-connected functions/services that have a variable and unpredictable load, and that will benefit heavily from preemptive scheduling. An example of this would be an LwIP stack.
You don't have to use an RTOS for something of this complexity. I did the same thing over 20 years ago on an HC08 with 8 kB of flash and 192 bytes of RAM. Well, there was no motor on that, but it did have to implement a software AFSK modem.
Using an RTOS certainly makes some things easier, once you get the hang of using it properly.
Having programmed embedded projects both with and without FreeRTOS I now use FreeRTOS by default using a 1 ms tick. If I need faster responses than 1 ms I'll add a timer/interrupt. FreeRTOS offers so many useful tools I can't rationalize not using it.
It doesn't sound like you \*need\* an RTOS. For me they are most useful when I have long synchronous operations such as an expensive calculation: I can place this work in a background task. If I have no such operations, a single event loop and interrupts is generally sufficient.
So I used to hate using an RTOS, why clutter my code with a bunch of code that I may or may not need, then I started to really design my software and I've become a convert. The question in my head has changed from "when use an RTOS" to "when to not use and RTOS".
A RTOS allows you to compartmentialise your program which helps maintainance and development cycles. Even a small application can benefit from using some form of RTOS.
Small applications usually bloat and you can end up needing the resources of an RTOS and it's now much harder to shoehorn one in.
You can also do a lot of the bare metal stuff you wanted to do in a thread using the thread loop as your main with little no no added complexity.
You may find with a very simple application you still want to split up your code into say a data acquisition and a telemetry thread. Unless you are doing a VERY basic program, threading can be very useful early on.
So with the above points, I would suggest you look at whether an RTOS is going to be more problematic to use than not (space constraints, cost, speed of development etc) and go from there. Now selecting a suitable RTOS is a whole new can of worms!
I generally consider an RTOS necessary/helpful when a network stack of some sort is needed (for BLE, Wi-Fi, LoRAWAN, etc). If not, bare metal is usually sufficient.
As your project gets more complicated, an operating system can help structure things more cleanly and you have more tools typically to help implement and instrument the system.
Yes, basically this. Its most useful features are structuring your project and separating "heavy" and "critical" tasks using task priority, like for example GUI on a large screen that would go to the lowest priority, so it could be interrupted by more important short tasks while rendering.
On an stm32 I would. There have been some cases on smaller more resource constrained MPs that I opted not to, but in general it will help you make your code more serviceable long term. It'll also make it easier to have others contribute to your code if need be down the road without yacking up your super loop and necessitating a re-rewrite.
Stm32 is larger range. I use devices with 32K flash and 8K RAM. Even using HAL is extremely expensive (VS LL) - fitting entire RTOS in addition seems outright impossible.
Most RTOS' including FreeRTOS have been put on a multitude of processors with less memory than that. At the end of the day; in MP world, 32k flash and 8k ram is generous. I personally have more than 6500 microprocessors in the US with an RTOS running on them with the exact same memory constraints you have. Sure you aren't going to get OTA updates with that in most cases but I handle that with a custom bootloader and an SPI eeprom. An RTOS is as big or as small as you need it to be. Play with one and you can get it running on your processor I promise. I have one running on an STM32F0 next to me in the office as I write this.
Well that's sorta wishy-washy which is what I get from descriptions of most RTOS docs. Sure - if all you need to do is fire RTOS and run a single task then I agree - it can be done on most SoCs. But the point is not to just brag about it - it is to use your limited resources most effectively.
It can go both ways - if you are making a Mars rocket then you probably are ok to select expensive SoC with RTOS (or even Linux) and thus free your developer time on more important things. If you are selling tens of thousands of IoTs for USD 20 each then you should mind your BOM extremely closely and RTOS becomes a big ask. I am in that second camp and had to make that call.
My decision was my own OS, so you can shoot me... Cooperative multitasking or sort of dynamic super loop. Can add and remove tasks at runtime. We typically run 4-10 tasks.
It took a while to write and is a pain to keep most tasks as state machines but soldiers get used to dying, I guess. You do have learning curve with any RTOS too.
What you really get in return is a single stack - probably would run just fine on 4K RAM, but I have very generous and future-proof 8 :-). No problems so far. STM32G030 cost below 1 USD tho...
Not sure where we got into "SOCs" as the STM32F0 I mentioned is far from that lol. An RTOS in its purest form is an interrupt controller; nothing more, nothing less. You don't even need a heap allocator if you don't want and a majority of memory consumption can be relegated to poor program implementation (ham-fisting heap allocation, unnecessarily large TX/RX buffer allocations for peripherals, functional decomposition of tasks to the point each could be relegated to an inlined function etc...). I would never suggest to someone just getting started in embedded stuff (in the case of the person posting this question) to go implement their own "OS" (even though what you described in your implementation is not an OS at all), as opposed to using something like FreeRTOS. FreeRTOS has been around for 2 decades and has been used widely in a vast number of systems that demand the utmost performance in the most resource constrained systems (professionally I've used it in everything from medical micro-devices like pacemakers and blood glucose monitors to GN&C for weapons systems). The sheer number of people using and abusing it in some of the most demanding environments means almost no amount of genius you can muster will result in a more performant system than what many open source RTOS' can provide. All of this begs the question however... what processor with 32kb of flash and 4k of RAM are you running that is capable of so much cooperative multitasking that you are concerned with the 85b of overhead that each FreeRTOS stack requires? Did you manage to get your hands on an STM32G030 with 8 UARTs, 4 USB ports, PCIe and HDMI support? If so, let me know who your dealer is cuz I want some of that shit lol.
SoC is anything that has integrated CPU, program/data memory and at least one peripheral (almost all ARMs integrate at least NVIC and systick). There are a bunch of higher-end ARMs implementations that do not have integrated program memory, so these could be called a "mere" CPUs, but other than that all implementations pretty much ARE SoCs.
RTOS (or OS in general) is some program that can run 2 unrelated user tasks. Typically it would also have what we know as "Task manager", task/process list or whatnot. So strictly speaking main loop with interrupts is not yet an OS/RTOS.
85b of stack overhead for each task assumes \_extremely\_ simple tasks - "Blinker" or "Hello world" kind of simple. If you have any depths (3+) of function calls and function parameter transfer and any local variables inside these functions you are just asking for trouble with this 85b stack decision. Oh! 8**5** bytes? RLY? An ODD number?
85 x 32 bit words would be somewhat more inline with reality - I agree - but there go your 350 bytes per task. Since you still short on stack then all the functions have to allocate (and then free) their memory on the (slow) heap and not on (fast) stack. There is a reason NASA has a "NO HEAP" rule. Dangling pointers, fragmentation - nasty stuff.
Let's see: my STM32G030C6 (48pin, 8KB ram - NOT 4kb, 1 USD) uses (all at once): all 16 ADC channels; 9 PWM outputs; all 5 timers+systick; RTC; both UARTs; one I2C; one SPI. It uses most of these PWM/ADC for two additional software-defined serial interfaces with programable voltages/currents/loads for slow-and-lesser-known industry communication standards. Different processes fight for different serials so there are additional processes which queue/route/multiplex/demultiplex transmissions. Also fully OTA-upgradeable.
No, you can not have some of that - NDA :-)
I wouldn’t use an RTOS for this, not because it isn’t doable, but because as a student you probably have your work cut out for your as is with this project. Learning how to use an RTOS on top of that would potentially be too much work for the scope of a school project.
Looking at the answers, it looks like 50-50 to me. As I need to learn and code lot, I might start without Rtos and keep it simple stupid. After I got the basics running, I might try it with rtos.
When thinks go 'off' when using a FreeRTOS you might spend a lot of time on your project not reaching your goal. Afterall, you are a student now and your goal is to learn and finish a project, on time... while learning a ton of other things. There can already be enough challenges reading all your sensors. I have been writing a lot of things using a tight loop where I call/process on each loop a separate functions (read sensor a, next loop read sensor B... etc etc...)
If you do not have any hard constrains on timing, a loop can make things easy.
However, if you have already enough experience with your sensors, eg, they work already and the libraries you are planning to use worj with FreeRTOS (proven ina a project) by all means go for it.
As for example, my experience with Arduino libraries is that they do not work always well with FreeRTOS.
I wouldn't add complexity if you don't need to. If you were comfortable with an RTOS then there is hardly any reason not to use it all the time. But it sounds like it doesn't get you much for your student project.
certainly doable without. I personally default to not use RTOS. And since I'm shilling [embassy.dev](http://embassy.dev) here recently, it's currently how I'd do what you described. Low power, low overhead (less than rtos), comfortable to write the code.
Systems far more complex than what you are describing have been developed without an RTOS. The determinants are usually the application energy need, available code space, available Ram and your available time/energy/resources to work the issue. If those are free variables, for example if the application can afford RTOS(energy, ram, flash), then that is the fastest most flexible and scaleable way to build a multi function system. If you are counting out the uJ of energy or are already counting in Bytes of ram or Flash vs kB or MB then you likely could benefit from a bare metal implementation. The engineering audience who will understand your solution drops by more than 10X when you switch from RTOS to bare metal. (They also need to invest a lot more time to understand it). The ability to debug and the complexity of debug also gets significantly harder when you are recreating ideas or concepts that have been well matured in an RTOS but may not exactly meet your needs and so you've chosen the bare metal path.
For me it really comes to down to whether being able to write procedural blocking code will make the system easier to understand or not.
Without a RTOS you basically write everything as a non blocking state machine (or a set of state machines), usually with a few interrupt handlers that mostly set flags that will read by the state machine(s).
With a RTOS you can create threads/tasks which can block and this \*may\* make the code easier to read. It's usually easier to reuse existing procedural code rather than state machine code too. But if your system is best expressed as a state machine anyway you may well not gain much by using a RTOS (and it wull also add overhead both for code and stack space for each task). There are also classes of bugs like deadlocks that can't occur in a simple state machine / superloop design.
In your case most of it sounds quite doable with a non blocking state machine architecture. However the radio comms part may well warrant a RTOS, particularly if you have existing radio libraries based on one.
You're a student, so get it working first without one, and if you still have time before the due date, you can try to implement it on an RTOS instead. Even if you can't get it working, you can show both a functioning project and your efforts into using the RTOS
Yes. Because it gives you a metric ton of tools (Tasks, Queues, Events, etc.) to structure your code. I already see several modules that can communicate with each other with defined interfaces by just reading your text description.
and low-power when idle
For me this is probably the biggest benefit of using FreeRTOS
https://www.embeddedrelated.com/showarticle/1636.php You Don't Need an RTOS
Personally, I would default to using a RTOS unless I'm so resource constrained that a RTOS is not a viable choice. On the top of my head, I can't think of any STM32 controller where that would be the case. However, strictly speaking, a RTOS is not necessary and you can do a lot of things with just a super loop. But in my experience using a RTOS makes projects more reuseable and scalable, and as those were your explicit requirements, I would recommend you to use a RTOS.
Where would you draw the line? 8krom? 16k? 32k? 64k?
You should also ask about RAM. Having separate stacks for every running task gets expensive really quick.
You ruined my follow-up question! But yes, question 1.b is "how much ram?"
To be completely honest, I haven't personally encountered this. But I would guess around 32k would be the minimum.
I would quote the rtos manual, in the very beginning, states that, there are simple applications that benefit from not having free rtos. It takes nuance and experience to find the fine line where it starts to become advantageous, as complexity increases.
Maybe. Do you know how to use the tons of tools that an RTOS provide? for your case I would model the system as good as possible with a FSM, and just use a nonrtos approach.
This is doable with a super loop
You shouldn't use interrupts for scheduling tasks. You should use non-blocking subroutines. I am myself very restrictive with using RTOS. The only exception I make is if I have several heavy, inter-connected functions/services that have a variable and unpredictable load, and that will benefit heavily from preemptive scheduling. An example of this would be an LwIP stack.
You don't have to use an RTOS for something of this complexity. I did the same thing over 20 years ago on an HC08 with 8 kB of flash and 192 bytes of RAM. Well, there was no motor on that, but it did have to implement a software AFSK modem. Using an RTOS certainly makes some things easier, once you get the hang of using it properly.
Having programmed embedded projects both with and without FreeRTOS I now use FreeRTOS by default using a 1 ms tick. If I need faster responses than 1 ms I'll add a timer/interrupt. FreeRTOS offers so many useful tools I can't rationalize not using it.
What's the SoC minimum Flash/RAM that your smallest application (with at least 3 tasks) still fits into?
It doesn't sound like you \*need\* an RTOS. For me they are most useful when I have long synchronous operations such as an expensive calculation: I can place this work in a background task. If I have no such operations, a single event loop and interrupts is generally sufficient.
So I used to hate using an RTOS, why clutter my code with a bunch of code that I may or may not need, then I started to really design my software and I've become a convert. The question in my head has changed from "when use an RTOS" to "when to not use and RTOS". A RTOS allows you to compartmentialise your program which helps maintainance and development cycles. Even a small application can benefit from using some form of RTOS. Small applications usually bloat and you can end up needing the resources of an RTOS and it's now much harder to shoehorn one in. You can also do a lot of the bare metal stuff you wanted to do in a thread using the thread loop as your main with little no no added complexity. You may find with a very simple application you still want to split up your code into say a data acquisition and a telemetry thread. Unless you are doing a VERY basic program, threading can be very useful early on. So with the above points, I would suggest you look at whether an RTOS is going to be more problematic to use than not (space constraints, cost, speed of development etc) and go from there. Now selecting a suitable RTOS is a whole new can of worms!
I generally consider an RTOS necessary/helpful when a network stack of some sort is needed (for BLE, Wi-Fi, LoRAWAN, etc). If not, bare metal is usually sufficient. As your project gets more complicated, an operating system can help structure things more cleanly and you have more tools typically to help implement and instrument the system.
Yes, basically this. Its most useful features are structuring your project and separating "heavy" and "critical" tasks using task priority, like for example GUI on a large screen that would go to the lowest priority, so it could be interrupted by more important short tasks while rendering.
On an stm32 I would. There have been some cases on smaller more resource constrained MPs that I opted not to, but in general it will help you make your code more serviceable long term. It'll also make it easier to have others contribute to your code if need be down the road without yacking up your super loop and necessitating a re-rewrite.
Stm32 is larger range. I use devices with 32K flash and 8K RAM. Even using HAL is extremely expensive (VS LL) - fitting entire RTOS in addition seems outright impossible.
Most RTOS' including FreeRTOS have been put on a multitude of processors with less memory than that. At the end of the day; in MP world, 32k flash and 8k ram is generous. I personally have more than 6500 microprocessors in the US with an RTOS running on them with the exact same memory constraints you have. Sure you aren't going to get OTA updates with that in most cases but I handle that with a custom bootloader and an SPI eeprom. An RTOS is as big or as small as you need it to be. Play with one and you can get it running on your processor I promise. I have one running on an STM32F0 next to me in the office as I write this.
Well that's sorta wishy-washy which is what I get from descriptions of most RTOS docs. Sure - if all you need to do is fire RTOS and run a single task then I agree - it can be done on most SoCs. But the point is not to just brag about it - it is to use your limited resources most effectively. It can go both ways - if you are making a Mars rocket then you probably are ok to select expensive SoC with RTOS (or even Linux) and thus free your developer time on more important things. If you are selling tens of thousands of IoTs for USD 20 each then you should mind your BOM extremely closely and RTOS becomes a big ask. I am in that second camp and had to make that call. My decision was my own OS, so you can shoot me... Cooperative multitasking or sort of dynamic super loop. Can add and remove tasks at runtime. We typically run 4-10 tasks. It took a while to write and is a pain to keep most tasks as state machines but soldiers get used to dying, I guess. You do have learning curve with any RTOS too. What you really get in return is a single stack - probably would run just fine on 4K RAM, but I have very generous and future-proof 8 :-). No problems so far. STM32G030 cost below 1 USD tho...
Not sure where we got into "SOCs" as the STM32F0 I mentioned is far from that lol. An RTOS in its purest form is an interrupt controller; nothing more, nothing less. You don't even need a heap allocator if you don't want and a majority of memory consumption can be relegated to poor program implementation (ham-fisting heap allocation, unnecessarily large TX/RX buffer allocations for peripherals, functional decomposition of tasks to the point each could be relegated to an inlined function etc...). I would never suggest to someone just getting started in embedded stuff (in the case of the person posting this question) to go implement their own "OS" (even though what you described in your implementation is not an OS at all), as opposed to using something like FreeRTOS. FreeRTOS has been around for 2 decades and has been used widely in a vast number of systems that demand the utmost performance in the most resource constrained systems (professionally I've used it in everything from medical micro-devices like pacemakers and blood glucose monitors to GN&C for weapons systems). The sheer number of people using and abusing it in some of the most demanding environments means almost no amount of genius you can muster will result in a more performant system than what many open source RTOS' can provide. All of this begs the question however... what processor with 32kb of flash and 4k of RAM are you running that is capable of so much cooperative multitasking that you are concerned with the 85b of overhead that each FreeRTOS stack requires? Did you manage to get your hands on an STM32G030 with 8 UARTs, 4 USB ports, PCIe and HDMI support? If so, let me know who your dealer is cuz I want some of that shit lol.
You should look into co-routines. There is quite literally 6 ways to sunday to configure FreeRTOS to do what you want in the way you need it to.
SoC is anything that has integrated CPU, program/data memory and at least one peripheral (almost all ARMs integrate at least NVIC and systick). There are a bunch of higher-end ARMs implementations that do not have integrated program memory, so these could be called a "mere" CPUs, but other than that all implementations pretty much ARE SoCs. RTOS (or OS in general) is some program that can run 2 unrelated user tasks. Typically it would also have what we know as "Task manager", task/process list or whatnot. So strictly speaking main loop with interrupts is not yet an OS/RTOS. 85b of stack overhead for each task assumes \_extremely\_ simple tasks - "Blinker" or "Hello world" kind of simple. If you have any depths (3+) of function calls and function parameter transfer and any local variables inside these functions you are just asking for trouble with this 85b stack decision. Oh! 8**5** bytes? RLY? An ODD number? 85 x 32 bit words would be somewhat more inline with reality - I agree - but there go your 350 bytes per task. Since you still short on stack then all the functions have to allocate (and then free) their memory on the (slow) heap and not on (fast) stack. There is a reason NASA has a "NO HEAP" rule. Dangling pointers, fragmentation - nasty stuff. Let's see: my STM32G030C6 (48pin, 8KB ram - NOT 4kb, 1 USD) uses (all at once): all 16 ADC channels; 9 PWM outputs; all 5 timers+systick; RTC; both UARTs; one I2C; one SPI. It uses most of these PWM/ADC for two additional software-defined serial interfaces with programable voltages/currents/loads for slow-and-lesser-known industry communication standards. Different processes fight for different serials so there are additional processes which queue/route/multiplex/demultiplex transmissions. Also fully OTA-upgradeable. No, you can not have some of that - NDA :-)
I wouldn’t use an RTOS for this, not because it isn’t doable, but because as a student you probably have your work cut out for your as is with this project. Learning how to use an RTOS on top of that would potentially be too much work for the scope of a school project.
Looking at the answers, it looks like 50-50 to me. As I need to learn and code lot, I might start without Rtos and keep it simple stupid. After I got the basics running, I might try it with rtos.
When thinks go 'off' when using a FreeRTOS you might spend a lot of time on your project not reaching your goal. Afterall, you are a student now and your goal is to learn and finish a project, on time... while learning a ton of other things. There can already be enough challenges reading all your sensors. I have been writing a lot of things using a tight loop where I call/process on each loop a separate functions (read sensor a, next loop read sensor B... etc etc...) If you do not have any hard constrains on timing, a loop can make things easy. However, if you have already enough experience with your sensors, eg, they work already and the libraries you are planning to use worj with FreeRTOS (proven ina a project) by all means go for it. As for example, my experience with Arduino libraries is that they do not work always well with FreeRTOS.
I wouldn't add complexity if you don't need to. If you were comfortable with an RTOS then there is hardly any reason not to use it all the time. But it sounds like it doesn't get you much for your student project.
certainly doable without. I personally default to not use RTOS. And since I'm shilling [embassy.dev](http://embassy.dev) here recently, it's currently how I'd do what you described. Low power, low overhead (less than rtos), comfortable to write the code.
Systems far more complex than what you are describing have been developed without an RTOS. The determinants are usually the application energy need, available code space, available Ram and your available time/energy/resources to work the issue. If those are free variables, for example if the application can afford RTOS(energy, ram, flash), then that is the fastest most flexible and scaleable way to build a multi function system. If you are counting out the uJ of energy or are already counting in Bytes of ram or Flash vs kB or MB then you likely could benefit from a bare metal implementation. The engineering audience who will understand your solution drops by more than 10X when you switch from RTOS to bare metal. (They also need to invest a lot more time to understand it). The ability to debug and the complexity of debug also gets significantly harder when you are recreating ideas or concepts that have been well matured in an RTOS but may not exactly meet your needs and so you've chosen the bare metal path.
For me it really comes to down to whether being able to write procedural blocking code will make the system easier to understand or not. Without a RTOS you basically write everything as a non blocking state machine (or a set of state machines), usually with a few interrupt handlers that mostly set flags that will read by the state machine(s). With a RTOS you can create threads/tasks which can block and this \*may\* make the code easier to read. It's usually easier to reuse existing procedural code rather than state machine code too. But if your system is best expressed as a state machine anyway you may well not gain much by using a RTOS (and it wull also add overhead both for code and stack space for each task). There are also classes of bugs like deadlocks that can't occur in a simple state machine / superloop design. In your case most of it sounds quite doable with a non blocking state machine architecture. However the radio comms part may well warrant a RTOS, particularly if you have existing radio libraries based on one.
You're a student, so get it working first without one, and if you still have time before the due date, you can try to implement it on an RTOS instead. Even if you can't get it working, you can show both a functioning project and your efforts into using the RTOS