[ECOS] ecos idle function--A correction and clarification.

Milind Kopikare milindkopi@yahoo.com
Tue Jan 21 19:24:00 GMT 2003

Thanks Andrew! I guess another workaround could also
be that we run teh calibration for a longer time, say
100ms. Then the error will be at worst only 1%.
Ofcourse, later we will be sampling every 100ms and
will have to account for the fact that the calibrated
value was for 1000ms.
Lemme know if you feel there is a flaw in this.

Thanks again,

--- Andrew Lunn <andrew.lunn@ascom.ch> wrote:
> >     But as a sequel, I would like to know why
> > sometimes, the idle_loops can turn out to be more
> than
> > the calibration. in other words, when we
> calibrate, we
> > only allow the idle_thread_main function to run
> with
> > the highest priority. Hence whatever value is
> recorded
> > for those 100ms by idle_thread_loops should be the
> > maximum possible. But when the code runs, there
> are
> > instances when the idle_thread_loops has a higher
> > value than the previously calibrated value. You
> also
> > have a provision in your code to check for this
> > condition. I am curious as to why this condition
> could
> > crop up.
> One reason i can think of is that the 100ms is not
> 100ms.
> cyg_alarm_enable(alarmH);
> This creates an alarm part way through a tick. So
> the actual alarm
> will be 100m + remainder of a tick. This could in
> fact be 109.9999 ms
> etc. Thus the error is in range of 10%. 
> I did not think of this at the time. A simple
> solution would be to put
> a cyg_thread_delay(1) before this. This should, in
> most cases, put the
> initialization at the beginning of a time slice and
> so increase the
> accuracy. 
>           Andrew

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

More information about the Ecos-discuss mailing list