RTOS vs Superloop, when to use?

[Muffins]

Hi Guys,

I have recently started down the train of learning about real time operating systems. I downloaded a port of ChibiOS to my arduino IDE and have been playing with that on an ATmege328p.

Anyway, I was wondering if superloops are actually used in consumer products and how I would determine if my program was reliable. In my mind RTOS is the way to go for making sure tasks play nice with one anther but at what point do I consider using it?

[rstofer]

Superloops work well when there is no time critical task.  They can still be pretty responsive if you only test for one, or a few, conditions during each pass.  Don't get hung up in a subtask.  No while(1) loops... They are simple to code, simple to debug and don't hide all the details in semaphores.

If there are critical tasks that can't be handled by a simple interrupt driven queue, an RTOS is the way to go.  The thing is, most programs can work with simple IO queues.  There is still a need for interrupts but there isn't a need for a scheduler.

Finally, anybody can code a Superloop.  It's not quite as easy to write for an RTOS and debugging can be a nightmare.  Things firing off willy-nilly can sometimes have interesting inter-reactions.

Don't take sides!  There is a time and place for both approaches.  It really comes down to the system requirements and the skill of the programmer.

Windows and Linux are hybrids.  Neither are real-time.  I don't know much about Linux but Windows is a cooperative multitasking system where tasks willing give up their slot on some condition preemptive multitasking system.  Works well!

[langwadt]

Superloops work well when there is no time critical task.  They can still be pretty responsive if you only test for one, or a few, conditions during each pass.  Don't get hung up in a subtask.  No while(1) loops... They are simple to code, simple to debug and don't hide all the details in semaphores.

If there are critical tasks that can't be handled by a simple interrupt driven queue, an RTOS is the way to go.  The thing is, most programs can work with simple IO queues.  There is still a need for interrupts but there isn't a need for a scheduler.

Finally, anybody can code a Superloop.  It's not quite as easy to write for an RTOS and debugging can be a nightmare.  Things firing off willy-nilly can sometimes have interesting inter-reactions.

Don't take sides!  There is a time and place for both approaches.  It really comes down to the system requirements and the skill of the programmer.

Windows and Linux are hybrids.  Neither are real-time.  I don't know much about Linux but Windows is a cooperative multitasking system where tasks willing give up their slot on some condition.  Works well!

afaik Windows hasn't been cooperative multitasking since before win95

[jmelson]

Windows and Linux are hybrids.  Neither are real-time.

Plain Linux is not real time, but there are several real time kernels that are built on Linux.  There are RTAI, Xenomai and RT-Preempt for the X86, and at least RT-Preempt for ARM.  Machinekit is a specialized RT system for CNC machine controllers, but it is a one-piece download that contains a complete Linux system with the RT-Preempt kernel for the BeagleBone Black.

Jon

[rstofer]

afaik Windows hasn't been cooperative multitasking since before win95

You are correct, they have changed to preemptive multitasking with the NT based kernels.

[rjp]

a truckload of things are variations on

wakeup, sample, display or send the sample, sleep.

the simple loop with blocking code tends to work fine for that common problem.

beyond that, you tend to want to avoid blocking and then an rtos or careful use of timers/interrupts is generally required.

[JS]

I've been using FreeRTOS, wanted to try Chibi but couldn't get it to fully work on stm and freertos comes in cube so dirt easy to set up for stm. I should try chibi for arduino, hadn't played attention to that combo.

Resources could be a big driver out of an rtos, sometimes you need to squeez a lot of data and have a program simple enough to run on it's own. Other times is too simple to put an rtos on top of it, it doesn't worth it and it's just a single task. Like using a micro to do a simple logic. Then, for any general purpose code, I include the RTOS.

Then deciding the type of system to use will depend on specific application, critical timing requirements, importance of priorities, etc. In the documentation for each rtos you will find some useful examples on how and why to choose each variant.

Windows [...]  Works well!

No it doesn't!

JS

[ogden]

Superloops work well when there is no time critical task.  They can still be pretty responsive if you only test for one, or a few, conditions during each pass.

I am afraid that you are associating superloop with polling processing of interrupts/events. Usual confusion which is not true. With superloop you can and shall run interrupt service routines. Properly designed  state-machine superloop with realtime code in the ISR can be as good as RTOS or even better - because superloop do not have RTOS (task switching and other) overheads.

Indeed there's always exceptions where one approach will perform better than another, but I believe that most up-to 16KB binary code projects can happily stay in the (properly designed) superloop. The bigger chips, the more code complexity and background tasks - the more you shall look into RTOS. Big superloop projects can become messy and hard to manage.

[Kjelt]

As stated above superloop and RTOS both have their merit and can be used both in most small embedded projects.
Where you might want to switch to an RTOS above a superloop is when you have a hard timeconstraint on your superloop cycle time,
AND have tasks that take more time than the cycle time allows.

Then you need to split that task up in more smaller tasks, use RMA analysis, a small statemachine handling the correct sequence etc. etc.
In that case when your superloop becomes more complex it is IMO preferred to switch to a proven RTOS since else you have to write,
parts of the RTOS yourself.
As a good rule, better re-use tested and proven open source software than write it yourself, this is esp. true for a more complex bigger software part like an RTOS.

[JPortici]

Anyway, I was wondering if superloops are actually used in consumer products

Yes they are.
a RTOS adds a lot of complexity and context switch can be a big hit, esp on small MCUs, but most tasks can be converted to finite state machines.
Example of "commercial superloop": Microchip Harmony. I don't use it, i do my own

[newbrain]

afaik Windows hasn't been cooperative multitasking since before win95

You are correct, they have changed to preemptive multitasking with the NT based kernels.

Actually, W95 itself used preemptive multitasking for 32 bit protected mode applications, and it did not have the NT based kernel.
I have since long misplaced my "Programming Windows 95" book, but I remember Charles Petzold making it a big deal (and rightly so, IMO).

[rstofer]

Superloops work well when there is no time critical task.  They can still be pretty responsive if you only test for one, or a few, conditions during each pass.

I am afraid that you are associating superloop with polling processing of interrupts/events. Usual confusion which is not true. With superloop you can and shall run interrupt service routines. Properly designed  state-machine superloop with realtime code in the ISR can be as good as RTOS or even better - because superloop do not have RTOS (task switching and other) overheads.

I thought I mentioned the obvious synchronization method of interrupt driven queues.  Obviously that also works for semaphores.  Something to tell the superloop that there is data available to process or a peripheral is ready for more data.  Sure, a lot can be processed in the interrupt handler but that doesn't get the effect noticed in the loop.  An example might be a command line handler.  The serial interrupt handler can build up a string of chars and even test that it is a valid sentence as it goes along but something has to tell the superloop that there is a command to process.  Or the command line parser could be called from the superloop and grab chars from a simple queue hooked to the serial interrupt handler.  Either way...

Interrupt routines need to be tight.  Get in, get it done and get out, time's wasting.  Same with the superloop, each pass should do as little as possible and not get hung up on some blocking task.  If there is a spin loop something is wrong with the code.

[iMo]

Chibios is fine-tuned and works best with STM32 mcus.  I did with stm32F4 in past and it worked fine. The fastest context switch, afaik. The author is an STM guy, btw.

In my mind RTOS is the way to go for making sure tasks play nice with one anther but at what point do I consider using it?

The beauty of an RTOS with MCUs is you can add the "tasks" into your system without a need to mess with the superloop timing. All your tasks are "independent" and can be scheduled to run "anytime" and use any available "resources anytime" (available means when the "resource" is not used by a different task - there are nice instruments to play with that).
At the end of the day you may "feel" each task lives its own life

Of course, when you start to dig deeper after some simple "blinking-like" examples you will certainly find the RTOS topic rather difficult. Therefore for smaller projects the superloop is still a good approach to follow.

[rstofer]

If there's a downside to RTOSes, it is the fact that there are hundreds or thousands of line of code you didn't write. Maybe the documentation matches the code, maybe it doesn't.  Maybe there are no glitches, maybe there are.  How do you know?  RTOS implementations are a little harder to debug.

FreeRTOS has been around for a very long time.  I would imagine that most of the glitches are resolved and I would expect the documentation to be quite good.  Other RTOSes?  Maybe I wouldn't trust them quite as much.

uC/OS has also been around for a very long time.  It isn't free and any time I have to contact the company to get a price, I realize I can't afford it.