Hello, I am verifying a simple LED blink code on ATMega2560 controller using Atmel Studio 7. The function _delay_ms(1000) does not actually generate a delay of 1000 ms. It is atleast 4 times faster. Can anyone tell me about this behaviour? My F_CPU is 16 MHz.
:
Locked by Moderator
F_CPU can be set as a compiler parameter (-D) or as a definition (#define) in your source code. If it is in source code, then it must be placed above the #include statement that load the util/delay.h file. The value of F_CPU must match the real clock frequency of the CPU, but it cannot be used to configure the CPU. The CPU derives its clock from an external crystal or resonator which should oscillate at 16 MHz. If the fuse CLKDIV8 is set, then the initial CPU clock is 1/8 of the 16 MHz. On Arduino modules, this fuse should normally be off. Check that. You software can modify the clock divider by writing to the CLKPRE register. You can divide the 16 MHz by 1 .. 256. Something is wired in your case because you say that the time is 1/4 of the expected one. So the CPU seems to run at 64 MHz. Needless to say that this is technically impossible. So the only thing I could imagine is that your F_CPU is not properly set, although you say that it is.
Echotwozero wrote: > The function _delay_ms(1000) does not actually generate > a delay of 1000 ms. It is atleast 4 times faster. First answer was korrekt: The maximal possible delay is 262.14 ms / F_CPU in MHz
No! Avr-libc says it is possible to define delays up to 6.5535 seconds (independent from CPU frequency). >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. >When the user request delay which exceed the maximum possible one, _delay_ms() provides a decreased resolution functionality. In this mode _delay_ms() will work with a resolution of 1/10 ms, providing delays up to 6.5535 seconds (independent from CPU frequency). The user will not be informed about decreased resolution.
Lutz wrote: > First answer was korrekt: The maximal possible delay is 262.14 ms / > F_CPU in MHz How does this fit to the observation of 250ms faster at 16 Mhz? 262.14 ms / 16 = 16.4 ms Read the paragraph below that in the documentation. As Gerhard wrote, much longer delays are possible but then the resolution is only 1/10 seconds which is not a problem in this case. Most people even did not notice that the delay function can be called with a floating point parameter to delay fractions a milliseconds.
Echotwozero wrote: > ATMega2560 controller Is that a self-made device? Crystals may oscillate with a higher frequency if the capacitor are missing or much too small.
Please check also this: Could it be possible, that your Core currently running on internal osc with 8MHz? This would decribe the the Quarter delay: 1. 8MHz instead of 16MHz 2. Clock Divider of 8 is set
There is a CLKO pin (PE7). If you set the fuse CKOUT, this pin will carry the system clock and you can measure the actual frequency.
NickNack wrote: > Could it be possible, that your Core currently running on internal osc > with 8MHz? > This would decribe the the Quarter delay: > 1. 8MHz instead of 16MHz > 2. Clock Divider of 8 is set stefanus wrote: > Is 8 MHz the quarter of 16 MHz? Ah, I got it (Facepalm). 16 MHz / 8 = 2 MHz 8 MHz ist 4x faster than 2 MHz.
Watch this topic
Disable multi-page view