Pilot's Logbook

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?

Continue reading →

I think I can say we all love the little Memory Usage gauges introduced in MPLAB a couple of years ago.. or was it more?

When working in assembly with an 8-bit microcontroller and a couple of Kbytes of FLASH memory they definitely do their job, but when using the PIC24 or PIC32 type of devices, the memory space grows into the hundreds of Kbytes and things get … well, more complicated!

You start including a stack here (USB?) and a library there (Advanced Graphics), the compiler throws in a couple library modules of its own (math libs, stdio…) and both FLASH and RAM spaces become a little more crowded. It does not take long before we start wondering who is using up more memory, and why… the little memory gauges just don’t cut it anymore.

The experts will tell you right away that the sensible thing to do is to turn on the “map” option of the linker, (Project Build Options, Linker Tab, Select Diagnostics pane, then Check Create Map file) and inspect the resulting .map file in the editor window.  But the text file generated is a pretty complex (and long) document and browsing through it in search of clues about what happened to our program and data memory can be quite hard work.

Fortunately with the latest version 1.05 of MPLAB C32 compiler there is a new  option for the linker to produce a detailed summary of your project memory usage: –report-mem. Continue reading →