Bug with clock nanoseconds

[Aitor.Viana.Sanchez at esa.int]

> It is correct.  RTEMS asked the BSP a very simple question:
> 
> "How many nanoseconds has it been since you last called 
rtems_clock_tick?"
> 
> The driver was answering this question with the "number of nanoseconds
> since the last  counter hit zero" not since it last called 
rtems_clock_tick.

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 
ticks".
> If you call get uptime 10 times in a row, you will likely get only 1 or 
two
> (if a tick occurs) distinct values.  Getting nanosecond accurate 
timestamps
> 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...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090331/5d481d81/attachment-0001.html>