[En-Nut-Discussion] AVR: Use of _delay_loop_2 versus nut_delay_loops

[Uwe Bonnes]

>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

    Harald> Hi Uwe, On 24.09.2012 14:17, Uwe Bonnes wrote:
    >> in SVN Head for NutMicroDelay for AVR, I replaces the usage of
    >> nut_delay_loops with all it's magic constants with a call to the
    >> avr-libc supplied _delay_loop_2() Funktion. Beside setup, the
    >> functions eats 4 cycle for each pass. This change made the BitBanging
    >> One-Wire example work with AVR too.
    >> 
    >> Please let me know if I broke anything.

    Harald> It doesn't work for AVR devices, which automatically detect
    Harald> their CPU frequency and do not have NUT_CPU_FREQ defined.

    Harald> Furthermore, there seem to be other problems with AVR as well,
    Harald> possibly introduced by

    Harald> #if !defined(NUT_DELAYLOOPS) && !defined(__AVR) &&
    Harald> !defined(__CORTEX__)

    Harald> where two underscores are missing.

I checked in two changes for that subject. They fix the __AVR versus __AVR__
and handle the loop calculation when NUT_CPU_FREQ  is not defined.

However a setup without NUT_CPU_FREQ only works with MCU_ATMEGA103 and
MCU_ATMEGA128. This is caused by the special timer setup for CountCpuLoops()
in arch/avr/dev/ostimer.c in

#ifdef NUT_CPU_FREQ             /* ----- NUT_CPU_FREQ */
 #if defined(MCU_AT90CAN128)

I don't have a test setup with these CPUs. And to understand to logic
used there is some bigger effort.

Can you please report back?

Thanks
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------