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

Kernel
1

amineos1 wrote on Thursday, May 22, 2014:

Hello,

I found this FreeRTOS Extension Class : http://www.stf12.org/developers/FreeRTOS_EC.html 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)

2

amineos1 wrote on Friday, May 23, 2014:

Yes, this FreeRTOS Extension Class : http://www.stf12.org/developers/FreeRTOS_EC.html 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 !

3

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.

Regards,
Stefano

4

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 ?

5

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.

Regards.

6

stf12 wrote on Tuesday, May 27, 2014:

Hi,

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

Regards,
Stefano

7

stf12 wrote on Thursday, May 29, 2014:

Hi,
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)

Regards,
Stefano

8

amineos1 wrote on Friday, May 30, 2014:

Excellent ! thank you very much Stefano !

9

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.

10

stf12 wrote on Tuesday, June 03, 2014:

Hi,

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:

http://code.google.com/p/stf12/source/browse/#svn%2Ftrunk%2FFreeRTOS_EC_DemoSTM324x9I-EVAL

Regards,
Stefano

11

amineos1 wrote on Tuesday, June 03, 2014:

Thank you / grazie !

12

stf12 wrote on Thursday, June 05, 2014:

Hi,

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

Regards,
Stefano

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

13

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.

14

stf12 wrote on Thursday, June 05, 2014:

Hi,

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:
http://www.stf12.org/stm32ide/

I hope you can find it useful :slight_smile:

Regards,
Stefano

15

rtel wrote on Thursday, June 05, 2014:

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

http://www.microchip.com/harmony
http://www.st.com/stm32cube

Regards.

16

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: http://warp.povusers.org/grrr/cplusplus_vs_c.html

17

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?

Regards,
Stefano

18

amineos1 wrote on Tuesday, June 10, 2014:

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

19

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.

Regards,
Stefano

20

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.