Sometimes you really need a steaming heap of… RAM.

Who would have thought of something as boring as a replacement for a math library? But we embedded people often face real-time constraints, and GoFast can be a lifesaver. It's cheap, too.

What about heaps? Really boring, right? Hey, we've got malloc and all of that built-in, why worry about a heap replacement? Well, Micro Digital did and just released eheap. It's quite a fascinating product, and even if you don't need a heap, or are happy with that which comes with your compiler, I recommend reading chapter 5 of the user's guide which describes the problems and the product. (eheap's source code and manuals are available here: http://www.smxrtos.com/eheap/?utm_source=Micro+Digital+Announces+eheap&utm_campaign=eheap+PR&utm_medium=email).

Now, whenever I write about heaps readers complain that Real Developers Don't Use Dynamic Memory Allocation. After all, it can lead to all sorts of problems like memory fragmentation. But some of us live in a world where RAM is in short supply and there are few alternatives to malloc and free. Alternatively, some RTOSes offer other ways to manage limited RAM. But heaps are a real part of the embedded space. Some developers have to live with them, and eheap offers some intriguing features to minimize malloc's problems.

First, an aside: I never, ever see code that tests malloc's return value. If it fails, it will let you know. There's not a whole lot one can do about it as, other than a reboot, it's hard to know how to handle an allocation failure. One option, in a multitasking system, is to suspend the task for a while and retry. With luck, another task may free some memory. This is somewhat dangerous as it could mean the system is running right on the edge of RAM availability.

eheap, on the other hand, is "self-healing." As the manual notes about the supplied smx_HeapRecover function: "It searches the heap to find and merge adjacent free chunks, in order to create a big-enough free chunk to satisfy the failed allocation." An example from the manual:

while (1)
{
  if (bp = smx_HeapMalloc(size))
    /* use bp */
  else
    if (!smx_HeapRecover(size, 20))
    break;
}
/* try another heap recovery action */

The argument (20) permits pre-emption every 20 chunks. eheap offers another option: a function that will extend the heap. Now, I'm not quite sure how valuable this would be; if there's memory that could be available for the heap, why not use it from the git-go?

A function is provided to sort memory bins to improve performance. The idea is that a lot of systems have built-in idle times; call this function when there's nothing else to do and the system's real-time response will get better.

Unlike some other dynamic memory allocation schemes, eheap is completely thread-safe.

eheap comprises a couple of thousand lines of well-documented C code (and they even got the license right, per my suggestions here: http://www.embedded.com/electronics-blogs/break-points/4441421/On-comment-headers). It's free for evaluation and non-commercial work, and is $2k/product for commercial users. The concepts behind eheap are fairly complex and tremendously interesting – I suggest even for those with no interest downloading the manual and reading the section on heap theory.

Published March, 2016