is there an object-oriented C++ port of FreeRTOS or even an over-layer

amineos1 wrote on Thursday, May 22, 2014:


I found this FreeRTOS Extension Class : but I don’t know if it’s reliable and I will be able to adpat this with the latest version of FreeRTOS and making it work with a PIC32, is there any people who have already test it ?

Thanks in advance (and sorry for bad english)

amineos1 wrote on Friday, May 23, 2014:

Yes, this FreeRTOS Extension Class : works like a charm, I managed to make it work with a PIC32, in fact, the original programmer used a STM32, it’s a good C++ over-layer for FreeRTOS !

stf12 wrote on Monday, May 26, 2014:

Hi all,

the FreeRTOS Extension Class was designed as wrapper classes for the FreeRTOS native handles.
My work on that component is frozen to FreeRTOS v7.0.0 (because I’m working on other projects :-). To update the class library to the last version of FreeRTOS you need:

  • to add the new FreeRTOS API to the corresponding class object
  • to add new class derived by the IFreeRTOSObj in order to wrap the new FreeRTOS native handle.
  • take into account the new name convention.

Let me know if you need more information.


amineos1 wrote on Tuesday, May 27, 2014:

Hi Stefano,

I want to thank you for you awesome work.

If I have problems or questions, do you have a dedicated forum for your class extension layer or can I send you a personal message ?

rtel wrote on Tuesday, May 27, 2014:

If your questions are FreeRTOS related (as opposed to pure C++ questions that are unconnected to the FreeRTOS framework), and if Stafano does not have his own forum, I would prefer to keep the thread on this forum so other FreeRTOS users who have similar questions in the future will be able to see the conversation.


stf12 wrote on Tuesday, May 27, 2014:


thanks to the FreeRTOS team to provide us this forum to discuss about FreeRTOS and the Extension class.


stf12 wrote on Thursday, May 29, 2014:

I’m working to update the FreeRTOS_EC in order to support FreeRTOS 8.
A first minor update is ready: I have refactored the source code to support the new FreeRTOS Defined typedefs Names.
The next step is to provide C++ support for the new features of FreeRTOS 8.

I made also a demo to show how it works. Following are the main features of the demo:

  • target platform: STM324x9I-Eval evaluation board (STM32F439 Cortex-M4 MCU)
  • toolset: GNU Tools for ARM Embedded Processors
  • Some of the standard FreeRTOS demo tasks re-implemented as C++ class (BlockQ, Integer, PollQ, SemTest)
  • target specific tasks (Led, LCD, Timer)


amineos1 wrote on Friday, May 30, 2014:

Excellent ! thank you very much Stefano !

amineos1 wrote on Monday, June 02, 2014:

Hello Stefano,

Can you tell me please what does the prefix “A” mean in AManagedTask and “I” in IFreeRTOSObj, for “C” I think the prefix means Class

I hope that the new version will be released soon.

stf12 wrote on Tuesday, June 03, 2014:


A = Abstract. It identifies a class with some pure virtual methods. This means that the class is partially implemented, and a subclass must provide a its own implementation of that methods.

I = Interface. This class has only pure virtual methods. It specifies a “contract” between objects.

I will provide a link to download the asap in this forum.
If you want to give a look, and help me to test it… :wink: … you can download the source from the SVN repository:


amineos1 wrote on Tuesday, June 03, 2014:

Thank you / grazie !

stf12 wrote on Thursday, June 05, 2014:


I would like to give you a quick update.
I have committed a new version of the FreeRTOS_EC class in the repository. Following is the status:

  • Added CQueueSet class.
    • Need to redefine how the functions that return a resource handle are managed: I want to return an object reference, but I don’t want to dynamically allocate the object.
    • Possible solution is for example :
      QueueSetMemberHandle_t xQueueSelectFromSet( QueueSetHandle_t xQueueSet, const TickType_t xTicksToWait )
      CSetMember &CQueueSet::SelectFromSet(const TickType_t xTicksToWait, &CSetMember)
  • New supported FreeRTOS API (FreeRTOS_EC related class)
    • xSemaphoreGetMutexHolder (ASyncObject)
    • xTimerGetTimerDaemonTaskHandle (ATimer)
    • xTimerPendFunctionCall (ATimer)
    • xTimerPendFunctionCallFromISR (ATimer)
    • vTaskStepTick (CFreeRTOS)
    • uxQueueMessagesWaitingFromISR (CQueue)
    • uxQueueSpacesAvailable (CQueue)
    • xQueueReset (CQueue)
    • xQueueOverwrite (CQueue)
    • xQueueOverwriteFromISR (CQueue)
    • xQueuePeekFromISR (CQueue)
    • vQueueUnregisterQueue (CQueue)
    • xQueueIsQueueFullFromISR (CQueue)
    • xQueueIsQueueEmptyFromISR (CQueue)
    • uxTaskGetSystemState (CTask)
    • xTaskGetApplicationTaskTag (CTask)
    • xTaskGetIdleTaskHandle (CTask)
    • uxTaskGetStackHighWaterMark (CTask)
    • eTaskGetState (CTask)
    • pcTaskGetTaskName (CTask)
    • xTaskGetTickCountFromISR (CTask)
    • vTaskSetApplicationTaskTag (CTask)
  • Not supported API:
    • Event Group
    • What about the MPU support? Need to test


NOTE: the demo project has been developed using Eclipse (IDE) + GNU ARM Eclipse Plug-ins + GNU Tools for ARM Embedded Processors (Toolset)

amineos1 wrote on Thursday, June 05, 2014:

Awesome ! Thank you very much once again ! I ll test the updated extension class very soon.

As I’m a PIC32 user, I want to ask you a question about using the STM32 with eclipse and the GNU ARM solution, does the 32KB code size limitation disappear with that solution ? because I might one day try and work with the STM32, apparently, it has interesting features that the PIC32 doesn’t have.

stf12 wrote on Thursday, June 05, 2014:


ST32 is a great family of Cortex-M microcontrollers with amazing features!
And… yes, you can program it without limitation. Give a look at this video:

I hope you can find it useful :slight_smile:


rtel wrote on Thursday, June 05, 2014:

…and of course both PIC32 and STM32 have drivers/middleware integrations with FreeRTOS ;o)


jradoslav wrote on Thursday, June 05, 2014:

Dear Stefano thanks for FreeRtos EC class, but can you explain
that C++ binary generation is good for ARM unit with 40Mhz, 32KB RAM or any microECU at all?
because our c++ tests produce huge binary(30kb C vs 250Kb C++ bin) with very bad optimalized procedures and functions,
that I think its dangerous to use C++ compiler in our project in microECU. C++ is very good language but its compiler/linker has more problems:

stf12 wrote on Tuesday, June 10, 2014:

Dear Radoslav,

thanks to open this discussion. I’m pleasure to share with you and this forum my thinking about the evolution of embedded application, but I don’t want to convince anyone because I’m not a GURU. :slight_smile:

A “small” MCU (40 Mhz and 32KB RAM) designed for application that are small in term of code lines, is not a good choice to push the OO evolution in the embedded world

When I designed the FreeRTOS_EC classes I have had in mind the evolution we saw a lot of years ego in the PC world: more powerful CPU => complex and bigger (in term of code lines) applications => new programming paradigm to manage this complexity. For this reason we saw the evolution the programming languages from Assembler to procedural languages © to functional and object orient language (C++), and so on.

Are we in time to introduce C++ in the embedded world? I think of yes if I look to application like the smart brand or the internet of things. A Cortex-M MCU today is powerful enough to manage a complex multitouch application. So it is time to design in a different way the application.

For sure we need to learn how fine tune the g++ compiler for an embedded application.For example in term of code size is it possible:

  • to remove the exception handler feature
  • to remove RTTI feature
  • to remove the portion of the runtime that manage the execution of static and global object distractor

It could be interesting to make some test between C and C++ code using some well defined code samples (may be a standard FreeRTOS demo implemented in both way). What do you think?


amineos1 wrote on Tuesday, June 10, 2014:

what are you saying is very interesting and useful ! Thank you !

stf12 wrote on Monday, June 16, 2014:

Hi all,

just a quick update:

  • Modified the CQueueSet class.
  • Added a standard demo task. See CQueueSetTes class.


jradoslav wrote on Tuesday, June 17, 2014:

Hi Stefano

I understand what you’re saying but I think that if hardware or digital world will work on TWO state value - control and data follow streams, state machines and extended SM. Until then will exist computer languages like ASM higher C and their coders, because computer language is derived from real HW architecture.

So,technologies ( C ASM and HW ) is tool or provider for OOP evolution. Rather Operation systems designed under C for specific HW is good provider for OOP abstraction and its interpretation.

Therefore i think that OOP evolution can be pushed directly to small embeded world, but this question not solve porting C to C++ of Freertos code.

This problem solve design of theroy or converting method from higher OOP languages(Java,C#,rubby etc) or UML model directly to C code generation. next this generated C code can be compiled with Freertos kernel code. And this is not easy work.