RIT timer possible overrun

[lpcware]

Content originally posted in LPCWare by efiLabs on Sun Dec 14 22:29:48 MST 2014
friends :

i noticed the following code in LpcOpen rtitimer_15xx.c

/* Returns the current timer Counter value */
uint64_t Chip_RIT_GetCounter(LPC_RITIMER_T *pRITimer)
{
uint64_t val;

val = (uint64_t) pRITimer->COUNTER_H;
val = val << 32;
val |= (uint64_t) pRITimer->COUNTER;

return val;
}

how about if the timer rolls over into the high part between the 2 reads ???

i didn't find anything in the user manual stating if the high part is being read 1st the low reading following it contains a saved copy of the low part from the time of the high part read

my solution was

  ulong h0 = LPC_RITIMER->COUNTER_H ;
  ulong lo = LPC_RITIMER->COUNTER ;
  ulong h1 = LPC_RITIMER->COUNTER_H ;

and if h0 != h1 reread the low part

any other suggestions please ???

cheers efiLabs

[lpcware]

Content originally posted in LPCWare by starblue on Fri Mar 27 02:33:56 MST 2015

---

Quote: efiLabs
my solution was

  ulong h0 = LPC_RITIMER->COUNTER_H ;
  ulong lo = LPC_RITIMER->COUNTER ;
  ulong h1 = LPC_RITIMER->COUNTER_H ;

and if h0 != h1 reread the low part

---

That's what I do in similar situations, loop while the reading of the high part changes.  Under any realistic system load the loop should terminate very quickly, rereading at most once (if not you have serious problems elsewhere).

[lpcware]

Content originally posted in LPCWare by hnoor on Fri Mar 27 00:47:54 MST 2015
i didn't find anything in the user manual stating if the high part is being read 1st the low reading following it contains a saved copy of the low part from the time of the high part read