[PORTED] TaskScheduler

MoDu
Tue Nov 27, 2018 3:54 pm
Cooperative multitasking for Arduino microcontrollers
https://github.com/arkhipenko/TaskScheduler

I’ve been using this fine and light cooperative scheduler for a while on STM32, but the author has (under my annoying nudging) added support for the little blue pill.

v3.0.2:
2018-11-11:
Support for STM32F1 boards (including IDLE Sleep)

I personally use OOP option almost exclusively, and the idle sleep functionality is just free real estate :mrgreen: !

Just thought I’d share, especially after this lovely topic.


ag123
Tue Nov 27, 2018 5:31 pm
+1 :D

zoomx
Wed Nov 28, 2018 1:25 pm
+1

mrburnette
Wed Nov 28, 2018 4:56 pm
Multi-tasking works better when there are multiple cpu. Otherwise, it is all largely unnecessary overhead for pseudo-threads, locks, and loopy-loops. Time is better spent on understanding the software “system” and creating efficient callbacks.

I understand that programmers think it is neat to do this on a cheap uC, but in most software designs it is unnecessary and just an excuse to not observe good software architecture and proper function/class designs.

On a chip like ESP32 under Arduino, the core designers have already done the API using FreeRTOS.

It is a cruel, cold world and IMO there are bigger mountains to climb than rolling my own pseudo-threads and ‘tos. I say, use the uC for realtime use in a tight loop, shake & repeat. Move up to a multicore uC for threading or to hardware like a RPi with a Linux OS for max flexibility.

Ray


C_D
Wed Nov 28, 2018 9:14 pm
Ray, is that comment for or against TaskScheduler?

I too use this library a lot and I think its a very easy and neat way to synchronise multiple tasks without the almost always unnecessary overhead of an RTOS.


mrburnette
Thu Nov 29, 2018 12:21 am
[C_D – Wed Nov 28, 2018 9:14 pm] –
Ray, is that comment for or against TaskScheduler?

I too use this library a lot and I think its a very easy and neat way to synchronise multiple tasks without the almost always unnecessary overhead of an RTOS.

Task scheduling on a single-core uC implies thread scheduling. There are reasons that RTOS were developed. But their use is the exception and not the norm.

Scheduling does not represent load balancing. Pseudo-threading does not represent work optimization. Implementing resource contention can create memory stress as the uC has no OS to dynamically pool real memory with virtual memory.

Programmers who understand the tools know when to use them… my comments are for new to intermediate coders – these are not everyday use concepts just because the examples often demonstrate blinking multiple LEDs.

Ray


MoDu
Thu Nov 29, 2018 10:54 am
I’m gonna have to support Ray on this one.

From my own personal context, I know how to use a cooperative-scheduler: I design all running tasks as state machines and never ever spend more than 500 micros on each task, along with a few more minor restrictions and design implications.

A noobie will try this and think he can just throw pseudo-threads at everything, and then wonder why all the timings are so off.

TL;DR: context is always important.


mrburnette
Thu Nov 29, 2018 12:31 pm
[MoDu – Thu Nov 29, 2018 10:54 am] –
I’m gonna have to support Ray on this one.

GeeWhiz… you do not have to sound so disappointed in your support. ;)

Ray


MoDu
Thu Nov 29, 2018 12:51 pm
You are the cold water we need, when we start running around with enthusiasm for the shiny new toys. :mrgreen:

mrburnette
Thu Nov 29, 2018 1:12 pm
[MoDu – Thu Nov 29, 2018 12:51 pm] –
You are the cold water we need, when we start running around with enthusiasm for the shiny new toys. :mrgreen:

Programming is often referred to as an “art” and hence the programmer is the artist. As such our toolbox is not filled with pigments and brushes but rather languages and techniques and structures. But we all need to study the masters to appreciate the possibilities and must strive to develop our own style.

It is not a desire to wring every cycle out of a uC. Rather, the goal is to create functioning software to run as the requirements demand. I find it helps to write the requirements on paper and refer to the goal often.

If we use a $2 uC to blink a LED, then perhaps we should have used a 555. But, it we use a thermistor to measure resistance as a function of temperature, calculate in the uC, and blink a LED if the temperature is out-of-bounds, then that $2 may be well spent even if only 5% of the capability is utilized. We may throw in a display using SPI or I2C and consume another 5%. $2 well spent and there is no need to fret about only 10% resource utilization. There are some mentalities however that would see a $1.80 loss.

Ray


ag123
Fri Nov 30, 2018 5:32 am
strictly speaking it isn’t really about ‘multi tasking’ that i find myself using such ‘co-operative’ scheduler including my own event loop

my guess is that it is quite common to want to drive an LCD present a (simple) gui, respond to inputs e.g. button presses etc, monitor sensors or adc, drive the beeper (a timer & tone() does it) and if that is not all sometimes one may want to drive a sd card all in that 20k sram
i tried RTOS and i found the use of vtasks fragment that 20k memory so much that it quickly runs out of memory on bp/mm.

to better manage memory use around the different tasks, the simplest way to manage ‘dynamic’ memory is simply use the *stack*, c, c++ supports that natively, all local variables are placed on the stack and unwound when the function exits.

in a way a ‘scheduler’ isn’t necessary as one could simply call one function/method after another in loop().
the notion of using a ‘scheduler’ and in my case i used an event loop is that delay() blocks.
so one would need to maintain the state to do a non-blocking delay.
and this is a rather common use case e.g. to blink the led while doing ‘other things’.
to simplify the use case, i used an event loop with a AsyncWait class that fires events at a later time after a delay and it turns out the concept works well on the bp/mm
it makes the pieces work together like a game console and becomes pretty responsive / interactive


ag123
Fri Nov 30, 2018 6:04 am
in the recent decades there has been ‘technology shifts’ / breakthroughs, the most notable being
[*] digital cameras – almost killed flim
[*] smartphones – killed the palm pilot
[*] android and iphone – nearly wiped out old push button phones

arduino? stm32duino?
this is a breakthrough of sorts, that old mcu in that old nokia phone comes out as commodity hardware distributed as development boards, sensors / parts as breakout modules
where is the breakthrough? you don’t normally hack your old nokia phone to drive a led, but now that the mcu become widely distributed as development boards, and detailed specs published something once deemed ‘impossible’ become common: you could program that old nokia phone mcu to drive breakout modules in your own custom use case – deemed IOT

i think stm32 and cortex-m is an evolution from the old ‘nokia phones’ mcus


mrburnette
Fri Nov 30, 2018 3:20 pm
[ag123 – Fri Nov 30, 2018 6:04 am] –

i think stm32 and cortex-m is an evolution from the old ‘nokia phones’ mcus

Disagree.

Raspberry Pi is an evolution from mobile tech.

The STM32F1xx is just a common old ARM uC. Nice, well designed, inexpensive, but dated.

Ray


ag123
Fri Nov 30, 2018 4:52 pm
at the moment it seemed arm development is still evolving along 2 separate tracks
some of those A64 development boards are going 64 bits quad core with big.little setups, i’m not too sure if the cutting-edge 8 cores ones are out as development boards as well. but the point is that it seemed like a massive overkill if a 8 core 64 bits 2ghz boards perhaps designed with gigabytes of memory is just used to blink a led

cortex-m still has it place as for now, the problem with IO is that it is a ‘waste of hardware real estate’ but one which couldn’t be avoided.
for instance a large size full 104 keys ansi keyboard uses a huge PCB and is pretty much ‘wasted space’ with lots of thin wires on the pcb, imagine the amount of copper that needs to be etched away. but the fact is that you simply can’t squeeze a keyboard into 1/10 its size and still have it being usable (by humans)
:lol:


Leave a Reply

Your email address will not be published. Required fields are marked *