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

[Bernd Walter]

On Mon, May 16, 2011 at 06:00:41AM -0700, uprinz wrote:
> 
> Hi!
> 
> Currently surfing the ostimer things for optimization in Cortex. Found there
> some interesting things...
> 
> __First__
> 
> In timer.c the function void NutMicroDelay(uint32_t us) looks to accept a
> value of us -> microseconds.
> The explanation of the function talks of microseconds too:
> 
> /*!
>  * \brief Loop for a specified number of microseconds.
>  *
>  * This call will not release the CPU and will not switch to another
>  * thread. However, interrupts are not disabled and introduce some
>  * jitter. Furthermore, unless NUT_DELAYLOOPS is not defined, the
>  * deviation may be greater than 10%.
> 
> But then the value is referenced as milliseconds:
> 
>  *
>  * If you need exact timing, use timer/counter hardware instead.
>  *
>  * \param us Delay time in microseconds. Values above 255 milliseconds
>  *           may not work.

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

>  *
>  * \todo Overflow handling.
>  */
> 
> The calculation then again calculates 
> register uint32_t cnt = nut_delay_loops * us / 1000;
> 
> what will result in millisecond resolution...

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.

> There will be no difference in the delay time if you give any value that
> differs only in the last three decimal digits ( yyyxxx)  as a parameter to
> this function.
> 
> __Second__
> 
> In some functions the system timer is referred to as something to be divided
> or multiplied by 1000. In other functions the same timer is referred to by
> dividing or multiplying it by 1024.

The delay has nothing to do with he system timer - maybe it is measured once
using the timer - don't know...

> I think we need some cleanup here, or am I totally wrong?
> Ulrich

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