How necessary is RTOS?

[Pack34]

I've been looking into this some and the main benefits on taking this kind of leap are:

- The illusion of multi-threading
- Task scheduling

However, these are very doable with the appropriate use of non-blocking state machines and the proper use of timers. It just seems like throwing RTOS into the mix is adding an additional layer of complication and consuming precious program space.

Or is there some specific DSP applications where it's crucially important?

Platforms in question: PIC18, PIC32, STM32

Regards,

[krish2487]

Short Answer : depends on the application


Long Answer : depends on the application. As you have said, simple multitasking is possible using timer triggers and non blocking state machines. However, thats not what RTOS are (only) used for achieving. RTOSes have a much complex design. They allow to facilitate interprocess communication, share a single stack, prempt other tasks from executing, allocate task priorities etc among many such features.


If you set out to achieve the same functionality set using state machines and timer triggers, you (almost) end up writing a RTOS skeleton framework.


It might seem like adding a layer of complexity but throwing in a RTOS, but it is actually more easier to scale number of tasks and allocate resources with an RTOS. As counter-intuitive as it may seem, RTOS actually take the focus off the underlying scheduler/MT/Stack management and help focus on the app development.


The same holds for any hardware platform, It is platform specific hardware like memory, ram etc that place a limit on the tasks.

[Mechanical Menace]

- The illusion of multi-threading

Not always an illusion, and the option to have the illusion can make it easier to port programs to other chips with little or no real porting work. If you think your code can't quite cut it on a single core device the RTOS will deal with MP scheduling and threading for you. If you think that you can get by with a single core device in a lower budget, less feature rich product that illusion can save you some headaches

But as said the added abstraction been useful depends on what you're trying to do.

[mazurov]

Platforms in question: PIC18, PIC32, STM32

I'm yet to see a good real-time framework capable of working well on PIC18. For PIC32, I have had good results with QP ( state-machine.com), it's not a RTOS but rather "state machines with event queues and timers"-type framework.

STM32 can run anything; it's not a matter of "which is better" but " which I'm most comfortable with". Some prefer RTOS, others like non-blocking.

[JohnnyBerg]

It depents on the application.

Try to toggle 2 outputs, one with a frequency of 997 hz and one at 1009 hz (997 and 1009 are both prime numbers) 

I consider the use of timers as a form of multitasking, so how to do it without timers?

[mikerj]

As your projects get larger and more complex, you end up spending a lot of time writing and debugging state machines, and trying to break up lengthy tasks in an efficient way. 

An RTOS allows you to spend more time developing the actual functionality of your application without all the messy state machine code.  You also gain a large library of useful functions such as queues, semaphores, mutexes, timers etc.

If you have never used an RTOS, the benefits seem dubious compared to the memory and cpu overhead, and it can seem a daunting task to start with.  Stupid flashing LED RTOS example code just makes RTOSs look ridiculously over-complicated and pointless, you need a reasonably complex project for them to show their benefits.  However, once you've grasped the concept and learn how to use them effectively they make a lot of sense.

As always, use the right tool for the job. Non-blocking state machines are often much more appropriate for simple applications, especially on 8 bit micros like the PIC18.

[KenGaler]

I find that an RTOS such as www.freertos.com is most useful when you get to the medium sized controllers such as the Atmel AT32 or the non-linux ARMs, for instance. 

[tggzzz]

In general, the same reasons you would use a database, or a known HLL, or an oscilloscope or spectrum analyser or off-the shelf MCU.

Depending on circumstances and scope...
Benefit: it can make your code simpler.
Benefit: many device libraries only work "inside" an RTOS.
Benefit: it allows you to concentrate on your value add.
Benefit: teaching the customer and/or maintenance team is cheaper and faster.
Benefit: finding an employee that wants to learn your code is more difficult.
Benefit: you don't poorly re-invent a wheel.

[zapta]

... share a single stack,...

How this is done? Don't you need to keep the context of each thread, including the content of its stack?

[tggzzz]

... share a single stack,...

How this is done? Don't you need to keep the context of each thread, including the content of its stack?

Depends on what you are prepared to give up. FreeRTOS's coroutines show one approach; see http://www.freertos.org/taskandcr.html and http://www.freertos.org/co-routine-limitations.html

[diyaudio]

I've been looking into this some and the main benefits on taking this kind of leap are:

- The illusion of multi-threading
- Task scheduling

However, these are very doable with the appropriate use of non-blocking state machines and the proper use of timers. It just seems like throwing RTOS into the mix is adding an additional layer of complication and consuming precious program space.

Or is there some specific DSP applications where it's crucially important?

Platforms in question: PIC18, PIC32, STM32

Regards,

I find RTOS development very clean, its not easy to debug similar to multi threaded development timing is harder to anticipate, what I don't understand is how each RTOS task is able to control its own stack, interesting... but opens up a new can of worms.. like how does two tasks communicate with each other and share memory?
 

[zapta]

... share a single stack,...

How this is done? Don't you need to keep the context of each thread, including the content of its stack?

Depends on what you are prepared to give up. FreeRTOS's coroutines show one approach; see http://www.freertos.org/taskandcr.html and http://www.freertos.org/co-routine-limitations.html

Thanks for the pointers.

If I got it correctly, you explicitly manage the states just like non blocked state machines and the RTOS does the scheduling of calling the functions. I wonder if it worth the extra complexity but I may give it a try, or write my own micro scheduler.

Is FreeRTOS free? Is it open source? Is it available for example for the NXP LPC11U35?

[tggzzz]

... share a single stack,...

How this is done? Don't you need to keep the context of each thread, including the content of its stack?

Depends on what you are prepared to give up. FreeRTOS's coroutines show one approach; see http://www.freertos.org/taskandcr.html and http://www.freertos.org/co-routine-limitations.html

Thanks for the pointers.

If I got it correctly, you explicitly manage the states just like non blocked state machines and the RTOS does the scheduling of calling the functions. I wonder if it worth the extra complexity but I may give it a try, or write my own micro scheduler.

I've written hard realtime systems in a co-routine style in C, and it was one way of expressing my code easily and simply and readable => easy maintenance. But, and it is a big but, each "co-routine" had its own stack and there was a tiny bit of assembler used to save/restore the registers.

I haven't used FreeRTOS but I'd be concerned that the "all-in-C" fetish would force me to produce contorted code, which would be bad news.

If there was a port of FreeRTOS to a machine that I was using, and peripherals were supported, then that would strongly bias me towards using it.

Is FreeRTOS free? Is it open source? Is it available for example for the NXP LPC11U35?

IIRC it is open source, plus there are paid-for versions that are supported and certified. Google is your friend.