Issue with gettimeofday() in RTEMS 4.10;

[João Rasta]

The issue seems similar yes, but i'm in doubt about if the leon can use
multiple ISRs per clock tick. How can i confirm if this is a bug?


Best,
JM



On Fri, Jan 28, 2011 at 2:33 PM, Gedare Bloom <gedare at gwmail.gwu.edu> wrote:

> I wonder if this is this related to PR 1495?:
> https://www.rtems.org/bugzilla/show_bug.cgi?id=1495
>
> The symptom is similar, but I don't think the LEON3 has the same
> structure of clock driver.
>
> -Gedare
>
> On Fri, Jan 28, 2011 at 9:11 AM, João Rasta <freakforever at gmail.com>
> wrote:
> > Hi,
> >
> > I'm using gettimeofday() to profile a function. For this i do:
> >
> >         struct timeval tim;
> >         // *Get actual clock
> >         gettimeofday(&tim, NULL);
> >         double t1=tim.tv_sec+(tim.tv_usec/1000000.0);
> >
> >
> >         // *GNC Calculations starting point
> >         Execute_gnc();
> >         // *Calculations termination point
> >
> >
> >         // *Calculate elapsed time with GNC calculations.
> >         gettimeofday(&tim, NULL);
> >         double t2=tim.tv_sec+(tim.tv_usec/1000000.0);
> >
> >         procDelay = (t2 - t1 + 0.0275);
> >         if (t1 > t2)
> >             printf(" WARNING %f > %f\n",t1,t2);
> >         else
> >             printf("%f\n",procDelay);
> >
> > But sometimes t1 is larger than t2, which should not be possible since t2
> is
> > allways measured after t1. For instance, the above code produces the
> > following when this issue happens:
> >
> > WARNING 567996584.559981 > 567996584.550001
> >
> > The above code runs in loop and this happens roughly once in an hour
> (just
> > an estimate). Is there any known overflow issue with the usec counter
> that i
> > should be aware? RTEMS is running with a LEON-3.
> >
> >
> > Best,
> > JM
> >
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.org
> > http://www.rtems.org/mailman/listinfo/rtems-users
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20110128/e5827564/attachment-0001.html>