How do you debug on a small chip with -O0 ???

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

Hi,

So, I've put together a very small program from the example in the first tutorial.

It is 72 bytes when using -Os, but when I use -O0, it jumps to 3130 bytes! If I comment out the _delay_ms(1000); it goes back to a reasonable 104 bytes.

Two questions -

1. Why does it jump to over 3K ?

2. How do you debug on chips that have limited memory like a tiny13a with 2K ?

Thanks,

Alan

---------------------------------

#define F_CPU 4000000UL

#include
#include

int main()
{
DDRB=7;

while(1)
{

if (PINB & 8)
PORTB |= _BV(0);
else PORTB &= ~(_BV(0));

_delay_ms(1000);

}
}

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

The _delay_ms() function (actually a macro IIRC) uses floating point maths to determine the exact number of cycles needed to be wasted to get the desired delay. Under -Os, an optimisation called "constant folding" causes this floating point value to be calculated at compile time, and only the calculated value to be used when the program runs.

With -O0, this optimisation is turned off and the compiler is forced to include the entire floating point library to do the calculation at runtime. Not only does this cause a hefty program size increase, it also causes the delay to be much longer than desired due to the calculation overhead.

Debugging with -Os is an art you will learn; a common trick is to declare variables of interest with "volatile" so that the compiler is forced to emit code for them rather than optimising them out completely if possible, so they can be watched in AVRStudio.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Hello

I am wanting to find out more information on compiler optimizations. What the compiler tends to remove / optimise and the resulting side effect to the code.

Some debugging tricks with Optimization level 0s, such as the volatile definition of variables, are useful, but what are other good methods of debugging.

Thanks in advance.

Derek

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

alank2, why do you use other types of optimization instead of -Os? Especially on the small chip? I always use -Os level as the best one.

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

The usual argument for using the horrendous -O0 setting is that it makes the code "easier to debug". Admittedly (as shown by this very thread) you are then debugging an entirely different program but at least you don't have to go hunting for the variables and the Watch window can be used.

Cliff

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

you can define a bigger chip in debuge mode and use your tiny13 with development

I love Digital
and you who involved in it!

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

clawson wrote:
The usual argument for using the horrendous -O0 setting is that it makes the code "easier to debug". Admittedly (as shown by this very thread) you are then debugging an entirely different program but at least you don't have to go hunting for the variables and the Watch window can be used.

Cliff


I'm affraid that debugging the code with the -O0 level you don't see the truth. To program uC you have to compile the code with the different -Os level. So the code inside the uC will be another.

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

Hi,

I was trying -O0 to make debugging followable. Are there levels between -O0 and -Os that are still followable, but not quite so bloated?

Also, could the timer code be compiled as a library using -Os and then my main program compiled as -O0 so it would be easier to debug, but the timer code wouldn't be affected? I've done this with other C development, would it work on this platform?

Thanks,

Alan

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

There is the level -O1. This has less optimaization turned on, but the its much more like -Os than -O0.

Making some or even all variables volatile allready helps a lot to make the code easier to debug.

Its allso possible to turn of some types of optimization off individually.

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

Kleinstein wrote:
There is the level -O1.

I also strongly recommend this as well.

Those delay functions have limitations that are strictly spelled out in the AVR-LibC User Manual. One limitation is that optimization must be turned on. But that doesn't mean that the only optimization is -Os. Try using -O1.

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

Or just learn to debug optimised code as the rest of us have done. Using the mixed C+Asm view in the debugger is a very useful tool - in this as you can see whether intermediate variables have been discarded or moved into register only usage.

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

You can temporarily split subroutines into individual source files, compile everything Os, change to O0 option and make edits to the files you want to debug so they will recompile.

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

Or just put the O0 option on individual files.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]