Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

FreeRTOS: Memory Management

Posted by paulromero on May 22, 2016

Dear Forum:

Is is possible to configure FreeRTOS such that the heap. implementation of prvPortMalloc() etc. can be used on separate heap and ram segments the concurrently ?

More clearly, I would like to use the same memory management algrorithm for two completey separate areas of memory. One is a large ram segment and the other is the default heap segment.

I am almost certan the names of the allocation and free routines must have distinct names and something needs to be done to point the at the right segment during initialization.

Best Regards,

Paul R.


FreeRTOS: Memory Management

Posted by richard_damon on May 22, 2016

You probably want to make a copy of the heap#.c file and give the functions a new name to make the version to handle the separate area. You can then add whatever is needed to force the heap array into the right memory, this is very system dependent.


FreeRTOS: Memory Management

Posted by heinbali01 on May 23, 2016

Do you want two different malloc routines, e.g.:

~~~~ /* Malloc internal RAM. */ void *pvPortMalloc(); void vPortFree();

/* Malloc external RAM. */
void *pvPortMalloc_2();
void vPortFree_2();

~~~~

Or do you want a single malloc/free couple that manages both areas of memory? In the last case you can use heap_5.c


FreeRTOS: Memory Management

Posted by rtel on May 23, 2016

Further to Hein's post, here is a link with a little more information on heap5: http://www.freertos.org/a00111.html#heap5

Regards.


FreeRTOS: Memory Management

Posted by paulromero on May 25, 2016

Hi Richard:

I would like to use two different malloc() routines with independent memory management.

I designed a best fit memory management algorithm which has been extensively tested and and moderately analyzed. It is pretty much system independent. All you need to do is point at the chunk of memory you want to use. However, it is not reentrant and the code could use some refinement.

The code that implements the algorithm and the proof of it are attached to this note for your perusal. Can you think of a way to make it safe for use in a multitasking environment without using mutexes ? I assume no one is dumb enough to try to use in an interrupt handler or critical section.

Best Regards,

Paul R.

Attachments

README.mm_algo (6192 bytes)
basic.h (335 bytes)
memory.h (1893 bytes)
vram_alloc.c (20068 bytes)

FreeRTOS: Memory Management

Posted by richard_damon on May 25, 2016

The simplest way to get mutual exclusion is a mutex, that is the basic purpose of them (which is what gives them their name). The alternative would be to do something to disable task switching for the duration, either with a critical section (which may cause unexceptable delays to interrupts) or to disable the scheduler, which will perhaps hold off a high priority task needlessly.

What is your problem with using a mutex?


FreeRTOS: Memory Management

Posted by paulromero on May 25, 2016

Hi Richard:

I have no problem, and actually like, using mutexes. However, some folks complain that they degrade performance.

Best Regards,

Paul R.


FreeRTOS: Memory Management

Posted by rtel on May 25, 2016

On the assumption the allocation is going to be fast, and taking your point that nobody should be doing this in an interrupt (although you would be surprised what people do ;o) I would second Richard D's suggestion of suspending the scheduler.

vTaskSuspendAll();
// Do you thing here
xTaskResumeAll();

It might be that you do not need to do this around the entire allocation function, but just at select points within the algorithm where simultaneous access would be an issue.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists