Electronics > Beginners
RTOS vs Superloop, when to use?
newbrain:
--- Quote from: rstofer on September 03, 2018, 02:17:18 am ---
--- Quote from: langwadt on September 02, 2018, 10:31:02 pm ---afaik Windows hasn't been cooperative multitasking since before win95
--- End quote ---
You are correct, they have changed to preemptive multitasking with the NT based kernels.
--- End quote ---
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:
--- Quote from: ogden on September 03, 2018, 07:35:46 am ---
--- Quote from: rstofer on September 02, 2018, 09:36:05 pm ---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.
--- End quote ---
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.
--- End quote ---
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.
--- Quote ---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?
--- End quote ---
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.
Navigation
[0] Message Index
[*] Previous page
Go to full version