How much memory can my application use?

I had a Vic-20 as a 12 year old and tried writing games in basic … they were simply too slow so I started looking at speeding sections up (in particular the drawing functions) and hence learned about these cool processors.

Have a look at the KIM-1 (probably the first ‘hobby PC’ To think they had a chess game running on it!

1 Like

Has no one linked to this yet?

The best way to get a real # is to ask your software while it’s running on the Arduino… of course this is only a ballpark also, but it will take into account stack (at call time), heap (static-ish variables), and dynamic allocations. If you had a deep function tree then calling it at the BOTTOM (innermost function) and printing that # should give you some idea of your “worst case” memory pressure. (still have to account for interrupts and such, but it would be close to as accurate as you’re going to get)


But I also fear that questions like this are often coming at it from the wrong angle. You should design to use as LITTLE ram as possible, to allow for the unexpected - that’s why the default warning is the way it is. I’ve seen too many sketch people thinking it’s “cool” to get their sketch to exactly 100% flash and then a new library version comes out - a bug is fixed - or the Arduino IDE updates and now their stuff doesn’t work at all. (won’t compile, because it’s too large). Always best to play it on the safe side.

You run the same risk with memory if your goal is to push the limits… you might quickly run into a case where your stuff works today but then a change in the library or toolchain renders your app unworkable. Of course distributing just a compiled binary is one solution to this problem… but we don’t seem to quite be there yet from what I’ve seen.

Generally I just try and keep an eye on the RAM the compile system reports, avoid deep nesting, avoid recursion… and stay away from dynamic allocation (although it sometimes has it’s uses).

I agree. I have taken great pains to reduce the RAM usage of my application and have got it to a point where there is plenty available at run time for the game to work properly and to absorb any library or IDE updates.

Agreed but this is the challenge in an environment like Arduboy - trading off features in a game or other programme against RAM usage. Strip it right back and the game can be pretty lame - add features back in and you start hitting the RAM limits.

Agreed, as you can see I write down each compile report and compare the changes I am making to the previous one. This gives me an idea of what is expensive in terms of RAM and progmem and what is efficient.

1 Like