FreeRTOS's compatibility with C++

baoway wrote on Wednesday, February 22, 2017:

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

heinbali01 wrote on Wednesday, February 22, 2017:

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

richarddamon wrote on Thursday, February 23, 2017:

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.

baoway wrote on Wednesday, March 01, 2017:

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

jwellbelove wrote on Friday, February 02, 2018:

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/

And, to tack on to that, there’s

Which is similar to, but different than, John’s great ETL