1

Can I use functions malloc and delete in embedded C? For example, I have one function, where was created pointer on structure with function malloc. This function return address in ram and I can use this . After exit from my function, where memory was allocated, this pointer will be deleted or this memory reserved for this, while not will be function delete terminated ? 

Typedef struct {
  Char varA;
  Char varB 
} myStruct ;

Void myfunc ( void) 
{
  myStruct * ptrStruct = ( myStruct *) malloc ( sizeof (myStruct)) ;
  // Code here 
  //........

  return ;    
}
Jabberwocky
  • 48,281
  • 17
  • 65
  • 115
Sauber
  • 33
  • 1
  • 4

3 Answers3

14

Generally, you shouldn't be using malloc in embedded systems, because doing so doesn't make any sense as explained here. In particular, it doesn't make any sense what-so-ever to use it on bare metal systems.

The only place where it makes sense to use dynamic memory allocation is large hosted, multi-process systems where multiple processes share the same RAM. If your definition of an embedded system is an Android smart phone or a portable PC, then yes it is fine to use malloc.

If you find yourself using it anywhere else, it almost certainly means that your program design is fundamentally flawed and also that you don't know how a heap works.

In addition, almost every embedded systems programming standard bans dynamic memory allocation.

Community
  • 1
  • 1
Lundin
  • 195,001
  • 40
  • 254
  • 396
  • 5
    Being "explained" elsewhere on the Internet does not make it true. The example you referenced is a system wuth 4kb of RAM. Not all embedded systems are of that nature. There are many reasons not to use dynamic memory allocation in *some* embedded systems, but you have to understand those reasons, and the constraints and requirements of your particular system to make an informed decision rather than follow some ill understood dogma. Moreover I would suggest "many embedded systems programming standards" rather the "almost all" - that would be hard to back up evidentially even if it were true – Clifford Oct 30 '15 at 16:50
6

There is nothing specific about embedded systems that prevent the use of dynamic memory.

However you may need to provide support for it in a number of ways, for example:

  • You need to ensure that the linker allocates sufficient space for the dynamic heap. Some linker scripts may already automatically allocate all remaining memory to the heap after stack and any other reserved allocations.
  • You may need to implement low level stubs to allow the library to access heap memory - for example in the newlib library, you need to implement sbrk_r() for malloc() etc. to work correctly.
  • In a multi-threaded system you may need to implement mutex stubs to ensure safe heap allocation. If the library does not provide such stubs, then malloc()/free() etc. will not be safe to use in such an environment, and you should write wrapper functions that assert the locks externally.

There are a number of reasons however why you might choose to avoid using dynamic memory (or at least standard library implemented dynamic memory) in an embedded system however:

  • Standard allocation schemes have non-deterministic timing unsuited to hard-real-time systems.
  • You need to handle the possibility of allocation failure gracefully for every allocation. Handling a potential non-deterministic run-time error safely is more complex than simply having the compiler tell you have insufficient memory at build time.
  • You need to guard against memory leaks; true of any system, but with no OS to manage memory exhaustion and kill a leaking process how will your system behave?
  • The standard library heap management may not be thread-safe without mutex stubs or wrapper functions.
  • Bugs that corrupt the heap are unlikely to affect execution immediately, often only causing an observable failure when a new heap operation is performed, resulting in non-deterministic behaviour at a time and location unrelated to the actual cause - making them very hard to diagnose. Again this is true of any system, but the debug facilities in a cross-hosted embedded system are often less sophisticated that on a self-hosted system.
Clifford
  • 88,407
  • 13
  • 85
  • 165
  • 1
    Also consider memory fragmentation. – Technophile Jan 03 '16 at 19:06
  • @Technophile : Ultimately fragmentation is a cause of both non-deterministic timing *and* allocation failure. I chose not to highlight it separately; what I have listed are issues of dynamic allocation rather the the causes of those issues. – Clifford Jan 03 '16 at 23:07
2

Yes, you can use malloc in embedded C. Some embedded systems have its own encapsulated memory allocation APIs. malloc() is the C lib API.

The memory is allocated from heap, a dedicated memory range defined by system designer. If you did not free the allocated memory after your function exits, the allocated memory is reserved and other processes cannot use it. Typically, it is memory leak. If you free the allocated memory but you still use the pointer after that, it is a wild pointer and will cause unknown behaviour.

Zhifei
  • 124
  • 5