The amount of RAM an application uses is printed out by the IDE at compile time. For applications that don’t allocate memory, this is a really good guide to how much spare RAM is available at run time.
However, if an application, like any using the Parola libraries, uses memory from the heap, you need to make sure that there is sufficient memory left for run-time memory allocation.
For reference, the different types of MCU memory and how they are used is described in this previous article.
How much RAM is enough?
To retain maximum flexibility in user code, the number of modules and zones is only fixed at application is run time. This also means that the total number of variables and buffers needed by both the MD_Parola and MD_MAX72xx libraries is only known then:
- MD_Parola allocates memory for tracking each zone. In version 2.6 that is to 41 bytes per zone.
- MD_MAX72xx needs to allocate one display buffer and one SPI communication buffers for each module, which comes to 11 bytes.
Therefore the total run-time heap RAM required for an application depends on the number of zones and the number of modules in the display. For the most common configurations, the total memory is given by the table below.
When to allocate RAM?
The other consideration is to minimize the possibility for heap memory fragmentation.
Both libraries allocate memory in the begin() method and free it in the class destructor. In most standard applications, the number of zones and modules does not change at run time. In this case, the best approach is to invoke begin() as soon as possible in setup() as the memory will, effectively, never be released.
However, if the displays are more dynamic and the number of zones will be changed during run time, then the begin() method should be invoked as late as possible in the setup() or even after, as this will ensure that the heap memory used is closest to the unallocated heap, giving the freed RAM the best chance for later re-use.