FreeRTOS Dynamic Memory Management (STM32F4)

[ssmail]

Posted on August 19, 2015 at 18:42

Please see attachment .pdf to see the content I excluded for brevity. 

I have a project with various communication stacks. Messages arrive through one port, and may be processed locally, or routed to another port. Additionally messages may be generated locally and sent to a port. These messages vary significantly in size, with most being less than 64 bytes, but occasionally there will be a packet approaching 1024 Bytes. However, the sizes may be any ware from 1 to 1024 bytes.

I am trying to understand if FreeRTOS supports a fragmentation-safe feature for passing these variable-length packets between threads and between ISR and thread.  For example, is it possible to use malloc() in conjunction with Message Queues (with the producer passing a reference to the allocated memory) without fragmentation concern.

I see in the Heap_4.c source code that it, �combines (coalescences) adjacent memory blocks as they are freed, and in so doing limits memory fragmentation.� However, this still concerns me because my product may not be reset for months of run-time. It seems very difficult to test if the coalescence scheme is effective enough.

I was considering the scheme described here �

http://www.barrgroup.com/Embedded-Systems/How-To/Malloc-Free-Dynamic-Memory-Allocation

� which I�ll paste below:

  [See attachment For this content]

I�ve read the �Memory Management� documentation of FreeRTOS �

http://www.freertos.org/a00111.html

� as well as skimmed the source code, but I am not confident that the heap implementation will meet my requirements.

I will paste �Memory Management� documentation below as well.

  [See attachment For this content]

 

Questions:

1)

Am I correct in my assessment that that the FreeRTOS heap implementation is not fragmentation-safe?

� and if yes �

2)

Is there a �typical/canned solution� for this issue that can be implemented �on top� of FreeRTOS/CMSIS? E.g. the Memory Pool scheme.

See also:

http://asf.atmel.com/docs/latest/uc3b/html/group__membag__group.html

#freertos-heap-malloc-fragmentati

[Tesla DeLorean]

Posted on August 19, 2015 at 19:48

Absent the ability to change someone's allocation that they currently hold, all dynamic allocations tends to have issues with fragmentation, or resource leaks.

If you're holding the buffers very briefly and releasing them, any system that coalesces or folds the released memory should be fine. The problems occur if you have an allocation that's not freed up, or held significantly longer than the transient ones.You probably need to better understand your packet sequences and model things. If everything is handled and released in order, you could use a large buffer and roll through it like a FIFO. This is how a lot of Ethernet controllers have typically worked.If using pools, you need to be clear what your total allocation needs to be, and the mix. ie whether you need 64, and 1024 byte pools, or if you need some 128, 256 or 512 ones too. These need to be data driven choices, based on how you see things arriving, the rate, and how quickly/efficiently you clear them. If things are going to have a significantly longer life, you'll probably need to move them into other structures where the size and update rate is better managed.Memory Allocators have to be a huge CS topic, there's got to be plenty of examples, and illustrations, that could be plugged into all manner of OS and RTOS with a little thought.Instrument what you have, understand the nature, and time, and the peak requirements. Be able to determine if you have leaks, who made them, along with your total used and free space, and how fragmented the arena is. If malloc() returns NULL have the system fail gracefully, if the problem is temporary at least it can recover. Understand what allocations are critical, and ones that will just cause data to be resent. Consider having different memory pools for things that can't fail. If your system does have to fall over and die, be prepared to output some useful diagnostics about how it got in that state.

[ssmail]

Posted on August 20, 2015 at 20:35clive1,It seems to me that pools may be a good trade-off between memory usage and fragmentation risk. Also, it lends itself well to diagnostics. For, example, there could be high-water marks for each pool size.Also, barring a memory leak bug I don't think any allocated memory should exist for more than a second.I found another article on Memory Pools here:

http://www.drdobbs.com/embedded-systems/embedded-memory-allocation/240169150

I also see that Nucleus RTOS includes Memory Pools as a feature.