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

[uprinz]

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.
 *
 * \todo Overflow handling.
 */

The calculation then again calculates 
register uint32_t cnt = nut_delay_loops * us / 1000;

what will result in millisecond resolution...
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.

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


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