next topic »

[on:]

It would be nice to have the output of avr-size after a correct compilation.
and why not with some simples calculations ?
Example : Ram usage (in %), EEprom usage (in %), ...

This "simple" print (It is simple to say it, but not allways simple to do it  ;-)
could avoid some headaches :
A couple of days ago I fall in a mysterious bug, it took me some days to find the issue.
(in my sketch there were too much serial.println).
the solution was on the forum (use PROGMEM instead) I was stupidly thinking "the compiler do not use ram for thoses println", off course I was wrong ...

I would like to thank's all folk working on this great project !

[Reply #1 on:]

The problem is that you can not know the RAM usage until a program runs. You would have to simulate the operation of the program and make sure that every branch was taken to even have an accurate guess of the function return stack in RAM. Sounds like a good idea but it is not practical.

[Reply #2 on:]

It would be nice to have the output of avr-size after a correct compilation.
and why not with some simples calculations ?
Example : Ram usage (in %), EEprom usage (in %), ...

I think this would make an excellent supplement to the flash usage we get today. This is an easy extension to add, useful to just about everyone programming Arduino's and a good indicator as to where we're heading in terms of free RAM or lack thereof.

[Reply #3 on:]

Did you not read my post? Yes it would be nice but, you can't say what the RAM usage is at compile time.

[Reply #4 on:]

Did you not read my post? Yes it would be nice but, you can't say what the RAM usage is at compile time.

You seem to reject the idea as being "not practical" and this triggered my post.

Using avr-size, we can extract allocated size for flash, RAM and EEPROM from the program image. Displaying all three rather than flash alone (as is done today) would make a useful and welcome extension. It is not the full answer to runtime RAM usage, but far better than nothing (which is what we currently have).

[Reply #5 on:]

but far better than nothing

I would disagree, I think giving a false figure for ram usage is more misleading for a beginner than giving no usage at all.

[Reply #6 on:]

There is nothing false about this as we get an exact figure for total pre-allocated global and static RAM across the full application. The rest is what is available for dynamic runtime use and so is a good measure on how far we're from disaster.

This figure is useful for anyone (skilled or not) and would help visualize the RAM impact of declaring large arrays, adding libraries, declaring constants,  the benefit of using PROGMEM and generally educate users about one of the more challenging aspects of embedded programming.

Insisting on not knowing seems like a good recipe for disaster.

[Reply #7 on:]

The point is that the meaning of the information given by whatever tool must be clear and unambiguous.

If the meaning is not clear or not given at all messages are (wide) open for misinterpretation => Mike's statement (and I agree, seen too many disasters due to misinterpretation).
If there is no message to interprete, people can ignore the absence - most will do just that - or try to figure out what the figures could be. They start thinking for themselves and they will gain a healthy skeptical attitude towards any message

On the other hand if we change the output to include this information about memory usage (which I think is really usefull) , an appropiate explanation must be added as well to prevent the above mentioned misinterpretation.

A first try how it could look.

Memory usge:  Flash: 20K of 32K - EEPROM 32 of 1024 - RAM: 400 of 2K
Note: EEPROM and RAM represent compile time allocations, runtime will allocate unknown additional EEPROM and RAM.

Please post your ideas how the final message should look like including the explanations so it becomes clear for everyone.

[Reply #8 on:]

There's a patch attached to http://code.google.com/p/arduino/issues/detail?id=395
(I don't know whether it still applies to the source base.)

While it won't tell you for sure whether your use of stack and heap will cause you to overflow RAM, it at least gives you an idea of how close your are just from static (data + bss) usage.

[Reply #9 on:]

Memory usge:  Flash: 20K of 32K - EEPROM 32 of 1024 - RAM: 400 of 2K
Note: EEPROM and RAM represent compile time allocations, runtime will allocate unknown additional EEPROM and RAM.

Please post your ideas how the final message should look like including the explanations so it becomes clear for everyone.

The message seems to be clear for newbies. :-)

Others Ideas :
A wiki page describing the memory usage in the reality would be a plus
(like the discussion here) with difference between the hard coded and the dynamic allocated memory. Maybe with a good idea of stack memory usage...

A warning before uploading if size of memory usage > 75% of memory
(off course this could be set in the preference file)