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

[Bernd Walter]

On Mon, May 16, 2011 at 08:51:33AM -0700, uprinz wrote:
> 
> 
> 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)?

You still need multiply the value with nut_delay_loops, so uint16_t
isn't big enough to hold the intermediate result.
Is the code really that big compared to 16bit on AVR?
Of course cycles don't count, since it's about wasting cycles anyway.

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

Ok - that's a valid point.
The cyceles required for the multiplication/division may be depended
on the values.
Nevertheless you still need enough space for the nut_delay_loops * us.

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

Yes - I've often done delays using timers.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.