I know there are gobbles of RAM in a PIC32 (more than the entire FLASH bank in most other PIC16/18… ) but RAM is one of those things in life you can never have enough of!
Plus, I am an 8-bitter by education, as I have already acknowledged before, and having spent most of my professional life working on microcontrollers with very limited resources, I am very sensitive to waste and waste of RAM in particular.
If you check the memory gauges in MPLAB, even an empty PIC32 program with no function calls and practically no code at all in the main(), will give you a minimum memory usage of 1.5K bytes of RAM. To me that’s huge! I need to know where all this RAM is going and how I can control it should I need it all!
The mystery is easily solved, if you look at the .map file, it shows that 1k byte of that RAM is just the default amount “reserved” for the stack. As we have seen before (the stack so misunderstood…) the way MPLAB manages the stack memory allocation is a bit tricky. By the way, that memory is not literally allocated, nor the SP register is affected directly, but this number is used at compile time, only once, to check if , after allocating all the global variables and the heap (if there is one), there is still room for the requested amount of stack. So it shows in the memory gauges, but it is not representing by any means the “real” amount of RAM that will be used by your application stack, nor the maximum amount available. In fact the stack will take all the memory left and some… if it needs to.
But where is the other 1/2k byte of RAM gone?
Again a careful memory map inspection will reveal that the stdio library is responsible for it and in particular it seems to be used for the stdin and stdout streams buffering. But wait, we said our application was “empty”, a smart linker should know better than to include pieces of libraries that are not directly called by our applications!
It turns out that it does (know better). In fact, even if we don’t call any function using the stdin or stdout streams in our application, there is one place where those are called into play anyway. It is in the default start up code (often referred to as crt0 or simply c0) and in particular in the “shut down” portion of it that gets called once our application terminates.
Luckily, as most such default functions in the MPLAB C32 libraries, they are defined as “weak” so that we can provide our own exit() function to override the default implementation saving both code space and that last chunk of data (RAM) space.
Whether we are using the standard I/Os or not, this stub implementation can save about 1 KB of code space and the remaining 520 bytes of RAM we were looking for.
Just add this function to your project.
void exit(int status)
{
while(1);
}
Feeling better already!
(P.S. Thanks Jason)
