Pros and Cons of Multi-tasking a Picaxe

I have an application which requires that a single chip do two separate tasks:

1) maintain very tight, continuous control of an integrator output

2) occasionally check an ADC input to see if the integrator needs to be adjusted and, if yes, to do some mathematical calculations on the input and make a correction to the integrator target output.

I was pretty excited when the multi-tasking chips came along because I thought it would be a piece of cake to assign the integrator to one task and all the 'overhead' to another task, and ordered some 20M2 chips to make that conversion.

But it seems that it ain't that straight forward. In multi-tasking mode, the setfreq command is taken off the table, and the chip seems to run at its default frequency. For me, this slows everything down, and the integrator, even in its own separate task environment, doesn't maintain as good control as it does when it shares resources with the other tasks in a 32MHz environment. In the single-task environment, I wrote the code so that the integrator runs exclusively until the output is 'perfect' then jumps to the other tasks, runs them once, then jumps right back to the integrator to make sure that it's output remains stable.

So, my question is: am I missing something and the multi-tasking approach really should work better, or have I simply discovered an unfortunate truth about the limitations of multi-tasking a picaxe chip?

Have you read through the parallel-tasking introduction section in part 1 of the PICAXE manual?

Although parallel tasks are possible and very useful in general situations, the PICAXE is still a 'single processing core' device and so can only do one thing at a time. So parallel tasks are shared in rotation by the processing core (at 16MHz) and so will never run as fast as a dedicated single task program. So, as in your case, if you want really high performance at 32MHz a single program task is the way to go (or a single task 20X2 at 64MHz?)

Thank you for the reply, yes, I had read that information. The part that I could not figure was, what happens to the clock? The explanation says it is managed by the firmware, but it doesn't say what the firmware does to it. Does the firmware turn it into a variable speed clock changing as required by the program, or is it in fact running at the default clock and no faster?

I was just checking to see if I'd missed something -- given my experience that multi-tasking is *very* noticeably slower, I thought it possible that I'd got something wrong.

Also I realize that the facts are the facts, but my curiosity drives me to wonder why the clock can't run at full speed in a multi-tasking system . . .

16MHz was chosen for the multi-tasking speed as it the most appropriate fastest speed that can keep all background features (such as time, servo etc etc) working correctly during multi-task programs.

Thank you, I'm glad to know that. It might be useful to others to put that one sentence into the manual.

Surely the execution speed depends on the number of tasks running. Running 2 tasks must be about 4 times faster than running all 8, I presume?

erco said:

Surely the execution speed depends on the number of tasks running. Running 2 tasks must be about 4 times faster than running all 8, I presume?

Click to expand...

Correct, the processor clock speed is 16MHz, but if you have 4 identical tasks running it will, in theory, take longer to cycle between each task (than if just 2 tasks were running). But most parallel tasks actually have idle time (e.g. during pauses) so if a task has a lot of pause idle time it does not really slow down the other tasks at all, as the pause does not take any processor use. It's all a balancing act and so you can never really say exactly what the 'operation' speed will be, as it depends on the commands used in each task.

Generally yes. The first program below toggles output 0 every 850us, while in the second ( with Task 1 suspended, and just Task 0 running ), toggling is every 440us.

Great info. Can you comment on the speed difference between these two programs, the first multitasking and the last one not?

Start0: Do : Toggle 0 : Loop
Start1: Do : Toggle 1 : Loop

and

Do : Toggle 0 : Toggle 1:Loop

For your application - one time critical task (integrator loop control) and one less critical (occasional ADC reads) I'd use an X2 Picaxe:

- set up a timer interrupt, the interrupt routine takes care of the critical task. This assures very steady control in regular intervals regardless of what the main program is doing (as long as you don't use some blocking commands like serin). At 64 MHz you can get up to ~1000 repeats per second (for a very short interrupt routine - less it the interrupt uses more time).

- in the main program, perform the less critical task

erco said:

Great info. Can you comment on the speed difference between these two programs, the first multitasking and the last one not?

Start0: Do : Toggle 0 : Loop
Start1: Do : Toggle 1 : Loop

and

Do : Toggle 0 : Toggle 1:Loop

Click to expand...

First toggles Pin 0 every 850us, the second at 16MHz, 350us

Thanks, more great info. Speaking of integrating, I want to do some dead reckoning navigation to keep track of robot position. I didn't see sin/cosine in the manual. Did I miss something?

erco said:

Thanks, more great info. Speaking of integrating, I want to do some dead reckoning navigation to keep track of robot position. I didn't see sin/cosine in the manual. Did I miss something?

Click to expand...

Please see M2, p.25 (Latest Manual)

Variables - Unary Mathematics

e

Thanks, I think...

X1/X2 only? Not even one of the latest M2 chips supports unary math?

Isn't that a giant step backwards?!

erco said:

Isn't that a giant step backwards?!

Click to expand...

Presumably its as a result of a compromise, so what features of the M2s should be removed to allow the Unary maths ?

erco said:

Thanks, more great info. Speaking of integrating, I want to do some dead reckoning navigation to keep track of robot position. I didn't see sin/cosine in the manual. Did I miss something?

Click to expand...

Out of interest how ?

I can see dead reconing working (for a short time) if you have accurate control and measurement over short distances, plus some method of (accurtatly) confirming direction of travel, but how in practice would this be achieved ?

You'd be surprised how well it works. Here's my first dead reckoning robot: http://www.youtube.com/watch?v=PX0IhUqnwrk