Let's Make Robots!

Picaxe M2 series 'multitasking'.

The M2 Picaxe series has multitasking (time slicing) to allow up to 4 tasks to run simultaneously which the manual says is to make monitoring switches and flashing LEDs etc, easier to program.  I was just wondering has anyone explored how far you can take the multiple tasks idea.  Has anyone, for example, tried controlling a servo, monitoring switches and varying PWM on a motor?

I've got a feeling that everything will get a bit glitchy, but perfectly happy to be proved wrong.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

this is some thing i could implement on scooder , i have not looked into it at grate length yet so ill get back to you as soon as i have a result 

NOTE im not holding my breath over PWM ."Time slicing"  sounds like it's messing withing the timer  ,but switches and LED's i don't think are going to be to much of a problem.

ok later reading manual time :)

it's not something i would use in a robot.

Parallel tasking is primarily designed for simpler educational projects. It works
very well using simple input/output commands and programs that contain pause
commands within the tasks. This covers the vast majority of school educational
Parallel tasking is not designed for complex parallel tasks with each task trying to
use different advanced features simultaneously e.g. trying to use serial / infra-red /
1-wire communication protocols simultaneously in 3 different tasks! In this
situation the end user should use a single core program to process each advanced
feature in turn.
Commands that require total core processing to maintain critical timing integrity
(e.g. readtemp, sertxd, debug, serin, irin etc.) will ‘block’ the parallel tasking until
that command has finished/timed out. Therefore the other tasks will appear to
momentarily ‘hang’ during the processing of that command.
Due to the task cycling the timing between each command in a particular task
cannot be guaranteed, because different length commands within the other tasks
will be processed in the interval. This also means that the accuracy of pause
commands will be slightly decreased. If a program specifically requires high
timing accuracy a single task should be used instead.
The ‘setfreq’ command is not available in parallel task programs, as the core will
automatically switch the frequency as required to maintain a high parallel task
processing speed. However most commands will ‘appear’ to be operating at
4MHz, so commands such as pulsout/pulsin, serout/serin, count etc. should be
calibrated as for 4MHz operation. Background servo pulsing will continue to
operate, but may have a decreased accuracy with occasional ‘twitches’. The change
in background frequency may also affect background pwm pulse generation, so it
is recommended that single task mode is used for programs containing pwmout
Processing multiple tasks is much more complex than a single task and so in
parallel task mode the core requires use of additional dedicated RAM memory.
Therefore, on the 18M2 in parallel task mode only, bytes 128 to 255 of the user
RAM are reserved as additional RAM for use by the core. Bytes 0-127 are still
available to the end user via peek/poke commands. In parallel task mode the byte
pointer (bptr) on the 18M2 will therefore overflow back to 0 after 127 (it
overflows at 255 in single task mode). This does not apply to other M2 chips (e.g.
14M2, 18M2+, 20M2) as the silicon of these later developed chips was designed
to include more RAM for this purpose. 

Aha - Manual 1.

I'm sure I didn't have that 'limitations' paragraph there before, even though I was up to date with the Programming Editor version. Looks like it's reading switches and flashing LEDs then #;¬)