[En-Nut-Discussion] NutMicroDelay for AVR fails on small values

[Harald Kipp]

Hi Uwe,

On 20.05.2013 11:47, Uwe Bonnes wrote:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
> 
>     Harald> Hi, I tried NutMicroDelay on a 16MHz ATmega128. While
>     Harald> NutMicroDelay(100) seems to work well, NutMicroDelay(10) creates
>     Harald> a much larger delay.

> is NUT_CPU_FREQ defined in you case? Maybe your
> code hits the 32 bit division and that division causes a great offset?

I'm currently not able to test this on real hardware, but...

NUT_CPU_FREQ is not defined, so

__tmp = (us *(NutGetCpuClock()>>8))/(400000000/256);

applies, in which case

__tmp = 10 * (16000000 >> 8) / 400000000 / 256;
__tmp = 625000 / 1562500;
__tmp = 0;

My guess is, that

_delay_loop_2(0);

results in a very long delay.

> Otherwise, it is not clear to me in what direction to optimize? There may be
> code that will do good on slort delays and bad on long delay, code that will
> do the other way round and much more compilcate code that does better in
> more cases.

As NutMicroDelay() avoids any context switch, it is quite useless for
long delays. IMHO, the focus should be on short delays.

Regards,

Harald