While trying to build a complete static application (configSUPPORT_DYNAMIC_ALLOCATION set to 0) I found that something inside the kernel still requires dynamic memory. According to the output it seems that the module event_groups.c is the offending one (I’ve shortened the ouput):
arduino-1.8.5/libraries/FreeRTOS-10.0.1/src/heap_3.c:53:3: error: #error This file must not be used if configSUPPORT_DYNAMIC_ALLOCATION is 0 #error This file must not be used if configSUPPORT_DYNAMIC_ALLOCATION is 0
Does it mean that we cannot build 100% static applications?
Should I remove the heap_3.c memory allocation file and any of its sibblings?
You have set configSUPPORT_DYNAMIC_ALLOCATION to 0, then tried to build a source file that implements a heap - the two are not compatible. If configSUPPORT_DYNAMIC_ALLOCATION is 0 then do not build any of the heap_x.c files (where in your case ‘x’ is ‘3’).
I’ve just found that I need to remove any heap_xxx.c file from the building if I want to build a 100% static app. It’s going to be a little messy in enviroments where the files MUST be removed completely by hand, like Arduino.
However, instead of deleting the file heap_3.c file I’ve just changed its name to heap_3.txt. I’m shure I’ll need it later on when building apps with dynamics objects.
However, I am experiencing errors when I compile with GCC for ARM CM4F:
../../cpp/FreeRTOS-Kernel/portable/MemMang/heap_4.c:50:6: error: #error This file must not be used if configSUPPORT_DYNAMIC_ALLOCATION is 0
50 | #error This file must not be used if configSUPPORT_DYNAMIC_ALLOCATION is 0
| ^~~~~
../../cpp/FreeRTOS-Kernel/portable/MemMang/heap_4.c:66:44: error: 'configTOTAL_HEAP_SIZE' undeclared here (not in a function)
66 | PRIVILEGED_DATA static uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
| ^~~~~~~~~~~~~~~~~~~~~
[10/16] Building C object cpp/FreeRTOS-Kernel/CMakeFiles/freertos_kernel.dir/portable/Common/mpu_wrappers.c.obj
../../cpp/FreeRTOS-Kernel/portable/Common/mpu_wrappers.c: In function 'MPU_xTaskCreateStatic':
../../cpp/FreeRTOS-Kernel/portable/Common/mpu_wrappers.c:82:9: warning: implicit declaration of function 'xPortRaisePrivilege' [-Wimplicit-function-declaration]
82 | xPortRaisePrivilege( xRunningPrivileged );
| ^~~~~~~~~~~~~~~~~~~
../../cpp/FreeRTOS-Kernel/portable/Common/mpu_wrappers.c:84:9: warning: implicit declaration of function 'vPortResetPrivilege' [-Wimplicit-function-declaration]
84 | vPortResetPrivilege( xRunningPrivileged );
I am importing FreeRTOS Kernel into my project as a git submodule and building using CMake. My application is written in C++ and including freertos_kernel as a library. I was hoping that by setting the config settings correctly, the CMake files in FreeRTOS would not attempt to compile any heap-related files and I would not need to modify the FreeRTOS source code in any way.
However, it seems like the CMakeLists for this project are written specifically for dynamic memory allocation:
add_library(freertos_kernel STATIC
croutine.c
event_groups.c
list.c
queue.c
stream_buffer.c
tasks.c
timers.c
portable/Common/mpu_wrappers.c
# If FREERTOS_HEAP is digit between 1 .. 5 - it is heap number, otherwise - it is path to custom heap source file
$<IF:$<BOOL:$<FILTER:${FREERTOS_HEAP},EXCLUDE,^[1-5]$>>,${FREERTOS_HEAP},portable/MemMang/heap_${FREERTOS_HEAP}.c>
)
This is kind of frustrating because it means that the kernel can’t work out-of-the-box, but rather must be modified by the end user, even if they’ve configured everything properly.
A workaround, as bad as to rename o delete files, is that every project has its own statically memory allocation scheme kernel tuned copy, including its own FreeRTOSConfig.h.
Or that you have two versions, one for each scheme. Yes, that’s bad too.
In some enviroments, like Eclipse, you can reject files from being build, however, when not using it, like for example, when using make or cmake directly, we face such problems. But that’s not exactly a FreeRTOS problem, but the building tool instead.
I understand your frustration - specially when you have many moving parts.
The CMake was added recently and is a work in progress. We are improving the CMake incrementally.
As a workaround, since you are using static allocation of memory, you can create an empty heap file and give the path to CMake so that it won’t force you to use any of the Kernel heap files. You can do that as below from your top-level CMake file:
I like where you’re going with this. However, mpu_wrappers is also problematic and not under the control of the user’s CMakeList.
I think this could be a good candidate for an upgrade to the top level CMakeList. Maybe an option when setting the path to the heap module which disables the inclusion of mpu_wrappers and heap_x.c. Instead of setting the FREERTOS_HEAP to 1-5 or a path, the user sets it to zero, or some string with the specific function of disabling the heap entirely.