Multiple firmware build configurations

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

Hi,

 

It seems to me that having separate debug and release configurations is of little to no value. Generally, because of size restrictions, you need to use the same optimization options for both. Also, debug symbols are normally stripped from the code actually programmed onto the target (loaded separately from e.g. elf file when in-circuit debugging).

 

For firmware, what are you guys' preferred setup and why?

 

single configuration?

build and debug configurations

even more configurations?

 

Cheers

Last Edited: Thu. Aug 24, 2017 - 08:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The main reason, as I see it, is that in the Debug build configuration you have the DEBUG symbol defined. This can be used for e.g. conditional compilation - possibly some logging that you only want while developing, or some such.

 

As you say, there is not much difference in compiler options in Debug and Release configurations, though I suppose someone might (for obscure reasons) want -O1 instead of -Os while developing.

 

For some cases, even more build configs can be used - perhaps to vary device build for?

 

It's a flexible system for a varying reality - so there is no single "preferred setup". It depends..

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]

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

"Debug" and "Release" are two different configurations that are inherited from Visual Studio. You are right that they are of little/no relevance for AVR because the (final) binary (the .hex) never contains debug symbols so the ability to turn on / off such as might happen when building EXE is of no relevance for AVR.

 

Also for EXE you turn on things like allocation boundary checks and stack frame checking run time code by the selection - but again AVR has none of this.

 

I've often wondered why Atmel chose to continue the tradition of Debug/Release when they started to use VS for AVR.

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

clawson wrote:
they are of little/no relevance for AVR

I disagree.

 

the (final) binary (the .hex) never contains debug symbols so the ability to turn on / off such as might happen when building EXE is of no relevance for AVR.

That is true, but that is not the only point of having different build configurations.

 

As Johan says, the key benefit is having the DEBUG symbol defined which can enable stuff like (extra) diagnostic logging.

 

Often, chips have special options for things like enabling debug through sleep - that is something that could usefully be in a "debug" but not a "release" build.

 

Very often, I will have a build for a dev kit and a build for the "real" hardware - that can also take advantage of different build configurations.

 

 

Whether Atmel's choice of default settings for the "debug" and "release" configurations (or even the choice of names) is useful is an entirely different matter - but the facility to have different configurations is certainly valuable, IMO & IME.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, as someone who uses visual studio with solutions that often have 100+ projects and 50+ configurations I'm well aware of the use of build configs and the advantages they offer. But I still don't think it's particularly relevant to have the two named configs that Atmel offer by default and that seem to just be trying to fit in with MSVS defaults. 

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

JohanEkdahl wrote:
As you say, there is not much difference in compiler options in Debug and Release configurations, though I suppose someone might (for obscure reasons) want -O1 instead of -Os while developing.

We have -Og now; introduced in upstream gcc 4.8

-Og

Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.

 

Last Edited: Sat. Aug 26, 2017 - 10:35 AM