Skip to content

Display RAM usage #121

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nseidle opened this issue Feb 3, 2020 · 3 comments · Fixed by #283
Closed

Display RAM usage #121

nseidle opened this issue Feb 3, 2020 · 3 comments · Fixed by #283
Assignees
Labels
enhancement New feature or request

Comments

@nseidle
Copy link
Member

nseidle commented Feb 3, 2020

If possible, it would be nice to display RAM usage at the end of successful compilation. Not sure if it can be supported. Looks like the other M0 based Arduinos don't output RAM usage.

After some initial googling it looks possible but I figured Kyle would be much faster to implement than me bumbling around platform.txt.

@oclyke
Copy link
Contributor

oclyke commented Feb 3, 2020

Should be easy, but of course it is not...

Arduino's 1.5 3rd Party Hardware Specification defines a 'recipe' to query the size of the application. For Apollo3 we use:

recipe.size.pattern="{compiler.path}/{compiler.cmd.size}" -A "{build.path}/{build.project_name}.axf"
recipe.size.regex=\.text\s+([0-9]+).*

So we are identifying the size of the .text output section of the .axf file using a regular expression search on the output from arm-none-eabi-size (which is Arm's implementation of the GNU 'size' tool). The output from that tool looks like this:

arm-none-eabi-size -A /var/~/arduino_build_513313/Blink.ino.axf
/var/~/arduino_build_513313/Blink.ino.axf  :
section             size        addr
.text               8280       65536
.stack             81920   268435456
.data                 52   268517376
.bss                3048   268517428
.ARM.attributes       55           0
.debug_info       250945           0
.debug_abbrev      22812           0
.debug_aranges      2448           0
.debug_ranges       3280           0
.debug_line        45323           0
.debug_str         58728           0
.comment             126           0
.debug_frame        5920           0
.debug_loc         30936           0
Total             513873

The size of the data section is a pretty good indication of the amount of RAM used initially (because of course it can't predict dynamic memory usage).

So ideally we could just use something like:

recipe.size_ram.pattern="{compiler.path}/{compiler.cmd.size}" -A "{build.path}/{build.project_name}.axf"
recipe.size_ram.regex=\.data\s+([0-9]+).*

However Arduino just doesn't seem to provide any such hook.

The closest thing might be the recipe.hooks.objcopy.postobjcopy.NUMBER.pattern hook but there still remains the challenge of calling the size command, searching the output for the size of the .data section, and finally communicating that to the user somehow.

On *nix we might be able to write a one-liner to do that with echo and sed. But I don't know of any built-in (guaranteed) tools that do the same in Windows.

So we need a method to handle this in a cross-platform sense. Two options come to mind: (ehh, come to think of it they sort of rely on one another so this is just one option)

  1. Python. Generally a pretty good cross-platform scripting option.
  2. Package and distribute binary executables for each host platform like we do with the uploader. Then the hook becomes:
ram_size_getter.args = {build.path}/{build.project_name}.axf
ram_size_getter.pgm=ram_size_getter_bin # default for non-windows platforms
ram_size_getter.pgm.windows=ram_size_getter_exe # for Windows
recipe.hooks.objcopy.postobjcopy.0.pattern={ram_size_getter.pgm} {ram_size_getter.args}

So that's my 2¢

@stephenf7072
Copy link
Contributor

stephenf7072 commented Jul 23, 2020

Linking to a similar issue (calculation of SRAM in use during running) which may help close this one: #205

@Wenn0101 Wenn0101 added the enhancement New feature or request label Oct 12, 2020
@oclyke oclyke self-assigned this Oct 12, 2020
@oclyke oclyke closed this as completed in 54cb510 Oct 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants