Question for FreeRtos system variables usage

jradoslav wrote on Thursday, June 05, 2014:

Dear FreeRtos developers, thank you for this project.

I have two questions.

1.It is safe dynamic allocation pattern under freertos OS API for system handles(pointers to system objects) and depending RAM data for
xQueue, xEventGroups, semaphores memory etc. objects that is used for intertask communication?

I think if the problem is that handles-pointers is not static declared.

I use:
queueHandle = xQueueCreate() and queueHandle pointer is not declared as static/global but is dynamically allocated in some task by heap_4.

2.C++ and C standards mixing is possible and C++ brings benefits, but my decision was C for development.
Is that decision OK or better then C++? or C++ compilation cannot affect application deployed on ARM processor.

heinbali01 wrote on Thursday, June 05, 2014:

Hi Radoslav,

Question 2: about C++ and embedded:

It is very well possible to use FreeRTOS in combination with C++ !

Personally I find C++ easier to read and it gives some more safety, more protection against making stupid mistakes.

There is an implementation of C++ and FreeRTOS:

I didn’t try it myself, but several people on this list liked it.

FreeRTOS_EC imposed the same limitations as I also do for embedded:

  • No use of the Template Library (STL)
  • No Run Time Type Information (RTTI)
  • No C++ Exception handling (-fno-exceptions)

So it’s just C++, but I do use the powerfull C++ templates.

Using C++ is more expensive. For writing a small bootloader, I will use plain C.

Be sure to get the correct linking: C versus C++. I thing all FreeRTOS headers now have:

#ifdef __cplusplus
extern "C" {

/* declarations */

#ifdef __cplusplus
} /* extern "C" */

Question 1:

If I may translate: It is safe to use a dynamically allocated variable that holds pointers to system handles?

Can you describe how your queueHandle is created?
Somewhere you declare the identifier ‘queueHandle’, what does it look like?

The following would be no problem:

struct MyHandles {
	SemaphoreHandle_t xSemaphore;
	QueueHandle_t xQueue;
	TaskHandle_t xTask;

int main ()
	struct MyHandles *myHandles;
	myHandles = ( struct MyHandles* ) pvPortMalloc( sizeof *myHandles );
	if( myHandles )
		memset( myHandles, '\0', sizeof *myHandles );
		myHandles->xQueue = xQueueCreate( QUEUE_LENGTH, QUEUE_SIZE );

In this example ‘myHandles’ is a local variable, pointing to a set of system handles. As long as ‘myHandles’ isn’t deleted, you can use all members.


jradoslav wrote on Thursday, June 05, 2014:

Thank you Hein I use this style of coding C
But in C is is difficult to implement ‘this’ keyword and must be passed as parameter handle to all “class” procedures.

typedef struct structMyHandles_t {
	SemaphoreHandle_t xSemaphore;
	QueueHandle_t xQueue;
	TaskHandle_t xTask;

typedef *void QItem_t;

#define _NEW(T) (( T* ) pvPortMalloc( sizeof (T) ));

int main ()
	MyHandles_t *p_myHandles; 
	p_myHandles = _NEW(MyHandles_t); 	
	if( myHandles )
		memset( myHandles, 0x00, sizeof (MyHandles_t)  );
		myHandles->xQueue = xQueueCreate( QUEUE_LENGTH, sizeof(QItem_t) );
    //task createion with p_myHandles parameter 
	//task createion

jradoslav wrote on Thursday, June 05, 2014:

Dear Hein

Thank you for link to c++ wrappers and higher implementation of queue featured task.
I worked on development 3 yeras ago on Symbian OS PDK, and this wappers are being used very similarily, therefore Im familiar with code style of these wrappers.

Kind Regards


richard_damon wrote on Thursday, June 05, 2014:

Not sure why you are trying to create a generic “MyHadles_t” type here.

For building up a “class” like task in FreeRTOS, you just define a struct and fill the data needed for it in main, pass the address of that struct as the parm when you create the task, and then first thing in the task, assign the void* pointer to a properly typed pointer in the task (you can even call the variable “this” if you want to make conversion to c++ easier later).

I find it rare that I want to put these sorts of things “on the heap”. The only reason I can think of is if you have a variable (and ‘unlimited’) number of tasks of a given type you can create, and these are being made dynamically at run time. (You then need to be VERY careful to handle the out of memory condition, for example in your above code, the task creation with p_myHandles parameter code should be INSIDE the if, after all, if you couldn’t create the parameter, you shouldn’t create the task).

heinbali01 wrote on Thursday, June 05, 2014:

Hi Richard,

Not sure why you are trying to create a generic “MyHandles_t” type here

To only purpose was to get Radoslav’s question clear :slight_smile:

…first thing in the task, assign the void* pointer to a properly typed pointer in the task

Yes sure, that’s what the task’s parameter is made for.
I also like the idea of encapsulating a task in a class and pass ‘this’ to the task’s initial function.

(why) put these sorts of things “on the heap”

I guess that Radoslav has a good reason for this. Maybe his MCU has a very small internal RAM and a big external RAM controlled by malloc

One issue I wanted to mention about C++: if you use function-scoped static instances of a class as in:

class CTimer {
    CTimer (int c);

/* This declaration is OK */
static CTimer timer( 0 );

void foo()
    /* This needs a guard */
    static CTimer timer( 0 );

GCC will complain about an undefined reference to “__cxa_guard_acquire/release”
So if you see this error, look for statically declared objects within some function.

Putting the same object outside the function (but still static) will solve the problem.


jradoslav wrote on Thursday, June 05, 2014:

Hi All

I`m writing my findings in development with Freertos under C++.

I successfuly compiled project under C++ and tried to call tasks through FreeRTOS_EC wrapper and ASF framework. the test was also succsessfull, but it takes a one problem.

The same test project compiled under C gnu99 generated 30Kb binary file but under C++ 250KB was the result(more combination of opt flags) and I closed elf view after 5 seconds.

I think the C++ is good for higher HW architectures like ARM >500Mhz.And provides high abstraction.

FreeRtos still provides high abstraction in C and it`s also very close to HW layer (binary generation). but FreeRtos is designed for processors with limited resources.

I think that this particular point is very important and shows that development under C++ should not be used for this purpose.

Kind regards


richard_damon wrote on Friday, June 06, 2014:

One question is this the size of the “object file” or the code/data space used in the final output. If the first, it may not be all that important, as the C++ may have include a lot of debug output. If the second, it can be useful to check what grew, it could well be that some little thing include a big library.

Properly written C++ can be be very similar in size to C code. The one thing that can cost space is the exception processing code (which should add that much).

jradoslav wrote on Friday, June 06, 2014:

Abstraction is a very useful and often looks smart but when using a higher abstraction so it is more distant from reality and depends on lower layer.

Therefore, the use of abstraction, it is necessary to ask whether converted code to the lower layer is reliable.

C++ compiler thinks about the language constructions(polymorphysm etc) where C compiler may not. Therefore, the C compiler always be better for optimalization then C++ compiler.


0 thinking
1 formalism, algebra
2 schema
3 model (UML etc)
4 domain spec model (extended model)
5 domain specific language code (generation is useful)
6 target language (NET, Java, other virtuals) //i think that this layer is best for OOP language
7.C or C++ for higher interpretter formats, depents on OS and processor
8 kernel hard C or C mixed assembler allways depends on concrete processor
9 binary code in flash memory
10 HW = reality.

all 0 to 9 depends on conversion method and its reliability to any next lower layer, only HW depends on fabrication and workers

heinbali01 wrote on Friday, June 06, 2014:


Richard Damon is right, the code produced by c++ and c are quite similar in size.
If your code gets large, look carefully at what is linked in.

Here is an example of how I compile and link c++ projects:


/* fill in your own g++ compiler */

/* compile only, link later */

/* these two depend on your hardware type. This if for Atmel UC3 */

/* Want to see every possible compiler warning */

/* As suggested below by Richard Barry: get more warnings */

/* No Run Time Type Information, because it is expensive */

/* No exception handling, too expensive */

/* Optionally, to get some auto-dependency checks */
-MT "e:/home/uc3/TestProject/version.i e:/home/uc3/TestProject/version.x e:/home/uc3/TestProject/version.o"

/* add debugging information to elf */
/* optimise for size */

/* Put every function in its own .text section */
/* so that functions which are never called will not be linked into the code */

/* Same for data */

/* Only use this if you provide your own version of memcpy */

-o e:/home/uc3/TestProject/version.o e:/home/uc3/TestProject/version.cpp



/* Fill in your own version of -gcc */
/* these two depend on you hardware type. This if for Atmel UC3 */

/* Define a linking scheme */

/* tell to use sections */

/* provide your own startup code */
/* Optionally, this is my startup code */
... /* many more object files */

-o myprogram.elf

It will take some time before you have a good setup to create a “hello world” in c++.

Just surf around and try to find examples for your target MCU.


rtel wrote on Friday, June 06, 2014:

/* Want to see every possible compiler warning */

Not really relevant to the question, but I always compile FreeRTOS with “-Wall -Wextra”

Compiling the code with some 18 different compilers generates conflicting requirements - what pleases one compiler, upsets another, hence the very verbose use of casting and brackets in the code.