I have some questions regarding memory allocation and freeing with MQX that I hope someone can help with. Our current application approach is using a lot of malloc and free calls, both of which we have pointed at the corresponding MQX memory functions for system memory (_mem_alloc() and _mem_free() ). How does MQX address memory fragmentation and how well does MQX will keep track of a large number of freed memory holes for reuse on future malloc calls. My understanding is that MQX will track the freed memory areas, and thier size, and use them for future allocations. My questions are:
Suggestions on best ways to accommodate the need for a lot of dynamic memory use across functional areas of the code and across threads? Have considered memory pools / blocks, msq queues - not sure which pros & cons of each will impact things the most.
Solved! Go to Solution.
1) seems to be limited to the amount of RAM you have on your system (allocations will fail only if you run out of ram, or if it can't find a block big enough)
as long as you don't change MQX_MEMORY_FREE_LIST_SORTED from the default '1' then it looks like it will find the best fit because the list is maintained in sorted order.
3) yes
4) you should be fine either way, i normally use the C library version just in case
5) i don't know what IDE you use, but the MQX plugin for IAR is excellent, it shows details on memory allocations from the various memory pools/blocks and message queue (and just about any other resource you can allocate/initialize or block on).
fyi: I've noticed that many kinetis parts have 2 banks of sram and that mqx will prevent any allocations from spanning both banks (ex: k60 with 2 32 kB banks, mqx allocates 16 bytes at the end of the first bank which can cause problems depending on your specific use case, usually an issue when you need multiple large allocations.
Hi John,
In addition, Freescale MQX uses its own memory allocation system, which doesn't rely on heap.
The default MQX memory pool, where MQX kernel allocates system memory, is between __KERNEL_DATA_START and __KERNEL_DATA_END (symbols generated during bsp linkage).
It allocates memory using function _mem_alloc_system().
On top of this, in bsp we define malloc() to call _mem_alloc_system().
If you want the MQX kernel to call Thumb library malloc, then you have to define _mem_alloc_system* in preprocessor to be malloc #define _mem_alloc_system malloc and so on. And then disable bsp "duplicate" definition of malloc (either by link order or be removing the duplcate definition from the sources).
If you want to use Thumb library allocation system, you can, but it is your responsibility to give the CodeWarrior necessary linker generated files and so on, whatever the Thumb library allocation system relies on.
You lose TAD, kernel logging and other MQX features related to memory allocation.
Have a great day,
Sol
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
1) seems to be limited to the amount of RAM you have on your system (allocations will fail only if you run out of ram, or if it can't find a block big enough)
as long as you don't change MQX_MEMORY_FREE_LIST_SORTED from the default '1' then it looks like it will find the best fit because the list is maintained in sorted order.
3) yes
4) you should be fine either way, i normally use the C library version just in case
5) i don't know what IDE you use, but the MQX plugin for IAR is excellent, it shows details on memory allocations from the various memory pools/blocks and message queue (and just about any other resource you can allocate/initialize or block on).
fyi: I've noticed that many kinetis parts have 2 banks of sram and that mqx will prevent any allocations from spanning both banks (ex: k60 with 2 32 kB banks, mqx allocates 16 bytes at the end of the first bank which can cause problems depending on your specific use case, usually an issue when you need multiple large allocations.
Thank you for the answers! Reading the description in the MQX User Guide MQX_MEMORY_FREE_LIST_SORTED, sounds like it is sorting by physical address, not size. Therefore I would think it will do a "first fit" not "best fit"
>>
MQX_MEMORY_FREE_LIST_SORTED
Default is one.
One: MQX sorts the freelist of memory blocks by address. This reduces memory
fragmentation, but increases the time MQX takes to free memory.
<<