Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Memory/Storage
 
 
Memory/Storage  

Understanding dynamic memory and heap contiguity

Posted: 11 Jul 2013     Print Version  Bookmark and Share

Keywords:software  memory  determinism  RTOS  MMU 

Any type of software requires memory to store data. How much data is stored, how it is accessed, and the processing performed on that data can vary greatly from one application to another.

In a desktop system, the approach to programming assumes that the system has infinite resources (memory) and that human intervention is a possibility. But most embedded applications have limited resources and may be deeply embedded, which means they need to be entirely self-sufficient.

Data storage
Broadly speaking, in C/C++ data can be stored in three ways:
1. In static memory, where the storage is allocated at build time. Variables defined outside of functions are intrinsically static. Inside a function, variables may be directed to static storage using an explicit static declaration.
2. On the stack or in a CPU register. Variables defined inside functions are stored in this way by default.
3. Dynamically allocated and de-allocated, as required. This allocation and de-allocation is performed using the library functions malloc() and free() in C or the new and delete operators in C++.

The heap
The heap is an area of memory set aside to provide dynamically allocated storage. It is managed by the library functions malloc() and free() in C or the new and delete operators in C++. The size and location of the heap are application dependent and the means by which it is allocated is specific to a particular toolchain.

Figure: Heap utilisation.

Dynamic = bad
When designing embedded software, if there is a choice between doing something statically or dynamically, the former should always be the first choice. This is because there are two distinct issues with most dynamic activities, such as resource allocation:

 • Determinism
 • Failure mode
Many, if not most, embedded applications are required to exhibit real time behaviour. A key factor in achieving this goal is determinism – the predictable timing of a process. Dynamic memory allocation is typically non-deterministic. Although, as we shall see, this can be overcome.

As mentioned earlier, most embedded systems do not have a human operator who can make a decision if an exceptional event occurs. On a desktop computer a message of the form: "Blah blah not available. Please try later" may be inconvenient; on an embedded system it is probably not an option. Think heart pace-maker or automobile engine management unit.

Limitations of malloc()
The standard C library functions (and C++ operators) exhibit all the features that support the "dynamic = bad" rule. A normal malloc() implementation is not deterministic, which means that its use should be avoided in real time code. If a memory allocation is attempted and insufficient heap space is available, a NULL pointer is returned. This can be detected and evasive action taken, but this may be complex to implement.

Running out of heap space is an unsurprising failure mode. In theory, at least, a facility could be provided to show how much space is available. This would enable a failure to be predicted and possibly avoided. However, this does not take fragmentation into account.

1 • 2 Next Page Last Page



Comment on "Understanding dynamic memory and hea..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top