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
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..
"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.
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.
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.
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
-OgOptimize 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.
