Dynamic memory size difference between IDE versions

[LukeZ]

Hello all,

I have a project that I wrote a few years ago using Arduino IDE 1.8.5. The source code is too long to post here, but is available on GitHub (yes, this is actually a link to github.com): GitHub - OpenPanzerProject/TankIR: A standalone tank IR device for use with Arduino UNO/Nano/other ATmega328 boards

The project is designed to run on any ATmega328 board; I always compile for the Nano. It is basically an IR sending and receiving program, but instead of the usual TV remote stuff it implements IR codes used in the RC tank hobby.

The program not only compiles fine in 1.8.5 but when loaded onto a board it actually functions as designed. Here are the compiled results:

Sketch uses 24300 bytes (79%) of program storage space. Maximum is 30720 bytes.
Global variables use 1462 bytes (71%) of dynamic memory, leaving 586 bytes for local variables. Maximum is 2048 bytes.

Recently I had another use attempt to compile in 1.8.13 and he reported getting the "stability problems may occur" warning. I downloaded 1.8.13 and confirmed, here are the compile results:

Sketch uses 25028 bytes (81%) of program storage space. Maximum is 30720 bytes.
Global variables use 1864 bytes (91%) of dynamic memory, leaving 184 bytes for local variables. Maximum is 2048 bytes.
Low memory available, stability problems may occur.

Dynamic memory for the same code has increased almost 400 bytes from 1,462 to 1,864.

I thought to myself, "I should see at what point between 1.8.5 this changes." Lo and behold, the sketch won't even compile on 1.8.6 through 1.8.9, in all four cases I get the same error message from the compiler:

lto1.exe: internal compiler error: in lto_output_varpool_node, at lto-cgraph.c:624

Please submit a full bug report,

with preprocessed source if appropriate.

See <http://gcc.gnu.org/bugs.html> for instructions.

lto-wrapper.exe: fatal error: C:\Arduino\hardware\tools\avr/bin/avr-gcc returned 1 exit status

compilation terminated.

c:/arduino/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed

collect2.exe: error: ld returned 1 exit status

exit status 1
Error compiling for board Arduino Nano.

When we get to 1.8.10 compilation works once more, but with the same larger size tallies that we get in 1.8.13 listed above. (I did not test 1.8.11 or 1.8.12)

I have a slew of other sketches from different projects laying around, and I compiled a few in 1.8.5 compared to 1.8.13. In all cases that I tried, the compiler actually gave me a smaller final program in the end with 1.8.13, as we would expect as optimizations improve. But for this specific project, the result is the opposite.

We have tried running the Tank IR code compiled on 1.8.13 in the real world, and in fact it does not work although we have not delved into exactly where it is breaking. But it seems likely at some point it is running out of memory and going into an unpredictable state.

Turning on verbose output for the compiler shows some mild warnings (typedef was ignored in this declaration, variable set but not used, etc...) Those can be cleaned up but don't in my opinion account for the 400 byte difference.

Now the failure to compile in 1.8.6 through 1.8.9 is probably an important clue, but the error message given doesn't mean much to me personally so I am not sure how to leverage that.

I am happy to do my own legwork, but although I have written lots of programs this sort of thing is a bit outside my expertise and I'm not sure where to start figuring things out.

And yes, it likely is possible to reduce the size of the sketch and I think that is a good exercise for me to do, but I would still like to get the bottom of this particular issue.

Any pointers or hints of things to explore would be most appreciated. My gratitude in advance!

Luke

[sterretje]

The lto-wrapper was a known bug with a certain version of gcc; you can search for it in the forum; I seem to remember that it can be solved by changing the boards version in tools -> boards -> board manager (just go back or forward in version)

For IDE 1.8.13, you can 'downgrade' the boards version to the same one as came with IDE 1.8.5 and see what happens. Or upgrade the boards version in IDE 1.8.5 and see what happens.

I do not have an explanation why just one sketch gives the odd result.

[anon73444976]

Global variables use 1462 bytes (71%) of dynamic memory, leaving 184 bytes for local variables. Maximum is 2048 bytes. That's just weird :o

[LukeZ]

TheMemberFormerlyKnownAsAWOL:
Global variables use 1462 bytes (71%) of dynamic memory, leaving 184 bytes for local variables. Maximum is 2048 bytes. That's just weird :o

My apologies, I was copying and pasting from the console window and messed things up, I have corrected it in the first post. It should have said (and did say) usage of 1462 (71%) leaving 586.

sterretje:
For IDE 1.8.13, you can 'downgrade' the boards version to the same one as came with IDE 1.8.5 and see what happens. Or upgrade the boards version in IDE 1.8.5 and see what happens.

Thanks sterretje for that suggestion. I was aware of the possibility of doing that, and have played with it, though not every possible combination. Many combinations give even worse results (allocating up to 98% of SRAM for global variables), some board versions fail to compile at all (with the same cryptic error message mentioned before). A few board versions compile with reasonable results (such as 1.6.20).

Is there somewhere available a record of which boards version went with which IDE version? I've looked on the Release Notes page but it doesn't seem to be there.

I should probably clarify my basic goal. As the developer on this project I have no problem using IDE 1.8.5 and indeed as a general rule I try to avoid the hamster wheel of continuous upgrades. The project compiles just fine on that platform and for me personally that is sufficient.

However, if a random new user comes along and thinks, "this is a cool project, maybe I will tinker with it," they are naturally going to download the latest version of the IDE, and then be stumped when the project doesn't work (it's almost worse that it compiles and runs on the target, but then some functions fail to work). So this leads to support requests. I can (and have) told them to use IDE 1.8.5, or I could tell them to downgrade boards, but obviously this is more hassle for the basic user and makes them wonder what kind of crummy firmware we've written that it doesn't work with the latest and greatest.

In short, I already have a functional widget, but making it as painless for other users to play with is the present difficulty.

As another data point of whatever worth, I recently discovered the 2.0 beta of the IDE. I compiled the sketch on that one and I get the same results as 1.6.10+ (back up to ~90% global variable allocation).