Software > Software

Scheduling cooperative tasks waiting on a delay.

<< < (2/4) > >>

obiwanjacobi:
Thank you very much for your answers but I get the distinct impression you are meaning something else with the term 'mulit-tasking' than I do. So lets call a separate execution flow that is managed by a scheduler a Thread and a logical piece of code (usually a class) that performs a specific operation or set of operations a Task. A multi-tasking system is NOT the same as a multi-threading system.

In a cooperative multi-tasking system all active tasks share the CPU time with each other and I cannot stop a Task from the outside. A Task can yield execution but does so willingly (hard-coded). So the cooperative nature is that all Tasks has to play nice together and there is no higher authority that can police the Tasks into behaving.

In such a scenario I don't see how a Timer/ISR would help, other than perhaps doing some background bookkeeping on what Task has the first upcoming delay time expiration. But that can also be done easy enough in the main loop.

So please tell me if I'm just not getting what you are trying to tell me or are we having some terms mixed up...?

paulstreats:
The reason I used timers and an ISR was so that tasks only run for a certain amount of time, they then yield for the next task and so on, until it comes back to the first task that resumes. It means that individual tasks dont need to be hardcoded to yield at any time, the processor timing unit and ISR handles it for you ensuring that each task gets the same amount of runtime and sharing the processors time equally.

 The only issue I have is the lack of ram to develop mine further, and the "book keeping" in the task scheduler becomes more and more complicated and is a fully time laden task in itself Popping and restoring the return stack, setting the program pointer etc... as well as building in fail safe stack checking to make sure errors and blank spaces are eliminated (if i remember, if a task is running and using the standard delay code, and its runtime has to yield, a blank space can occasionally appear where the program pointer should be so i just had to waste the time with loops. I would like to be able to setup a delay server to handle delays and allow other tasks to run instead of just wasting it though :))

 If you dont need such a complicated system, then a simple schedule list in the main function should work just aswell (mine was developed to handle dynamic tasks but if you know what tasks you need to run then theres no need for the complication).

 One way of handling the delays in the simp[lified system could still be done with the timer and an ISR, set the timer for the length of delay you require, store the position of the program counter and when the timer interrupt happens and the pointer jumps to the ISR, put the stored position on the top of the stack and return;

obiwanjacobi:
I explicitly do not want to go pre-emptive because I feel that it is overkill in the small MCU's my lib is targeting. The fact that you run out of RAM to develop it further is a sure sign (to me) that you're not on the the 'correct' (correct is a matter of setting goals) path.

I just posted the link to the mechanism I use for cooperative mult-tasking here: http://www.societyofrobots.com/robotforum/index.php?topic=16906.0

It consists of some macros that build up a switch statement that keeps track of where the Task was with executing its code.

I am currently experimenting with a simple (static) scheduler that keeps track of tasks in two lists (arrays): tasks that are running and tasks that are waiting. If I can get that to work - just wrote the pseudo code for it - it will do just fine.

paulstreats:
Definately, dont go too heavy with it. The simpler you can make it to do the job, the better. The more you incorporate into it, the more memory its going to need and also more time is needed to devote to housekeeping on the stacks, I developed mine for fun really and for the challenge rather than to be used in a specific application and I got a lot out of it in terms of understanding more about the program pointer, return stack, memory heap etc... as well as having all of the register loaded up on the simulator and watching pointers moving backwards and forwards. It really was just a learning experience and to be honest I would still like to develop it further but not until I have an ARM setup that I'm confident with and get on with the toolchain. There really is a limit to what can be done on small mcu's or especially those with limited clock speeds since housekeeping external ram would take up too much runtime to further develop the system (something that i did consider :D)

 But no carry on as you are, I'd love to see how you do eventually handle the efficient delays :)

obiwanjacobi:

--- Quote from: paulstreats on May 06, 2013, 05:59:33 AM --- [..] I'd love to see how you do eventually handle the efficient delays :)

--- End quote ---

Me too!  :o   :P

Navigation

[0] Message Index

[#] Next page

[*] Previous page