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

[Alain M.]

Bernard Fouché escreveu:
>>   
> 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.

What about having two functions? My idea is based in the fact that in 
embedded, the round option is often critical and changes a lot for 
different situations. (the linker can aliminate te ones not used)

> 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.

IMHO we need first is a fix for the problem that fits every need. *Then* 
optimization can be done... IIRC some nut functions return constant 
variables and some other times read from unmodified registers. That is 
to say that an optional global optimization can be thousands of times faster

Alain