Hi Bill,

I often do it the same way. However getElapsedSysTics() should check for
overflow of sysTICs, or you get the Windows98 feeling - complete system
freeze after 40 days ;-). May we can add it to the example/tasker? (maybe I
have some spare time the days until new year).

M.

On Fri, Dec 12, 2003 at 09:00:33AM -0600, Bill Knight wrote:
> I'm going to top post this because I want to keep the following
> response from Matthais but want to make a couple of short comments
> concerning the use of the cooperative tasker.
> 
> 1) it is possible to wait for an event in a task and still allow
> other tasks to run.  Use a construct like:
>   while (waiting for keystroke)
>     swap();
> 
> 2) I almost always do use timers with the tasker.  Typically I will
> setup the main counter so it rolls over about every 5mSec (you can
> choose your own value).  In the ISR for the rollover I increment a
> volatile uint16_t I call sysTICs.  Then I create a couple of timer
> handler functions; getSysTICs() returns the current value of sysTICs;
> uint16_t getElapsedSysTICs(uint16_t startTICs) returns the number of
> rollovers from startTICs to now (the current value of sysTICs).
>   These two functions can be used in a number of ways:
> a) int ch;
>    uint16_t startTICs = getSysTICs();
>    while ((ch = getKey()) < 0) &&
>           (getElaspedSysTICs(startTICS) < timeoutTICs))
>      swap();
> 
> b) void sleep(uint16_t duartionTICs)
>    { uint16_t startTICs = getSysTICs();
>      while (getElapsedTICs(startTICs) < durationTICs)
>        swap();
>    }
> 
> Several tasks can have different timeout timers active at the same
> time while only using the rollover interrupt from a single timer
> channel.
> 
> Regards
> -Bill Knight
> R O SoftWare
> 
> On Fri, 12 Dec 2003 15:37:00 +0100, Matthias Weingart wrote:
> 
> On Mon, Dec 08, 2003 at 11:45:16PM +0800, Steve Underwood wrote:
> > Hi all,
> > 
> > The tasker code in examples, is function but very basic. Oleg's SOS is 
> > rather more functional, but doesn't really address the needs of an 
> > MSP430 user - it does nothing about power management. 
> 
> Hi Steve,
> 
> I have analysed my code, and in most cases my routines are hanging around in
> sleep() or busy? statements, waiting for something to get ready. Most of
> that sleeps() are not time critical; it does not really matter if the sleep
> takes little longer than specified. Most of the time you have all your tasks
> sitting in sleep(); the CPU can switched off, until the time elapsed (or you
> got an interrupt, and there is some work for you tasks).
>  The cooperative multitasker is a good idea to use that idle time in other
> parts (tasks) of the firmware. The tasker has one advantage: it does not
> need any timer. Timers are a very rare ressource (I wished TI is spending
> more timers to their MSP's; timers should not need much silicon, why not 5
> timers?), but with a sleep() function (waiting at least xx ms), we need a
> piece of code that is executed periodically. The user of the OS should add
> this code to one of his timer interrupt routines. If no timer with a fixed
> timing is available, one can use a simple 555 like timer at 2 (or 1)
> interrupt port pins (slaa119). However, if you do not need sleeps() you can
> drop that code, and tasks are switched as long as there is not task ready 
> then it goes to LPM until the next interrupt.
>  Another advantage of the tasker is that the tasks are switched when
> everything in your task is finished and ready to switch to another task (no
> critical sections, no headache with hwmul).
>  Disadvantage of the cooperative tasker, however, is that you dead lock the
> OS if one task is blocking. You should never use while( busy ) statements,
> it should always be a while( busy and not timeout() ).
>  There should also be a possibility to get a task running immediately (wake
> up a task). Example: You get a ADC interrupt. All your tasks are sleeping.
> In the ADC interrupt you specify the task that is executed after RETI, and
> your ADC results are processed right away (the same implies for other tasks).
> 
> summary, extensions to tasker:
> - sleep(ms) (until time elapsed) 
> - sleepinfinitely() (until interrupt, until another task has finished)
> - timeout() 
> - code for a timer interrupt
> - some possibilities to prioritize tasks
> - if all tasks are sleeping switch to LPM
> 
> However this tasker would only work if all your tasks are sleeping
> periodically and you can broke your code in pieces that are shorter than
> your minimal timing requirements (e.g. ADC interrupt intervals).
> 
> Next point is non thread save code (e.g. access to hardware). With a
> cooperative multitasker, not thread save code is no problem, as long as it
> is not using sleep() itself (switching to other tasks), it does not use
> globals and you call it from only one task. But is this possible, really?
> Sometimes, maybe; then there should be a mechanism that could tell you that
> you do not call non thread save code from different tasks (is gcc able to list
> a call tree for all function calls?). Probably we need semaphores and events
> here.
> 
> I have written this from the view of a firmware programmer (not from the
> theoretical view of a OS programmer). Ok, lets compare my list with the
> features of SOS or uCOS. Oops, I think I reinvented the wheel. ;-) Make it
> sense to reinvent the wheel?  Maybe making it modular, let the coder 
> only use the parts he really needs...
> 
>         Matthias
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
        Matthias

Reply via email to