[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug with clock nanoseconds
- Date: Tue, 31 Mar 2009 15:38:40 +0200
- From: Aitor.Viana.Sanchez at esa.int (Aitor.Viana.Sanchez at esa.int)
- Subject: Bug with clock nanoseconds
> It is correct. RTEMS asked the BSP a very simple question:
> "How many nanoseconds has it been since you last called
> The driver was answering this question with the "number of nanoseconds
> since the last counter hit zero" not since it last called
In this case I think is correct as the "counter hit zero" event
corresponds to the "last called rtems_clock_tick()"
> You are losing the ability to have the timestamp include "partial
> If you call get uptime 10 times in a row, you will likely get only 1 or
> (if a tick occurs) distinct values. Getting nanosecond accurate
> is the entire functional goal of the handler being called.
Yes that's completely true. I want to ask something. The problem is caused
because _TOD_Get_uptime() function is performing...
*uptime = _TOD_Uptime
if( _Watchdog_Nanoseconds_since_tick_handler )
offset.tv_nsec = (*_Watchdog_Nanoseconds_since_tick_handler)();
and if a clock tick interrupt occurs in between the consistency between
the uptime and offset values is lost. Should not be the _TOD_Get_uptime()
function preventing this?
-------------- next part --------------
An HTML attachment was scrubbed...