[En-Nut-Discussion] ms / us problem in timer routines

[uprinz]

Bernd Walter-2 wrote:
> 
> The limitation is defined as milliseconds, the value itself is still
> declared as microseconds.
> I don't see anything wrong.
> The 255 milliseconds might not be a limit on each system, but it is
> correctly defined as "may not work".
> 

Ok, so the function needs to be called with 100000 as parameter if you like
to have a 100ms delay.
In that case you could have called NutDelay(100) what results in nearly the
same result.

But for that routine some 32bit math is done what causes lots of code for
AVR. Wouldn't it be better to limit this function to lets say 65k us as
everything above (or from 1000 upwards) could be done by NutDelay(ms)?

On a slow architecture this will result less jitter caused by multiple
8/16bit math.

On fast machines the calculation could be done by using the system timer
actual value with the reload value taken into reference. Might be more
precise and spares the calibration loop at the timer_init.


Bernd Walter-2 wrote:
> 
> No - it results in nut_delay_loops resolution.
> E.g. with nut_delay_loops = 500 (500 loops per ms) it results in 2µs
> resolution.
> Say you want 10µs delay:
> 500 * 10 / 1000 = 5000 / 1000 = 5.
> 
You're right. 


Bernd Walter-2 wrote:
> 
> The delay has nothing to do with he system timer - maybe it is measured
> once
> using the timer - don't know...
> 
I know that, and the init of nut_delay_loops is done in the NutTimerInit().

Ulrich

-----
Best regards
Ulrich
-- 
View this message in context: http://old.nabble.com/ms---us-problem-in-timer-routines-tp31628195p31630408.html
Sent from the MicroControllers - Ethernut mailing list archive at Nabble.com.