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] [December 2015 Threads]
I am integrating FreRTOS 8.2.2 into a legacy project. In addition, I am trying to incorporate TCP+ example code. The old coding used heap3 for the heap model and the TCP+ requires heap4. When I use heap4 the build fails saying that the heap memory has overrun it size. I can only use half the size for heap that I need.
I am using armxilinx_eabi and an ARM9 in a ZYNQ.
Why are the heap requirements so much more in the heap_4? Is there a way to use the same heap size?
There are no differences in the amount of heap required or used when switching from heap3 to heap4, the only difference is how the heap is allocated.
When you use heap_3 the heap is allocated by the development tools, and does not form part of the data that is located by the linker, and so the linker does not take its size into account.
When you use heap4 the heap is basically a statically allocated array, which is located by the linker - and the linker has to fit it into its memory map. The size of the array that is used as the heap is defined by the configTOTALHEAP_SIZE setting.
Remember that, when using heap_4, provided no other code is calling malloc directly, you can set the size of the heap allocated by the tools to as close to 0 as the tools will allow (normally 4 bytes).
See http://www.freertos.org/a00111.html for more details.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.