Why use FREERTOS instead of the interrupt mechanism on a microcontroller?

Question

This might be a very stupid question.

I have experience with embedded software on bare-metal and just started with FREERTOS. However I don't really understand why one would use FREERTOS instead of the built in interrupt mechanism. The goal of multitasking is to give the impression some sort of parallellization is going on on a single core (similar to multithreading). If you have a main function that is running specific functions continuously, next to this you can have different interrupt routines with different importance levels that can interrupt that main function and then return to the main function. With an embedded OS you have some task running and it then gets interrupted to run a task with a higher priority.

So far in my eyes the final result seems pretty similar, could someone correct me and/or give some more explanation?

"Interrupt mechanism" is by no means is a replacement for OS. OS is an abstraction layer above the bare metal hardware, which sometimes is simplifying the developers life. Sometimes not. If you don't understand why use it, then probably you don't need it. — Eugene Sh., Jul 08 '16 at 20:37
Because some people have more OS experience than bare metal experience. — Ignacio Vazquez-Abrams, Jul 08 '16 at 20:37
@EugeneSh. I have programmed microcontrollers for several years now, including multicore programming (since a few months). But still don't see why you'd need it. I hoped someone here could give me a very clear self-explanatory example where an embedded OS is really needed. "If you don't understand why use it, then probably you don't need it."A: I can't keep on being an ignorant about that topic, just because "I don't need it". — LandonZeKepitelOfGreytBritn, Jul 08 '16 at 20:40
@trilolil At some point an embedded system is becoming *very* complex, such that a single-threaded `while(1)` loop approach is not good anymore. Then you are writing a simple task scheduler. Then you discover that you need priorities for the task, and smarter scheduling. Also you have developed a bunch of HAL libraries at this point. And suddenly you discover that you want to run this program on different hardware. So you make it portable. And.. guess what? You have developed a simple OS. Now the question. Why? You have a ready made one containing this stuff. — Eugene Sh., Jul 08 '16 at 20:46
@EugeneSh. an example (eventually made up or whatever) where a single threaded while(1) loop is not good anymore would be very appreciated. :) — LandonZeKepitelOfGreytBritn, Jul 08 '16 at 20:48
@trilolil Well, even the most complex OS is the `while(1)` loop on the bottom. but as a simple example take task preemption mechanism. Assume that you have a low priority, but a heavy taks taking much time and a high priority realtime task. So the first task can run on the "background" yielding the execution to the second task whenever it is required. Can you *simply* achieve this with a while loop? no. But OS has it out of the box. — Eugene Sh., Jul 08 '16 at 21:01
If you use an OS or RTOS you are giving up some freedoms in exchange for background services, such as memory management, display drivers, USB and ethernet handlers,etc. At least an RTOS might offer a 1uS RTC when most offer only a 1mS RTC. — , Jul 08 '16 at 21:02
@EugeneSh. can't this simply be achieved with interrupts? Unless I misunderstood your example... — LandonZeKepitelOfGreytBritn, Jul 08 '16 at 21:06
@trilolil It *is* achieved with interrupts in the OS. But interrupts and the register-level programming is a rather low level for a complex software systems. OS is giving you a high abstraction level, providing different services and a certain level of portability. — Eugene Sh., Jul 08 '16 at 21:08
@Sparky256 interesting point. However I think all the points you just mentionned are things that are being taken care of by the kernel. So far I think you could just use a kernel, with preloaded drivers and eventually add your own drivers and finally use the kernels interrupt mechanism. So still no RTOS is needed as I see... — LandonZeKepitelOfGreytBritn, Jul 08 '16 at 21:08
@trilolil Are you aware that "kernel" *is* the core part of an OS? — Eugene Sh., Jul 08 '16 at 21:09
@EugeneSh. yes I am. You can have a kernel without an OS, but no OS without a kernel. If I am not mistaking — LandonZeKepitelOfGreytBritn, Jul 08 '16 at 21:11
You can't either. Kernel is an OS. The other parts are optional additions. — Eugene Sh., Jul 08 '16 at 21:12
If you need ethernet and a TCP/IP stack or a filesystem on a flash drive, you probably want to use an OS to get that stuff without having to write it yourself. — user57037, Jul 08 '16 at 21:34
Duplicate question as @SamGibson mentioned. Long stream of comments has yielded no answers or options. Vote to close. — , Jul 09 '16 at 03:32

score 7 · Accepted Answer · answered Jul 09 '16 at 12:07

You said, "the goal of multitasking is to give the impression some sort of parallellization is going on on a single core". That is way off the mark. I would say that the goal of multitasking is to divide a set of complex requirements into more manageable chunks while increasing the overall responsiveness of the system.

You might be able to achieve the first part of this goal using interrupts alone. But if you put an entire task's worth of functionality into an interrupt handler then you're going to worsen the system's responsiveness.

Imagine a monitoring device that:

continuously processes samples from an ADC connected to a sensor and performs some signal processing on the samples,
has a simple user interface with a display and a few buttons,
and has an Ethernet interface to communicate data on a network.

To do all of this from a main super-loop would make for a pretty complex super-loop. You could simplify the super-loop somewhat by moving functionality into interrupt handlers. But imagine if the ADC interrupt performs all the signal processing, the button interrupt performs all the display updates, and the Ethernet interrupt performs all the network message parsing. This system would not be very responsive because it's spending relatively long periods of time in interrupt handlers.

With an RTOS, you divide requirements into tasks making each task relatively simple to implement. Interrupt processing is kept to a minimum and the scheduler determines which task to execute. This can make for a highly responsive system. If you've designed the tasks smartly then it's also more robust and extensible than the complex super-loop.

You can have preemptive interrups mechanisms: problem solved. — LandonZeKepitelOfGreytBritn, Oct 22 '18 at 17:15

score 3 · Answer 2 · answered Jul 08 '16 at 22:47

Perhaps this comes down to a misunderstanding of what an RTOS is. There's no magic happening that you can not create yourself.

It does make a lot of things a lot easier though. Let's make up an example of a simple state machine that has to do different things depending on what has happened in the machine so far:

while(1) {
    switch( state ) {
        case 1:
            if( has_sample )
                fft_segment( sample_buffer, output );
            state++;
            break;
        case 2:
            if( has_packet )
                reply_to_packet( network_state );
            state++;
            break;
        case ...
    }
}

You don't want either of these running in an interrupt handler. fft_segment and reply_to_packet can potentially take some time.

Let's say that fft_segment takes a long time to run, and there's an incoming packet to reply to. It has to wait until your FFT is completed.

With an RTOS in place, you will run these in tasks with a different priority, and the OS can preempt fft_segment if necessary, to reply to the network request. This without blocking more important hardware interrupts.

Additional benefits are separation of code, which of course helps when your projects grow.

Nothing stops you from hacking this together "by hand", for example by splitting your heavy processing up in smaller parts that can run after each other, but with an RTOS you don't have to - it allows you to code in a way that's more natural.

I don't really understand why one would use FREERTOS instead of the built in interrupt mechanism.

You don't use it instead of the interrupts, you use it in addition to the interrupts. An RTOS gives you a more flexible way to manage priorities and different hardware.

The closest an RTOS comes to magic is that there are sections of some microcontroler documentation/training which are subtle or complex, and are really only relevant for people writing an RTOS. There is an assumption that if you need those features as an end product developer, you won't invent them yourself. — Sean Houlihane, Jul 09 '16 at 08:30

score 2 · Answer 3 · answered Jul 09 '16 at 10:09

This is from the FreeRTOS site itself: http://www.freertos.org/FAQWhat.html#WhyUseRTOS albeit a bit out of date.

Whether you can benefit from an RTOS or not depends on the size of your application and the requirements of your application - but that is stating the obvious.

Look beyond "trying to make things look like they are running in parallel" though - that is important for a multi-user system (like Unix) but almost irrelevant for a small dedicated system. What is more important is things like, how simple can I make my design, how maintainable can I make my design, what is the least amount of code I have to write to implement my requirements, how can I get as much functionality onto the smallest processor possible (correcting a misconception that appears time and time again, making your system completely event driven and never executing code [checking a state, polling an input, etc.] unless some processing actually needs to be done, means you can fit more functionality onto a processor when using an RTOS than when not), how can I have maximum responsiveness simultaneously with minimum power consumption ...... and so on.

score 0 · Answer 4 · answered Jul 08 '16 at 22:52

Yes an RTOS carries a lot of baggage, it is a lot of code that is not yours but will get you fired if it fails and you own the project. When you are able to manage the tasks without it, great, no problem. If you get to where your software is starting to resemble an rtos with the features you are needing to add, etc. There is a tipping point where you should consider trying the rtos to see what it does or doesnt give you. It is likely overkill but it may have many of the wheels you were re-inventing.

Obviously there is nothing in there you couldnt do on your own. Likewise all the chip resources and features are equally available to you as they are to the RTOS, priority interrupts if present, etc.

At the end of the day it comes down to personal preference.

Why use FREERTOS instead of the interrupt mechanism on a microcontroller?

4 Answers4