> -----Original Message-----
> From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On
Behalf
> Of Isaac Marino Bavaresco
> Sent: 26 May 2009 15:15
> To: Microcontroller discussion list - Public.
> Subject: RE: [EE] RTOS like this?
> 
> Michael Rigby-Jones escreveu:
> >
> >> -----Original Message-----
> >> From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On
> >>
> > Behalf
> >
> >> Of Isaac Marino Bavaresco
> >> Sent: 23 May 2009 01:03
> >> To: Microcontroller discussion list - Public.
> >> Subject: Re: [EE] RTOS like this?
> >>
> >>
> >> This is my proof of concept for a preemptive scheduler for PIC16
MCUs.
> >> Not quite working, but shows the concept (in MPLB-SIM).
> >>
> >> Sometimes one task gets "lost",  but the others keep taking rounds.
I
> >> think I will need to rewrite the scheduler (interrupt routine) in
> >> assembly for it to work correctly.
> >>
> >> The context is not saved/restored correctly yet (STATUS, FSR,
etc.),
> >> only the PC.
> >>
> >
> > Sorry to be a bit negative, but this only works as well as it does
> > because your tasks are so simple.  You are saving the return address
at
> > just one point in your task, yet the scheduler could interrupt it
> > anywhere.  Even if you added context saving this would never work
> > correctly with tasks that compiler to more than a couple of
> > instructions.
> >
> > Regards
> >
> > Mike
> >
> 
> If you analyze the macro Sw, you will see that the tasks may be
> interrupted only at specific points, just after the return address is
> saved.
> The tick interrupt stay disabled most of the time (the INTCON PIE bit
=
> register 0x0b, bit 6), and is only enabled for one instruction cycle
> each time the macro is invoked (bsf 0x0b,6/bcf 0x0b,6).
> 
> Some people discussed here if it is preemptive or not (theoretically,
> before I wrote the code). I think it is something in-between
preemptive
> and collaborative.
> Preemption may happen just at specific points (when the macro is
> called), but only if the tick has elapsed, unlike a "Yield" that
forces
> a switch every time it is called.

I see, I didn't realise that you intended placing multiple calls to the
Sw macro within a task.  If I understand correctly, your scheme forces a
task to run for a minimum amount of time, i.e. the first Sw() that is
encountered AFTER this period will force a context switch?

Seems you could add similar functionality to a purely cooperative system
by checking if enough time had elapsed within the "yield" macro prior to
saving context and jumping to the next task?  

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist