New object not created properly

Kernel
1

maxpartenfelder wrote on Thursday, September 01, 2016:

I am encountering a very strange error using freeRTOS on an Arduino Mega2560:

In the setup block I can create an instance of my class:

MyClass* myClass = new MyClass(char a, char b, new Vector(42));
// new Vector(42) creates a new vector and pushes 42 in as first item

Using a print() method in this class, I get a legimit output on the console, showing me all the chars and values in the vector.

Using the exact same line inside a task, causes the object not to be created properly. It seems like the fields are empty or there is something entirely wrong (like strange memory errors) with the instance. Printing it again results in an empty line (program doesn’t crash) while printig a globally created instance gives the correct result.

Is there any trap in freeRTOS concerning the creation of new instances of an object inside a task? Below is the code for the task creation, increasing the task stack size doesn’t help. For debug reasons this the only task running at the moment.

xTaskCreate(displayTask,
    "DisplayTask",
    configMINIMAL_STACK_SIZE + 300,
    NULL,
    tskIDLE_PRIORITY + 1,
    NULL);
2

rtel wrote on Thursday, September 01, 2016:

Sorry - everything we do is in C, not C++, although there are some very
good C++ frameworks around for FreeRTOS, so I can’t comment directly on
your issue.

In more general terms, your question is too general…

Is there any trap in freeRTOS concerning the creation of new instances
of an object inside a task?

Are you talking about calling C++ constructors (if so, see my comment
above), or are you talking about using pvPortMalloc() and vPortFree()?

3

maxpartenfelder wrote on Thursday, September 01, 2016:

MyClass* myClass = new MyClass(char a, char b, new Vector(42));

This is supposed to be a C++ constructor.

Sorry - everything we do is in C

Does this mean, that I am not allowed to use C++ with the FreeRTOS_AVR port? This would be a big dealbreaker for me, since my whole programe is written in C++ so far.

4

rtel wrote on Thursday, September 01, 2016:

Like I said, there are several good C++ frameworks for FreeRTOS, but it
is not something we test ourselves.

Take a look at

http://interactive.freertos.org/hc/en-us/community/posts/210028906-Using-FreeRTOS-with-C-

(I think you will find a much newer version of that on the web)

also

http://interactive.freertos.org/hc/en-us/community/posts/210029426-FreeRTOS-C-Wrappers

5

richard_damon wrote on Thursday, September 01, 2016:

One key thing you need to watch out for when using an RTOS like FreeRTOS is that you have a compatilbe library (library functions can handle being reentrant). Most parts of the library don’t have an issue with this. One of the big issues is heap management. In embeded C, you can fairly easy manage this yourself by either not using the heap, or changing calls to malloc to use the FreeRTOS wrappers. In C++ though, the new operator tends to call malloc itself directly. Out of the box, this may not be safe, as if another thread is doing the same you can corrupt your heap. Thare are a couple of ways around this:

  1. Don’t use new in tasks. (including classes that internally use new) Many embeded design rules limit the use of the heap functions to initialization. This means that all dynamic objects are created before starting the schduler. This is one trip up in C++, as typical usage does much more heap usage than C, and much of it under the hood.
  2. Wrap all calls that might use the heap in some form of exclusion (like a mutex or schedule suspend). This lets you use the heap, but does require care to identify all points that might use the heap (like adding/removing items from containers)
  3. Override all the various operator new()s and operator delete()s to go through the wrappers.
  4. If the library supports it, implement the reentriency layer for the library. For example, newlib provides a set of entry points to allow you to provide an exclusion object for malloc/calloc/realloc/free making them thread safe. (I think there is code for this in the core or example with a define to enable). These hooks also sometimes also create some thread local storage to make some other non-reentrent functions thread safe.

I use C++ at times with FreeRTOS (and a pointer to my wrapper class was posted above), and often I just use the first method, yes, it says I don’t use all of C++, but it is enough to get a lot of work done and use a lot of the improvements from C++, it says you don’t use the STL, but in an embeded enviroment where you can’t afford to get an out of memory fault in the middle of an operation, that becomes a design requirment anyway. I have used the 4th option in very limited cases.

6

heinbali01 wrote on Thursday, September 01, 2016:

Although FreeRTOS is a C-only project, in my experience, it mixes perfectly with C++. Except for the re-entrancy problems of some library calls, and I also do not use the Standard Template Library for embedded.

I tend to use what Richard Damon describes as option 3, redefine new and delete.

You could define these four C++ operators:

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 );
}

These self-defined operators will avoid the used of the standard malloc()/free(), and that will most probably solve the problem that you encounter.