This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ecos idle function--A correction and clarification.


I never meant the code to be 100% accurate. Its just a rough
estimate. Too many thinks can upset it, so i don't consider it worth
spending much time on it. But this is Open Source. Feel free to spend
time playing with it and if you do make it better, please let me know.

If you do play around with the time periods and filters, please add
CDL to control it. 

     Andrew

On Tue, Jan 21, 2003 at 10:03:36AM -0800, Milind Kopikare wrote:
> 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,
> Milind
> 
> --- 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_initialize(alarmH,cyg_current_time()+10,0);
> > 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.
> http://mailplus.yahoo.com

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]