Skip to content

Recipes for configuring size / memory usage #480

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
PaulStoffregen opened this issue Oct 24, 2019 · 3 comments · Fixed by #1211
Closed

Recipes for configuring size / memory usage #480

PaulStoffregen opened this issue Oct 24, 2019 · 3 comments · Fixed by #1211
Labels
conclusion: resolved Issue was resolved topic: code Related to content of the project itself type: enhancement Proposed improvement

Comments

@PaulStoffregen
Copy link

Please consider making the memory usage summary more configurable with recipes in platform.txt.

Currently arduino-builder assumes there can be only 2 memory regions. The 2 names are hard-coded. The 2 maximum sizes come from prefs in boards.txt.

Some hardware has 3 or more distinct memory regions. I am current struggling with this problem with the latest Teensy board, where combining 2 regions together to fit into a single line causes a lot of user confusion when they try to use memory that Arduino's size summary leads them to believe should be available, but actually isn't... but appears to be free, because of the necessity of shoehorning multiple regions into builder's limited size summary.

Hopefully arduino-builder could someday recognize a group of rules like this:

recipe.size.name.mymemory="External RAM"
recipe.size.regex.mymemory=^(?:\.bss\.extram|\.data\.extram)
recipe.size.maximum.mymemory=131072

This should cause builder to print line of text like this:

External RAM uses 24412 bytes (19%). Maximum is 131072 bytes.

Or if a 4th rule gives a name for the use of leftover space...

recipe.size.name.mymemory="External RAM chip"
recipe.size.leftover.mymemory="special buffers"
recipe.size.regex.mymemory=^(?:\.bss\.extram|\.data\.extram)
recipe.size.maximum.mymemory=131072

Hopefully this 4 rule case could cause line like this to print:

External RAM uses 24412 bytes (19%), leaving 106660 bytes for special buffers. Maximum is 131072 bytes.

Alternately, if this is too much trouble, perhaps a rule could be added to simply run a program which will generate the size summery and builder would skip printing its limited-to-2 regions summary?

@facchinm
Copy link
Member

I love the idea! It could be included in next arduino-cli sprint if it gets enough traction.
In the meantime, adding -Wl,--print-memory-usage to ldflags could help reporting more useful statistics (maybe). Let me know if it works 😉

@cmaglie cmaglie transferred this issue from arduino/arduino-builder Nov 11, 2019
@per1234 per1234 added the type: enhancement Proposed improvement label Jun 12, 2020
@PaulStoffregen
Copy link
Author

@facchinm - Any chance I could talk you into adding a raw unfiltered size recipe? If a platform defines "recipe.rawsize.pattern", just run the program and use whatever it prints to stdout as-is. No regex matching, no size checks, just copy its message to the output for a user to see. And of course if the command returns a non-zero status, consider than a fail as if the normal size check fails.

I tried to accomplish this is a postbuild hook.

recipe.hooks.postbuild.1.pattern="echo" "just show this as the size message, without regex processing"

But the problem is the user never sees this message in non-verbose mode.

For now, I really need a way to show more detailed size info than the 2 regex approach can handle. I really don't want to add yet another patch to the Java IDE, but I just don't see a way to replace the size process that works in all modes.

@cmaglie
Copy link
Member

cmaglie commented Mar 4, 2021

@PaulStoffregen I've drafted an implementation, let me polish it a bit so I can open a PR and we'll further discuss it there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conclusion: resolved Issue was resolved topic: code Related to content of the project itself type: enhancement Proposed improvement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants