Hello, I’ve got a question regarding the compatibility between FreeRTOS and C++. FreeRTOS’s kernel itself exist of C-files. A solution would be to work with extern “C” linkage in the C++-files and a global/ static task function, which receives a void* parameter in the main.cpp. This works for me so far. My general question is now: is it possible to write a FreeRTOS project completely as a C++-project or do I need the solution with extern “C” linkage above. Additionally is it possible to use the STL, especially the operators new and delete for allocating dynamic memory. Any help would be greatly appreciated. Thanks, Bao

FreeRTOS can be mixed perfectly with C++ code. Even the task-functions may have a C++ linkage, because xTaskCreate() only expects an address of a function. Care should be taken with new() and delete(). I often redefine them as follows: ~~~~ void * operator new( size_t size ) { return pvPortMalloc( size ); } void * operator new[]( size_t size ) { return pvPortMalloc(size); } void operator delete( void * ptr ) { vPortFree ( ptr ); } void operator delete[]( void * ptr ) { vPortFree ( ptr ); } ~~~~ because the standard definitions will call malloc() and free(). Richard Damon created a wrapper for FreeRTOS, which you find here: https://github.com/richard-damon/FreeRTOScpp

Strictly speaking, the task function that FreeRTOS calls should be a function declaired as extern “C” as there may be a difference in calling conventions between “C” functions and “C++” functions. This does restrict (I believe) the task function to be a ‘global’ function and not a member of a class. In most cases, especially for the class of processors used with FreeRTOS, this isn’t an issue, and you can use a static member function of the class for the task function. Currently my wrappers do this, but I am thinking of modifying them to be more strictly correct if I can work out all the corner cases. For me, rather that trying to fix new/delete to use pvPortMalloc, I am more inclinde to replace malloc/free with a thread safe version. Newlib-nano has a version that can be made thread safe with just a compiler option and defining a couple of simple callback functions (and most gcc based systems will be using newlib-nano, but might not have that option set, so it isn’t that hard to replace it. This says that if you use a C library routine that uses the heap you are still protected.

Hey Hein and Richard, thank you both for the great answers. They definetely help a lot. I’ve already heard about the method of redefining the new() and delete() operators, so they would not call the standard malloc() and free() functions anymore, just like Hein mentioned above. I’ve added the Newlib-nano library to my linker, but I assume that the new() and delete() operators haven’t been redefined. Richard, you have mentioned to define some callback functions, but how do they exactly look like? Thank you in advance for helping, Bao

I know it’s nearly a year since the OP’s post, but if you’re interested in statically allocated STL like containers (no heap use at all) then you may be interested in the Embedded Template Library (ETL) It’s open source under the MIT licence. https://www.etlcpp.com/