[En-Nut-Discussion] NutMicroDelay for AVR fails on small values
harald.kipp at egnite.de
Mon May 20 15:24:59 CEST 2013
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
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.
More information about the En-Nut-Discussion