drastic increase in file size

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi,
how precise is the "_delay_ms(time in ms)" function defined in util/delay.h in avr-gcc??

v used this function in our code quite a lot of time and
the resultant file size increase was 16kb!!!!

how can it be reduced and why does this happen as this is a simple fn.??

v used this macro instead of delay and the resultant increase was 12kb instead of 16kb.

#define loose_delay(delay)   \
  for (__temp0 = 0; __temp0 < delay; __temp0++) { \
    for (__temp1 = 0; __temp1 < 0x00FF; __temp1++); \
  }

any idea why this happens??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

anubhavh wrote:
any idea why this happens??
From the AVR Libc documentation:
Quote:
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.
Have you enabled optimization (-Os) and is the delay time an expression that is a known constant at compile-time?

Don

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply don.....
Our file size changed from 33 kb to 11 kb after optimisation.....
our program using _delay_ms is working while the one in which we use our macro own delay is not working....we have posted our macro code in above ...
any idea why this happens??

what is difference between -00,-01,-02...,-0s??
optimisation is not being done at -03 and -00??

i want to ask how precise _delay_ms is...as when simulating a delay of 1000ms the stop watch goes from 400us to 66000us for atmega32 at 4mhz....thats not 1000ms
any clues??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At O3 the compiler goes for MAXIMAL code speed. Not size efficiency. And also it goes a bit nuts. This is not always good for yer code.

O0 disables ALL optimisation so the code is slow and bloated.

These functions are inheritly imprecise. Try compiling it and simulating it under different O settings (O0 O1 O2 O3 Os). You'll see the difference.

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nothing like double posting to get an answer :?

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the posts...
Can u tell why our code for macro doesnt work with compiler optimisation(_OS)
while _delay_ms does??

#define loose_delay(delay) \
for (__temp0 = 0; __temp0 < delay; __temp0++) { \
for (__temp1 = 0; __temp1 < 0x00FF; __temp1++); \
}

and how precise is _delay_ms??
as when simulating a delay of 1000ms the stop watch goes from 400us to 66000us for atmega32 at 4mhz....thats not 1000ms

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your #define won't work with -Os *unless* you make __temp0 and __temp1 'volatile' because otherwise the compiler will think the code in those loops is pointless and throw it away. In part this is why you are wasting your time trying to "roll your own" delays when some clever programmer before you has already done all the brain and leg work and come up with the (fairly) accurate delays in delay.h - so just use those.

(unless you need "long" delays in which case you're probably better off using a hardware timer and maybe even using it with interrupts)

Cliff

PS and for the delays in delay.h to work you have to (a) set F_CPU correctly, (b) turn on compiler optimisation and (c) observe the 262.14 rule