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

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.