How necessary is RTOS? - Page 1
Forum section: electronics / general

author: Pack34
author_rank: Frequent Contributor
timestamp: April 20, 2015, 02:47:12 pm
content: I've been looking into this some and the main benefits on taking this kind of leap are:- The illusion of multi-threading- Task schedulingHowever, 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, STM32Regards,

author: krish2487
author_rank: Frequent Contributor
timestamp: April 20, 2015, 03:04:16 pm
content: Short Answer : depends on the applicationLong 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.

author: Mechanical Menace
author_rank: Super Contributor
timestamp: April 20, 2015, 03:26:31 pm
content: Quote from: Pack34 on April 20, 2015, 02:47:12 pmNot 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 headachesBut as said the added abstraction been useful depends on what you're trying to do.

author: mazurov
author_rank: Frequent Contributor
timestamp: April 20, 2015, 04:57:28 pm
content: Quote from: Pack34 on April 20, 2015, 02:47:12 pmI'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.

author: JohnnyBerg
author_rank: Frequent Contributor
timestamp: April 20, 2015, 05:02:09 pm
content: 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?

author: mikerj
author_rank: Super Contributor
timestamp: April 20, 2015, 05:11:08 pm
content: 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.

author: KenGaler
author_rank: Contributor
timestamp: April 29, 2015, 01:41:03 pm
content: I find that an RTOS such aswww.freertos.comis most useful when you get to the medium sized controllers such as the Atmel AT32 or the non-linux ARMs, for instance.

author: tggzzz
author_rank: Super Contributor
timestamp: April 29, 2015, 04:00:51 pm
content: 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 makeyourcode 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'tpoorlyre-invent a wheel.

author: zapta
author_rank: Super Contributor
timestamp: April 29, 2015, 04:14:24 pm
content: Quote from: krish2487 on April 20, 2015, 03:04:16 pmHow this is done? Don't you need to keep the context of each thread, including the content of its stack?

author: tggzzz
author_rank: Super Contributor
timestamp: April 29, 2015, 04:27:28 pm
content: Quote from: zapta on April 29, 2015, 04:14:24 pmDepends on what you are prepared to give up. FreeRTOS's coroutines show one approach; seehttp://www.freertos.org/taskandcr.htmlandhttp://www.freertos.org/co-routine-limitations.html

author: diyaudio
author_rank: Frequent Contributor
timestamp: April 29, 2015, 04:51:07 pm
content: Quote from: Pack34 on April 20, 2015, 02:47:12 pmI 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?

author: zapta
author_rank: Super Contributor
timestamp: April 29, 2015, 04:59:47 pm
content: Quote from: tggzzz on April 29, 2015, 04:27:28 pmThanks 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?

author: tggzzz
author_rank: Super Contributor
timestamp: April 29, 2015, 05:54:00 pm
content: Quote from: zapta on April 29, 2015, 04:59:47 pmI've written hard realtime systems in a co-routine style in C, and it wasoneway 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,andperipherals were supported, then that would strongly bias me towards using it.QuoteIIRC it is open source, plus there are paid-for versions that are supportedand certified. Google is your friend.