RTOS on picaxe

[QuIcK]

Heya,
I've done a bit of reading on this, and it seems like a very cool way of doing time critical processing...
does anyone have any good tutorials on how to go about an RTOS, or better yet, has anyone implemented one on a PICAXE (or even, can it?)

From what I understand it as, its a stack of procedures with a priority weighting on each procedure. theres an interrupt routine that fires every XXms, that then processes which procedure should get time allotted to it (the procedure can return stuff like PROCEDURE_COMPLETE if it completed all its calculations, PROCEDURE_MOREDATA if its waiting on, say, a reading, etc.). The higher the priority, the more it executes.

I recently did a volume controller for my studio, and retrospectively, i would have liked to implement this so volume fades are smooth, keystrokes arent missed etc. as it was, i struggled to get it to run fast (i got there tho)... perhaps an RTOS would have been more suitable so fading happens every 8 cycles, keystroke capture every 2 cycles (or less), and relay processing every 4 cycles

 

[KeithRB]

This is much more natural in a stack based computer. Since all variables are global you would have to be very careful to keep track of all the variables to avoid collisions.

There is also no way to return to a different routine after an interrupt.

 

[hippy]

You're really talking task scheduling rather than full RTOS but that it is at the core of any OS.

There are two types of scheduling "pre-emptive" and "co-operative".

Pre-emptive means being able to stop the task at any point, do something else then come back to it, much like interrupts. That's not really possible on a PICAXE because there's no simple way to stop a PICAXE program, know where it is, do something else, and come back to it apart from interrupt and that is only one level deep.

Co-operative means run to some point then stop, hand control back to the scheduler which runs something else, continue when it gets control again. That's much more feasible and can be done with a PICAXE, but the issues are speed of execution of each task and blocking commands, SERIN etc. If there are no commands blocking on input it should be possible.

The 18M2 does automatic round-robin scheduling which can be used for co-operative multi-tasking.

There are previous posts on multi-tasking and scheduling with a number of ideas there. How useful these are depends on what the overall requirements are.

A simple approach is to write your code linearly, each task as a separate subroutine. Each remembers their own state, either does something when entered and returns or simply returns if nothing to do. The scheduler is just a loop of Gosubs to each.

 

[QuIcK]

funnily enough hippy, that last suggestion is pretty much what i came up with, altho i dont think i actually realised it (until now).

I think i may have to check out the M2... DAC output & touch inputs. sweet!

 

[hippy]

All schedulers are extensions of the Gosub to Task basic loop, taking things out of the task to make it easier for the tasks to be written and making them more readable at the cost of increasing scheduler complexity.

Instead of the task checking "do I need to do anything?" when called, the scheduler checks before calling it, often adding an ability for tasks to have a 'temporary return, and next time continue at the line after', plus re-ordering tasks according to priority.

Let a clock interrupt handle all that and able to 'force the temporary return' and you've got pre-emption.

 

[geoff07]

Depending a bit on what you want to do, you might consider a state/machine structure. I have used this for real-time telepone exchange coding where it is very suitable for keeping track of complex ralationships (but not on Picaxe of course). I have posted a solar controller in the projects/misc section that uses this approach. It won't do true preemption, but adding an interrupt routine to update action flags and with the tasks broken down into bite-sized pieces you can easily create a simple real-time system. I'm currently working on a garage door controller that is monitoring motor rotation, limit switches, a light beam and command inputs whilst controlling the motor, various lights and alarms and an lcd, all with really quite simple and maintainable code. With a picaxe 28x2 at 32MHz you can have an idle loop running at well above 100Hz even with work to do. With the right use of interrupts, polling and flags you can make sure nothing is missed.