Page 1 of 1

Cyclical Timers and micro resets

PostPosted: Mon Sep 04, 2006 1:35 am
by lawberman
My IAR MSP430 resets if I call OSResetCycTmr from inside the Cyclical Timer routine itself. Why is this?

I also note that OSSetCycTmrPeriod does not check if the period is zero. Calling it with a period of zero also causes a reset.



Re: Cyclical Timers and micro resets

PostPosted: Mon Sep 04, 2006 9:35 am
by aek
Thanks for this post.

1) None of Salvo's cyclic timer services are intended to be used within the associated cyclic timer functions themselves, and currently do not support such an operation (e.g. destroying a cyclic timer from within the cyclic timer itself). Admittedly, this is not obvious from the Salvo documentation.

2) Yes, the zero-check should be performed. I've added it to OSSetCycTmrPeriod() when OSENABLE_ERROR_CHECKING is TRUE.

------------------


Re: Cyclical Timers and micro resets

PostPosted: Mon Sep 04, 2006 9:45 am
by aek
See also SB-29.

------------------


Re: Cyclical Timers and micro resets

PostPosted: Mon Sep 04, 2006 10:53 am
by lawberman
Thanks for your reply.
Out of interest, is the Cyclical Timer routine run in the background or foreground?
If in the background, would creating a large number of timers cause degradation of timing?

Re: Cyclical Timers and micro resets

PostPosted: Tue Sep 05, 2006 7:31 am
by aek
Cyclic timers are run in the background. They are "dispatched" from inside the scheduler, but instead of a call-by-pointer to a task (which then returns to the scheduler via a context switch), cyclic timers are simply functions that are called via pointer from inside the scheduler.

Define "degradation of timing".

------------------


Re: Cyclical Timers and micro resets

PostPosted: Tue Sep 05, 2006 9:53 am
by lawberman
Thanks for your reply.
What I meant was that if the cyclical timer functions are run from the background, would the periodicity of the timers be affected by how many timers are being used.ie the more timers, the less accurate the periodicity.

Re: Cyclical Timers and micro resets

PostPosted: Tue Sep 05, 2006 10:16 am
by aek
You would never notice any difference.

Salvo's timer-based functions are extremely efficient at runtime. They trade a little more work up-front (e.g. when a task is delayed via OS_Delay()) for an extremely fast OSTimer(), independent of how many timers (in this case, delayed tasks, task waiting with timeouts, and cyclic timers) are currently active.

The one place where you could conceivably see a slowdown is if you have a whole bunch of delays that all run synchronously -- i.e. they all time out together in the same system tick. But even then you'd have to have huge numbers to make any difference.

Also, Salvo keeps track of "lost ticks". Those are ticks that occur when OSSched() is prevented from running (e.g. if you have a background process that does not yield for longer than a system tick). The "lost ticks" are recorded, and the timers will catch up to the proper current time as soon as OSSched() runs.

This timer functionality is quite different from many other RTOSes, which carry large arrays of timers and have to service all active timers on every system tick.. Salvo only has to service one timer per tick, regardless of how many are active.

------------------

[This message has been edited by aek (edited September 05, 2006).]