Debug / Release Strange Timer behaviour

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

Hi,

I just realised that my debug / release options can generate different F_CPU frequency and I dont know why is that.

 

For programming my device I am using USBASP 2.0

 

For Debug I am using:

-c usbasp -p atmega8 -U flash:w:$(ProjectDir)Debug\$(TargetName).hex:i

and for Release:

-c usbasp -p atmega8 -U flash:w:$(ProjectDir)Release\$(TargetName).hex:i

Recently I changed my F_CPU frequency via ExtremeBurner and realised that on Debug frequency  of _ms_delay() is too high (LED blinks too fast)

while on release it is fine...

 

My other concern connected to these 2 functions is that with big chunks of code (a lot libs included etc) sometimes Debug wasnt writing code to the device, while release was.

I suppose it is connected to the optimalization as debug option propably didnt do opt for space and just couldnt 'fit'.

 

However I thought for optimalization were responsible 2 functions placed here (atmel studio 7)

As you can see here it is stated however I have no idea how these AVRdude declarations are corresponding with it as they seem to be completly different set of tools...

 

As I am quite fresh to AVR programming could someone put some light on this please?

 

Chris

 

 

 

 

 

 

This topic has a solution.
Last Edited: Thu. Aug 31, 2017 - 10:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Chris_Irathil wrote:
that on Debug frequency of _ms_delay() is too high (LED blinks too fast) while on release it is fine...
But the rate of flashing is determined at the time you COMPILE the code, not when you program it. So if Debug/Release differ then it suggests that F_CPU was defined differently in the two. So show the code and the way in which F_CPU is being defined for both Debug and Release.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no point in using separate USBASP_Debug and USBASP_Release.

 

Just configure your external Tools "Arguments" as:

-c usbasp -p ATmega8 -e -U flash:w:$(TargetName).hex:i -U eeprom:w:$(TargetName).eep:i

and "Initial Directory" as:

$(TargetDir)

I would avoid "Extreme Burner" like the Plague.    Or at least use it very carefully.

 

David.

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

Thank you Clawson for response,

I couldn't find definitions of F_CPU for these tools

 

here is the code:

#ifndef F_CPU
#define F_CPU 8000000UL // 8 MHz clock speed
#endif

#include <avr/io.h>
#include <util/delay.h>

//TESTING PROGRAM FOR AVR AND CLOCK FREQUENCY(delay)

int main(void)
{
	DDRC = 0xFF; //Makes PORTC as Output
	PORTC= 0xFF; //Turns PORTC to HIGH state

	while(1) //infinite loop
	{
		PORTC = 0xFF; //Turns ON All LEDs
		_delay_ms(1000); //1 second delay
		PORTC= 0x00; //Turns OFF All LEDs
		_delay_ms(1000); //1 second delay
	}
	return 0;
}

apparently as I turned on AVR and tested is everything was fine, so to again I changed F_CPU via extreme burner to 8 Mhz (4 previously).

After Build -> Debug works correcly. However releasing this pasted code effects in LED blinking in 2x frequency it is supposed to.

 

PS: even if it was compiled and debugged and is working correcly, pressing release makes led blink twice as fast as it is supposed to.

 

Chris

 

Last Edited: Thu. Aug 31, 2017 - 09:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I would avoid "Extreme Burner" like the Plague.

Just out of interest, why is that?

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

Thank you David,

 

After changing again Frequecny (well... I had  to test it somehow -,-' ), building and using your commands to build/release it worked properly!

Could you bring closer the topic of avoiding Extreme Burner?

 

Also which of these 2 modes is more recommended to use?

 

So many questions in such simple matter!

 

Chris

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

Chris_Irathil wrote:
Also which of these 2 modes is more recommended to use?

 

 

See: http://www.avrfreaks.net/forum/m...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#ifndef F_CPU
#define F_CPU 8000000UL // 8 MHz clock speed
#endif

Don't do it that way. If it is already defined (by a -D) then you could have a different result from what you intend. If you KNOW it is 8MHz then change those lines to be:

#undef F_CPU
#define F_CPU 8000000UL // 8 MHz clock speed

That way it won't matter what it might defined as when it reaches this line (-D) - this will always set it to 8MHz, over-riding any previous setting.

Last Edited: Thu. Aug 31, 2017 - 09:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

#ifndef F_CPU
#define F_CPU 8000000UL // 8 MHz clock speed
#endif

Don't do it that way.

Agreed.

 

I guess whoever did that was trying to be "helpful" (sic) by providing a default.

 

Trouble is, in most cases, it's the wrong value - so it actually hinders and does not help at all.

 

It would have been far more helpful to have something like

#ifndef F_CPU
#error "F_CPU must be defined - see xyz for details"
#endif
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh don't get me started! <util/delay.h> itself has an #ifndef F_CPU but instead of throwing such an error to say "this ain't gonna work unless you define F_CPU" what it actually (stupidly!) does is just define it to an arbitrary 1MHz anyway.
 

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

Thank you guys that was very useful!

Also could you leave some comment about Extreme Burner, as I am still confused about

david.prentice wrote:

I would avoid "Extreme Burner" like the Plague.

So perhaps there are better ways of changiong fuses ? 

Last Edited: Thu. Aug 31, 2017 - 10:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're using Atmel Studio - can't you just do it straight from there?

 

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

awneil wrote:
can't you just do it straight from there?
He said USBAsp so not exactly "straight" from there. But he can follow the usual advice about setting up an "external tool" to invoke avrdude and that would work.