Group Actions
Engagement
  • Author Author: e14 Contributor
  • Date Created: Date Created
  • Views 5056 views
  • Likes 1 like
  • Comments 13 comments
Related
Recommended

Arduino: Dynamically allocating and freeing memory

e14 Contributor

Everything that happens on a micro-controller has to be known. This includes dealing with memory. Many people (myself included) have developed a wonderful set of code that can dynamically use and free memory through the standard malloc and free functions. Only later do we discover that our available memory is getting reduced as time goes by -- followed by undetermined and random failures.

 

This is because no microcontroller (the ArduinoArduino included) has the ability to garbage collect.

 

For instance, let's say you malloc A and then malloc B. You then free A. There is now a memory hole (the size of A) that will never be closed again. Essentially a non-existing A is now taking up memory. If you now malloc A again, it will not be stored in that hole -- new memory will be taken up. You can see how this can become a problem.

 

To solve this problem, I developed the library ReMem (Reusable Memory), located in my usertools library, which among other things contains a full featured User Interface.

 

Documentation of ReMem can be found here. Basically ReMem creates an object (with a specified size) that has two functions: rmalloc and free. These work exactly the same way as the conventional malloc and free except when you free data, it will be used again if the same size data is requested. (The disadvantage is that it can be slow, and takes an extra byte of data per malloc).

 

 

Upcomming

The code is currently stable, but I'm going to be adding the ability to reclaim data that has been freed at the end, as well as cannibalize large allocations. Stay tuned.


Update

I have a new, more tested library for this purpose called tinymem. Check it out here: https://github.com/cloudformdesign/tinymem

  • I must admit, this is an odd discussion. Ordinarily for an embedded application (e.g. using an Arduino), variables are stored on the stack. How often does one need to use malloc on a constrained microcontroller like Arduino uses? What little memory you have will be used up partitioning it for all the processes that need to run on it (and let's face it, the usual tiny little kernels that are intended for microcontrollers allocate the same amount of memory for all processes, so there is enough waste there that one really doesn't want to waste yet more with a flexible malloc as enjoyed with Linux. Instead, the software designer can just think carefully about what global storage may be needed, and what can be placed on the stack safely. Furthermore for embedded systems one usually knows how many processes will run, and their memory needs.

     

    In other words, the specific restrictions of an embedded system running on a processor with such limited RAM must force one to think carefully anyway about what data is stored and where; I can't ever imagine using malloc for such a system. Surely it must be a very rare circumstance that an Arduino user would ever need malloc?

  • in reply to clem57

    tinymem has very little overhead (50bits per pointer). There are many reasons that you might need dynamic allocation -- many things simply are not possible without it.

     

    Do you have a link to the "stack" implementation you are referring to? FIFIO is often not enough for complex applications.

  • in reply to e14 Contributor

    Per your link:

    My general rule for embedded systems is to only malloc() large buffers and only once, at the start of the program, e.g., in setup()

    So any use of library (malloc) is not justified when RAM is under 64K. Why incur the overhead. Right? My stack question is a mechanism for first in last out needs and not just function calls. There are many classical designs that would nicely use this.

    Clem

  • in reply to johnbeetem

    On a linux system with a memory manager it does, but on embedded systems this is most definitely NOT the default behavior. How could it be? Some systems have less than 500 bytes of RAM, where would they store pointers to all the free blocks?

     

    Here is a stack-overflow link for the Arduino in particular: http://arduino.stackexchange.com/questions/682/is-using-malloc-and-free-a-really-bad-idea-on-arduino

     

    I have looked at how linux systems do it, and most of them work by allocating memory to programs in large "chunks", 4kB is pretty standard, and then using compiled indirection like you say. This implementation will also not work for embedded systems for obvious reasons: there are not many "4kB chunks" for a system with between 2kB and 64kB of RAM, and adding compiled indirection for a broad range of microcontrollers would probably be difficult.

     

    Also, it is worth noting that tinymem uses indirection, just not in the manner you suggest -- which as you suggest would lead to huge speed-downs in addition to inefficient memory consumption.