Go Down

Topic: ATTiny 25V - 1MHz - Huge delay not working (Read 400 times) previous topic - next topic

ilfuria

Hello.
I have a project using an ATTiny board that, in certain cases, has to stand idle for very long amounts of time (~45 minutes, that is 2,700,000ms).
I'm used to the _delay_ms function, but that number is too huge and, basically, the chip stands idle forever.

I then tried to put a for loop like
Code: [Select]

for(int i=0; i<1000; i++) _delay_ms(2700);


which still does not work as expected (i.e. the chip still keeps going).

Since these are some huge delays, do you know any tricks I can use to make the thing work?
Thanks a lot in advance

DrAzzy

Are you compiling it for 8mhz instead of 1mhz? If you did, it would run at 1/8th the expected speed, so the delays would be so long you might conclude they're going on for ever.

delay takes an unsigned long so it should work up to 4.2 billion milliseconds.
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy

ilfuria

I actually don't know how to check for this, sorry…  :-[
I used some makefiles from a book, and the avr-gcc -DFCPU option is set to 1000000UL.
Also I defined F_CPU in my code as
Code: [Select]
#define F_CPU 1000000UL
That should be it, right?
Thanks,

DrAzzy

Okay, yup.

So you're also not using the Arduino IDE.

delay_ms takes a double...

See the comment in util/delay.h

Code: [Select]
/**
   \ingroup util_delay

   Perform a delay of \c __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.

   If the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long)
   support, maximal possible delay is 4294967.295 ms/ F_CPU in MHz. For
   values greater than the maximal possible delay, overflows results in
   no delay i.e., 0ms.

   Conversion of __us into clock cycles may not always result in integer.
   By default, the clock cycles rounded up to next integer. This ensures that
   the user gets atleast __us microseconds of delay.

   Alternatively, user can define __DELAY_ROUND_DOWN__ and __DELAY_ROUND_CLOSEST__
   to round down and round to closest integer.

   Note: The new implementation of _delay_ms(double __ms) with
    __builtin_avr_delay_cycles(unsigned long) support is not backward compatible.
   User can define __DELAY_BACKWARD_COMPATIBLE__ to get a backward compatible delay.
   Also, the backward compatible
   algorithm will be chosen if the code is compiled in a <em>freestanding
   environment</em> (GCC option \c -ffreestanding), as the math functions
   required for rounding are not available to the compiler then.

 */
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy

ilfuria

Ok… I already read that but I did not quite understand it.
Anyhow, thanks to your suggestion, I tried to use a slower time (i.e. 60 seconds) and what I found is that the "wait" is doubled. I think this can be due to a lot of reasons… I'd better check out the whole code.
Thanks anyway

Go Up