Pulling the threads……

Off my shirt till it looks better……….

Right, so umm. One of the reasons I moved onto stm32 hardware was that I read it had native threading support. Or software based threading.

So i could say run 2 functions at the same time (figuratively speaking), and in software the tasks are staggered to appear to run at the same time.

The reason I would like to do this is because on my speedo project I have 2 stepper motor dials and 2 led arrays that display MPH and RPM… Along with that I have a nextion display also dishing out information. Behind that I have maths calculating the rpm and mph… While I realise for the RPM and MPH to be calculated accurately I need to have there moments prioritised. So a few MS dedicated for them to do there thing so, At the beginning of the main loop these two will be called stacked on top of each other.

These generate a number and pass them onto the MPH and RPM display update functions.

This is where I need the threading to occur. I want the LEDs to animate to the position, not just jump, and the motors need to run there steps to the position too.

Im currently testing with 28BYJ-48 5v motors, this highlights the issue of waiting for tasks to complete before another thing can happen as theyre slow, but I will likely move onto those automotive gauge stepper motors actually used in dials… While they have little toque they requite less steps to get form A-B and give enough accuracy for this task.

While that would improve performance it still would generate a noticeable pause in the running of leds and other functions while each motor in turn updates on a regular basis. This would give a really jumpy and slow read out of the data.

So yeah, how do I call multiple threads? in VBA it was something like a DoWhile loop that would run tasks while still waiting for another task to complete.

Is it something as simple as ‘ callThreads(task1,task2,task3….) ‘ that would be nice

Nutsy wrote:One of the reasons I moved onto stm32 hardware was that I read it had native threading support.

Check out the Scheduler Library:

https://www.arduino.cc/en/Reference/Scheduler
https://www.arduino.cc/en/Tutorial/MultipleBlinks

Uses a cooperative multi-tasking model. Not preemptive.

-rick

http://playground.arduino.cc/Code/TaskScheduler
It even compiles straight on MMini – here is the Benchmark example:
Start...done.
Tstart =0
Tfinish=1740
Duration=1740

Thanks guys…
scheduler.h doesnt seem to work. Or at least I might be trying to use it wrong. While i get no compile errors, it seems that the only way to pass focus to a loop is to yield the main loop, which stops that and then goes to the next loop, then i can yeild that loop, which stops and goes onto the next, so on and so forth.

Trouble is thats not what im after. Unless its not running right on the Mini.

Thanks pito, ill try that one out now…

Have a look at ProtoThreads:
https://en.wikipedia.org/wiki/Protothreads
Extremely lightweight, portable standard C, and they can block.

Nutsy wrote:scheduler.h doesnt seem to work. Or at least I might be trying to use it wrong. While i get no compile errors, it seems that the only way to pass focus to a loop is to yield the main loop, which stops that and then goes to the next loop, then i can yeild that loop, which stops and goes onto the next, so on and so forth.

unaware of this thread, i’ve done something which could hardly be even called a ‘scheduler’
http://www.stm32duino.com/viewtopic.php?f=18&t=2117

there is yet another inspiring article ‘the one line rtos’
http://scitechconnect.elsevier.com/the-one-line-rtos/

i noted a big *difference* between this type of ‘run to completion’ scheduler vs conventional context switching rtos (e.g. FreeRTOS)
‘run to completion’ is nothing more than basic c functions or c++ methods. this means for instance that you want to blink a led
the concept change is literally between day and night.
to ‘blink the led’ you need to keep state transitions in global variables and draw up a finite state machine and to define how it would transit to the next state.

e.g. you can have the state [on] and [off], on transit to off after a number of ticks, off to on after another number of ticks, so you need a global (or instance) variable to keep the state and the ticks_count and u’d need to code the if-else transitions when the specific condition is met.
this is drastically different from while(1) { ledon(); delay(1000); ledoff(); delay(1000) }
there is no yield() etc in this context, the states and state transitions need to be explicitly defined and managed

just 2 cents

This is where I need the threading to occur.

you probably have a specific definition of “threading” that doesn’t apply to the hardware.

The way to go with your project is to decompose your tasks into a few chunks:

1) display: you can run them from an interrupt;
2) math: you can run them in the foreground;
3) motor: you can run then through an interrupt as well, or hardware, depending on your set-up.

Basically, your math calculation will come up with numbers for the display and actions for the motor. it should just put those numbers / actions in a buffer for the display and motor routines to access periodically through the interrupt.

Done.

You can also use multiple independent state machines for this (but I guess it results in basically the same thing)

if you favor an OS-like solution, you may want to check out protothreads, a macro-based framework that provides an “RTOS-like” feeling. it is basically a stylized state machine.