Bug with clock nanoseconds

[Joel Sherrill]

Aitor.Viana.Sanchez at esa.int wrote:
>
>
> > I repeat.  It is the responsibility of the clock tick device driver
> > to reliably and correctly report the number of nanoseconds since
> > the last time rtems_clock_tick was called.  If that was slightly
> > greater than 1 tick ago, then it needs to return a number of nanoseconds
> > slightly greater than 1 tick.
>
> I agree but...
>
> I think bsp_clock_nanoseconds_since_last_tick() for LEON2 and ERC32 
> are well implemented. They return the precise amount of nanoseconds 
> since last tick and I dont really see the proposed workaround (see 
> bellow)
>
> LEON2:
>
> uint32_t bsp_clock_nanoseconds_since_last_tick(void) {
>    uint32_t clicks;
>
>    clicks = LEON_REG.Timer_Counter_1;
>
>    /* Down counter */
>    clicks = (uint32_t) (BSP_Configuration.microseconds_per_tick - 
> clicks) *
> 1000;
>
>    /* if an interrupt occurred while interrupts were disabled and the
> nanoseconds is too little */
>    /* means that a clock interrupt occurred BEFORE the nanoseconds were
> read */
>    if (LEON_Is_interrupt_pending(LEON_INTERRUPT_TIMER1) && clicks <
> BSP_Configuration.microseconds_per_tick / 2)
>        clicks += BSP_Configuration.microseconds_per_tick * 1000;
>
>    return clicks;
> }
>
> This implementation does not make sense without the framework of the 
> _TOD_Get_uptime() function where the problem is an interrupt between 
> getting _TOD_Uptime and getting nanoseconds since last tick.
>
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.

Most of the time the answers are the same but there is a small window
where it is not and this case highlights that.
> Moreover, CONFIGURE_MICROSECONDS_PER_TICK  defines the RTEMS time 
> granularity so I dont see the point making this ad-hoc modification in 
> bsp_clock_nanoseconds_since_last_tick() function to make 
> _TOD_Get_Uptime() work properly when we can do it applying this simple 
> patch
>
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.
> === modified file 'cpukit/score/src/coretodgetuptime.c'
> --- cpukit/score/src/coretodgetuptime.c 2009-03-31 07:56:38 +0000
> +++ cpukit/score/src/coretodgetuptime.c 2009-03-31 11:58:51 +0000
> @@ -46,8 +46,8 @@
>
>    _ISR_Disable( level );
>      *uptime = _TOD_Uptime;
> -    if ( _Watchdog_Nanoseconds_since_tick_handler )
> -      offset.tv_nsec = (*_Watchdog_Nanoseconds_since_tick_handler)();
> +//    if ( _Watchdog_Nanoseconds_since_tick_handler )
> +//      offset.tv_nsec = (*_Watchdog_Nanoseconds_since_tick_handler)();
>
>    _ISR_Enable( level );
>
> loosing no resolution.
>
> BTW this patch is tested and working.
>
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985