The Make Controller has quite a bit of memory onboard (at least in the microcontroller world) - 256K of Flash and 64K of RAM.  For those of us coming from an 8-bit microcontroller world, this sounds like more than you could ever know what to do with.  Of course, from the perspective of the desktop, this is squat. 

It turns out to be a pretty reasonable amount - you don't have to spend hours assembly-optimizing your code, but you do need to be aware of your memory usage as you create your programs.

Memory allocation

Memory has been the cause of many a bug in programs on any platform.  If you don't need to do dynamic memory allocation, the best advice is generally not to use it - just allocate whatever you need in your code and at compile time the linker will make sure you aren't overstepping your bounds.  In the cases where dynamic memory allocation makes sense, the Make Controller can do dynamic memory allocation in a way that will be familiar to C programmers - using Malloc and Free. This requires some understanding about pointers so if those aren't your strong suit beware.

Malloc will allocate a certain number of bytes for you, if they're available, when you ask it:

int bufferSize = 1024;
char *bufferPtr = Malloc( bufferSize );
if( bufferPtr != NULL )
  // then we allocated successfully

When you're done with this memory, you should release it using Free:

Free( bufferPtr );

The memory manager in FreeRTOS does not defragment any of the heap after memory is freed.

Malloc also has to pause the processor while it allocates memory, so if you're Mallocing and Freeing all the time, it will take a toll on performance.

Balancing the heap

Malloc allocates memory from the heap.  In your config.h you can specify how large the heap is by adjusting the CONTROLLER_HEAPSIZE constant.  You need to be aware of how much memory the rest of your program is using, then you can basically use the remaining memory for your heap.  For instance, the whole networking system on the Make Controller takes up a ton of memory.  If you're not using it in your project, you can reclaim all that memory for your heap to be used in your calls to Malloc. 

To get a sense of how much memory you're using, you can take a look at the map file produced during compilation. 

When you create new tasks, these are also allocated from the heap.  If you're going to be creating lots of tasks that require lots of memory, be sure to set your heap size large enough.

Memory (stack) for tasks

When you create a new task, you need to specify how much memory to allocate it.  This memory comes from the heap.  One of the most frequent issues I have personally when writing programs is running out of stack on one of my tasks.  This can be very frustrating because there's nothing that says, "Hey I've run out of memory I'm quitting now".  The memory just runs over into some place it shouldn't and things go haywire, seemingly with no explanation.  This is where you need to just take a deep breath, and allocate more memory to your task.

It's hard to really know in advance how many bytes you're going to need for your task.  But there are some things that will let us make educated guesses without going to all the trouble of caluclating the size of every piece of data we might use. 

Local (or automatic) variables are created on the stack of a task.  So, if you all of sudden say something like

char buffer[1024];

then you have to make sure you have more than 1024 bytes allocated to your task.  Some data structures are big and it can be easy to forget that when you're not actually writing out how many bytes they are, as in the buffer example above.  If you're calling into any other systems, be aware that they will almost certainly have some local variables that you'll need to account for.

Usually it's best to just give yourself a big hunk of memory to start with, and then start to whittle it down once your program is taking shape.

Big memory consumers

There are a few players in the Make Controller codebase that are notoriously big consumers of memory.  This isn't necessarily a problem - it's just good to be aware of them so that you can be an informed debugger!

• The network system.  By far the biggest consumer of memory.
• The web server.
• printf and snprintf.  Compiled under newlib, these functions end up requiring quite a bit of memory.  Use them with caution.