Oneskorenia s AVR

Poznámka k používaniu fukncie _delay_ms()

void _delay_ms ( double __ms )

Perform a delay of __ms milliseconds, using _delay_loop_2().

The macro F_CPU is supposed to be defined to a constant defining the CPU clock frequency (in Hertz).

The maximal possible delay is 262.14 ms / F_CPU in MHz.

Citovane z avr library documentation of delay.h http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html

If you look at delay.h, you'll see the following comment:

   The maximal possible delay is 262.14 ms / F_CPU in MHz.

So, running at 16 MHz, the maximum delay with _delay_ms is 16 milliseconds.

Tried this from scratch, compiled with -O1 on WinAVR 20060421 for an ATmega8, Frequency to 8 MHz, set up on AVR Studio 4.12 SP2 build 472, and it includes the full math library. Recompiling with -O2 the math library isn't included.GCC 3.4.6 doesn't optimize the FP math away with only -O1. It does with -Os though (which is IMHO the most recommendable optimization level for the AVR anyway). Alternatively, add -fgcse, and it will optimize them as well.

Interestingly enough, GCC 4.1.0 optimizes these even with -O1.

void delay_1s(void) {

  uint8_t i;
  for (i = 0; i < 100; i++)
     _delay_ms(10);

}

Alebo

// this wrapper function calls _delay_ms with a known value of 1 // if you call _delay_ms(variable) then the floating point library // is going to be included and your output file gets much larger void delay_1ms(uint16_t ms) {

   uint16_t i;
   for(i=0;i<ms;i++) _delay_ms(1);

}

A tu je este poznamka, ze hodnota musi byt znama v case prekladu, takze kompilator moze vyraz vyhodnotit a nahradit ho vysledkom. V opacnom pripade je na pocet cyklov pouzity vypocet, ktory vyvola pouzitie kniznice pre pracu s realnymi cislami math.h cim program vzrastie o viac ako 2kB.

The functions in this header file are wrappers around the basic busy-wait functions from <util/delay_basic.h>. They are meant as convenience functions where actual time values can be specified rather than a number of cycles to wait for. The idea behind is that compile-time constant expressions will be eliminated by compiler optimization so floating-point expressions can be used to calculate the number of delay cycles needed based on the CPU frequency passed by the macro F_CPU.

Note

   In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

The functions available allow the specification of microsecond, and millisecond delays directly, using the application-supplied macro F_CPU as the CPU clock frequency (in Hertz).