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.


>     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

-- 
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]