5
\$\begingroup\$

This question already has an answer here:

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?

\$\endgroup\$

marked as duplicate by Sparky256, Anindo Ghosh, Blup1980, Peter Smith, uint128_t Jul 9 '16 at 18:51

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 3
    \$\begingroup\$ "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. \$\endgroup\$ – Eugene Sh. Jul 8 '16 at 20:37
  • 2
    \$\begingroup\$ @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. \$\endgroup\$ – Eugene Sh. Jul 8 '16 at 20:46
  • 1
    \$\begingroup\$ @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. \$\endgroup\$ – Eugene Sh. Jul 8 '16 at 21:01
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ – Sparky256 Jul 8 '16 at 21:02
  • 2
    \$\begingroup\$ You can't either. Kernel is an OS. The other parts are optional additions. \$\endgroup\$ – Eugene Sh. Jul 8 '16 at 21:12
6
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ You can have preemptive interrups mechanisms: problem solved. \$\endgroup\$ – LandonZeKepitelOfGreytBritn Oct 22 '18 at 17:15
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ 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. \$\endgroup\$ – Sean Houlihane Jul 9 '16 at 8:30
2
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.