Understanding what's in a binary / reducing memory footprint
While developing M5ez the memory usage jumped up at a few points without me properly understanding why. Can anyone point me to tools to better understand what's in my binary and possibly how to make it smaller?
I can use a debugger on your code to see what's using the memory...
You can't use a jtag on M5Stack but you can make a setup similar to M5Stack and you can debug the code on that one.
Yes please... I'd love to know what the memory footprint of M5ez, let's say when running the demo program, is made of.
- The images stored as array, take considerable space on the project.
- I recommend you to switch to PlatformIO for development.
That IDE will give you a better look over the code objects and tier size. Just check the ".pioenvs" folder on the project.
You can easy convert the code from PlatformIO for Arduino "IDE" .ino if you want to.
- avoid using "main" keyword on your code. Beginners may misunderstand that coding practice.
- avoid using preprocesor for class instances. Use "M5.Lcd.xxxx" instead "m5.lcd.xxxx".
In some cases, it can save some ram this way (i know... is weird).
The list of components running on demo project is long... and you don't have control on all of them.
Most of them are from the framework. Arduino on its own is a memory hog:
The ez on itself don't use that much memory.
Here are the ez members that always reside in ram:
Beside those, there are M5 members, tft_eSPI members, Wifi members (that take a lot of space) and so on...
Those are the components with the most memory usage.
Here is a dependency graph for the demo project:
I tried PlatformIO and didn't like it, maybe I should have tried longer. But if you're making something to be this easy to use, the Arduino IDE is where the users are, so I would always create for it as the primary way for people to use it.
I know the JPGs take up space in flash (but 1 byte per byte, not more than they need, right?) I'd also like to know what the space in the compiled image is used for, can you also list that? There were some weird jumps in how big the image got while I was developing.