[En-Nut-Discussion] NutGetTickClock rounding (again)

[Bernard Fouché]

Henrik Maier wrote:
> The previously proposed arithmetic rounding method did not require two cases
> and I don't consider it that bad after all as NutGetTickClock is actually
> constant and we can assume that it is always close to 1000 or multiples of
> it. So I think your argument that arithmetic rounding will be wrong 50% of
> the time does not apply to this use case.
>   
I would not bet on people always using a number of ticks per second 
equals or closes to 1000. I also share Duane's point of view: the return 
value must never be inferior to the 'real' expected value. Typical 
example: having to wait for at least 5ms before writing again into an 
I2C addressed EEPROM. If I call the function with the value 5(ms) and 
the system ticks @997Hz, then I want the value 6(ticks) to be returned 
and not 5(ticks).

Power usage or specific peripheral driving may require some programmer 
to use whatever tick freq he/she needs, and IMHO making here the choice 
of having hidden side effects on such a calculation is to be avoided.

If the Linux calculation is fine, then let's take it: anyway, if the 
tick count function expands to a constant, conditional compilation and 
the optimizer will reduce the instruction count. If the tick count is 
not a constant, then we can not do much about it beside not introducing 
wrong results. Maybe some programmer out there even use a variable tick 
count :)

If this calculation takes too long, then the application programmer will 
have to organize his/her code to call NutGetTickClock() less often, but 
at least there won't be any bad surprise whose origin is buried into the OS.