FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [May 2016 Threads] FreeRTOS: Memory ManagementPosted 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 ManagementPosted 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 ManagementPosted 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 ManagementPosted 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 ManagementPosted 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.
Attachmentsvram_alloc.c (20068 bytes)
FreeRTOS: Memory ManagementPosted 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 ManagementPosted 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 ManagementPosted 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|