<br><tt><font size=2>> It is correct.  RTEMS asked the BSP a very
simple question:<br>
> <br>
> "How many nanoseconds has it been since you last called rtems_clock_tick?"<br>
> <br>
> The driver was answering this question with the "number of nanoseconds<br>
> since the last  counter hit zero" not since it last called
rtems_clock_tick.</font></tt>
<br>
<br><tt><font size=2>In this case I think is correct as the "counter
hit zero" event corresponds to the "last called rtems_clock_tick()"</font></tt>
<br>
<br><tt><font size=2>> You are losing the ability to have the timestamp
include "partial ticks".<br>
> If you call get uptime 10 times in a row, you will likely get only
1 or two<br>
> (if a tick occurs) distinct values.  Getting nanosecond accurate
timestamps<br>
> is the entire functional goal of the handler being called.</font></tt>
<br>
<br><tt><font size=2>Yes that's completely true. I want to ask something.
The problem is caused because _TOD_Get_uptime() function is performing...</font></tt>
<br>
<br><font size=2 face="Courier New">*uptime = _TOD_Uptime</font>
<br><font size=2 face="Courier New">if( _Watchdog_Nanoseconds_since_tick_handler
)</font>
<br><font size=2 face="Courier New">offset.tv_nsec = (*_Watchdog_Nanoseconds_since_tick_handler)();</font>
<br>
<br>
<br><tt><font size=2>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?</font></tt>
<br>