use of malloc in embedded c

Question

In embedded c programming language. Is malloc useful in single task embedded system?

I am working since 0.5 years in embedded system. I never used malloc in 8-bit controller programming.

can anybody suggest me to use malloc in 8-bit controller programming?

Solution 1

In embedded systems the use of dynamic allocation is strongly discouraged. Behavior of the critical systems should be deterministic. Many libraries and OS for embedded firmware avoid using dynamic allocation.

For short explanation why malloc is not good for embedded systems see: malloc sins

Standards for critical systems may prohibit the use of malloc as a bad programming practice.

For example MISRA C1 and MISRA C2 do not allow the use of malloc/calloc. See MISRA standard.

Q&A: dynamic memory allocation - MISRA Bulletin Board

Solution 2

No it is not useful. The whole purpose of malloc is to let multiple processes share all available RAM memory of the system dynamically, when they have need for it. This in turn implies that you have a multi-process system and that the amount of available RAM is vast, but also variable or unknown.

In smaller embedded systems that are either "bare metal" (no OS) or use a RTOS, such memory sharing does not make any sense. Unlike a PC, such an embedded system is completely deterministic and therefore you always know the amount of RAM needed for the worst case. You also know exactly how much RAM there is on the chip.

The need of using malloc on such systems typically originates from confused PC programmers who have picked up embedded programming without studying it first.

Details here.

Comments

[Eugene Sh.]

It can be used. But since you are working 5 years in embedded you should know the downsides of it.

[V. Kravchenko]

When you have all memory available in single task OS you can just like access all of your memory without allocating and deallocating it. If you want to write at some memory place, just get it and write to it.

[Eugene Sh.]

@V.Kravchenko Well, that's not a very good approach.. We are C programmers, not assembly. And the use of dynamic allocation has little to do with being single or multiple tasks.

[infixed]

malloc comes with a price. You'll need to worry about testing for fragmentation and garbage collection problems during long terms of execution. If you can allocate your memory structures at compile time you'll be less chaotic.

[Jabberwocky]

You have never used malloc in 5 years on your 8 bit controller, that suggests you didn't need it and this partially answers your question.

[Lundin]

@EugeneSh. malloc is a specialized function designed to handle a .heap segment. You won't even have that segment in most embedded systems. Indeed you should use some manner of static allocation instead, or possibly "alloca"-like functions that use the stack.

[Eugene Sh.]

@Lundin It doesn't have to be "heap" per se. You can have a static array representing your memory pool and a "dumb" malloc just running a pointer along it with the same semantics as the "classical" malloc.

[Eugene Sh.]

@Lundin But how would you allocate the exact memory if you have a variable input? You can allocate the maximum memory you believe will do, but not the exact.

[infixed]

I think that malloc can be useful in single thread applications where the program is creating memory objects of variable size. Say for instance saving strings. If you can allocate variable sized blocks out of your free memory pool, you can create more objects than if they are all of a fixed size. But it does leave you with worries about fragmentation and garbage collection and memory leaks.

[LPs]

@infixed On an embedded target with limited memory you should always profile it starting your design. Using malloc it is only a (waisting resorces and cpu time etc...) feature that make the life easier for the coder, in first instance. Not sure for debuggers and testers. ;)

[Lundin]

@infixed There exists no case where you would have a "memory object of variable size" in a deterministic embedded system. There must always be an upper limit. You must design for the worst case, you must have enough memory to handle to worst case, and that's it. See the post I linked.

[Lundin]

Such standards never get to the bottom of why it doesn't make sense in embedded systems though. MISRA-C is nowadays a generic programming standard, possibly used outside the embedded systems branch, so it just says that heap allocation is dangerous because of leaks, segmentation etc. (Also note that there's a new MISRA "C3" out, formal name is MISRA-C:2012).

[Lundin]

@infixed Summary: if you actually know what you are doing, you will get much more efficient programs than if you blindly call malloc without a clue about what it actually does. The latter is a PC programmer mindset and will only cause sorrow and pain when designing embedded systems. You must have complete and utter control over how much memory your program uses, period. Delivering firmware that may suddenly run out of memory isn't professional engineering, that's just quackery.

[infixed]

@lundin. You know that hierarchies of storage speed and tradeoffs is not a new concept. Nobody advocated blindly calling malloc. As embedded system grow more capable they are moving into realms that regular systems were operating at not that long ago. Maybe you want to have your deterministic system that does things like, for example, going out over SPI to fetch the same data from a SD card each time that data is used, instead of caching it in RAM. I don't. Yes one has to deal with the worst case. That does not mean you have to live in it 100% of the time

[Clifford]

It is neither the whole, only or even primary use of malloc. You cannot be quite that emphatic about its usefulness or otherwise. Usefulness and advisability are not the same thing.

[Chris Stratton]

The number of tasks really doesn't have much to do with the possible utility of dynamic memory allocation - rather, that variability of data and conditions does. Dynamic memory (re)allocation definitely has its dangers, but just because there is only one task that owns all the memory doesn't change the need to design how it is used - nothing says you have to have an operating system to have a malloc(). Static allocations are indeed safest - but there are ways in which using dynamic memory to respond to variable conditions when possible can be sensible, too.