[En-Nut-Discussion] NutGetTickClock rounding (again)
Henrik Maier
hmlists at focus-sw.com
Wed Jul 16 08:23:19 CEST 2008
> NO - i disagree. I would call this *WRONG* You are doing 'traditional
> rounding' at the 0.5 point. While mathematically that seems correct (ie:
> rounding money). Most developers Timeouts will be wrong 50% of the time.
Duane,
You are right it is more accurate for timing purposes not to use traditional
arithmetic rounding. Also my code broke when Nut/OS changed the
NutTimerMillisToTicks implementation from 4.2.1 to 4.4.1 because time-outs
were suddenly too short not because they were too long.
Thank you for the very good explanation and constructive contribution. I had
another close look at the Linux kernel code and they are also using the
'rounding-up' method:
(m * HZ + MSEC_PER_SEC - 1) / MSEC_PER_SEC.
In our case HZ is NutGetTickClock and MSEC_PER_SEC is 1000.
So the rounding should then be done this way I suppose:
---------------------------------------------------
u_long NutTimerMillisToTicks(u_long ms)
{
if (ms >= 0x3E8000UL)
return (ms / 1000UL) * NutGetTickClock();
else
return (ms * NutGetTickClock() + (1000UL - 1UL)) / 1000UL;
}
-----------------------------------------------------
Henrik
More information about the En-Nut-Discussion
mailing list