- 17. January 2012: Atypical Curiosity
- 4. January 2012: PIC32MX7 PIM, RB5 pin conflict (solved)
- 30. December 2011: MikroE Mini-32 Board
- 29. December 2011: Donate to Wikipedia
- 28. December 2011: PIC32 Interrupt Nesting (update)
- 20. December 2011: Graphics Library 3.02
- 2. December 2011: Home Brewed IDE for PIC32 assembly development
- 30. November 2011: Yoda Conditions, Egyptian brackets and more...
- 9. November 2011: AVI Player Project (for the uMMB)
- 21. March 2011: More Multimedia Boards
- January 2012
- December 2011
- November 2011
- March 2011
- February 2011
- January 2011
- March 2010
- January 2010
- December 2009
- November 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- January 2009
- December 2008
- November 2008
- October 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
Where is my RAM?
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)
Leave a Reply
You must be logged in to post a comment.