Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

New object not created properly

Posted by maxpartenfelder on September 1, 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", configMINIMALSTACKSIZE + 300, NULL, tskIDLE_PRIORITY + 1, NULL); ~~~


New object not created properly

Posted by rtel on September 1, 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()?


New object not created properly

Posted by maxpartenfelder on September 1, 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.


New object not created properly

Posted by rtel on September 1, 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


New object not created properly

Posted by richard_damon on September 1, 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.


New object not created properly

Posted by heinbali01 on September 1, 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 { return pvPortMalloc( size ); }

void operator delete( void * ptr ) { vPortFree( ptr ); }

void operator delete { 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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS