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

Kernel
21

amineos1 wrote on Wednesday, July 30, 2014:

Hello Stefano,

Under a PIC32MX, with your framework (version 7, the old one) I created 4 Tasks with different priorities (ADC,FFT,UART, and LED) and I used mutexes (from the framework of course) to synchronize between them.

I noticed something odd : when mutexes or the array used by those tasks are global and static my application don’t work and I don’t know why ??? that’s very strange since they are static variables.

So I am obliged to give to my tasks pointers to the mutexes and the data (arrays to store the collected ADC sample and FFT results) so everything works very well.

22

stf12 wrote on Friday, August 01, 2014:

Hi,

this is strange. I have attached a simple demo (4 tasks and 2 mutex) that works fine.
Is the test like your application?

Regards,
Stefano

23

amineos1 wrote on Saturday, August 02, 2014:

Hello,

it’s strange but it’s microchip stupid compiler, the problem touchs not only synchronization mechanisms (semaphores mutexes …) but all normal variables (arrays etc…)

I will give you an example : when I fill a STATIC array with data in “FFT TASK” the UART TASK sends to the computer zeros, so in fact, the FFT TASKS doesnt fill the static array but it’s filling another thing I don’t know really which one, that’s really odd) and this is the compiler fault !

if the array contains zeros, it means that it has not been filled, but when I give to the FFT task or any normal task a pointer the array or the variable to modify, in fact, it works !

I want to say a message to those who want to use your work under MPLABX (Microchip PIC32) yesterday I had many problems with interrupts, I spend hours to find the solution, so you can compile : you must use extern “C” with the functions that will be ISRs and not in the prototype of the ISRs wrapper as commonly known, this is for the compilation.

if the interrupt level of the interrupt source (e.g. timer) which you have put in its IRQ register is higher than the level you have put in the ISR wrapper prototype (the iplx argument where x is a number between 1 and 7) your application will crash (you will have this ugly message in debug mode console : No source code lines were found at current PC …)

Stefano, the hardware initialization method with a task crashed my application so when I put instructions that perform dynamic allocation inside the constructor instead of that method, my application didn’t crash, but I noticed this problem with only one task… so I avoid using this method.

I think that all those problems come from the LAME microchip XC32++ compiler, if you dont know : optimization are not available for the free version of XC32++, this is really a joke, if the compiler doesnt’t do the optimization work, who will do it ??? Microchip is a tightwad company, you will notice that also in their dev kits :wink: I’m glad I started working with the STM32.

Stefano, did you know that in order to work with interrupts under FreeRTOS and PIC32 we must use assembly wrappers (a single .S file for each ISR inside we must put the name of the C written ISR) ? does this exist also with the STM32 ? I started working with the STM32F4 and I don’t know how ISR’s are managed under this ARM based mcu and its FreeRTOS port, I hope that you can give a fast answer to my question before I start searching the information and Thank you in advance.

I ll look at the example you gave me, but I know that’s unuseful since it’s the compiler fault, I must avoid using static variables inside the tasks, the program will compile but it will not run as expected because the Microchip is not reliable when compiling C++ projects.

In debug mode I can’t even browse the insctructions !!!

To conclude, your work works under PIC32 but tasks must use pointers to the mutexes, semaphores, queues or even arrays or simple variables… otherwise the application will not work, in debug mode, in the IDE console we can read :
“No source code lines were found at current PC 0x…”

if my advices concerning interruptions are not respected you will have the same message,
avoid also to use HardwareInitalize and put your hardware initialization in the constructor.

Thank you and sorry for bad english.

24

amineos1 wrote on Monday, August 04, 2014:

Well, LOL, with another example that I made, the static variables worked inside the tasks !

Maybe I had a little bug in my precedent examples or maybe it’s the compiler fault, I dont know, it’s hard to investigate problems under an RTOS.

But I ll still say that MPLAB X and its comiler sucks hard !

25

stf12 wrote on Tuesday, August 05, 2014:

Hi,

let me share my experience about what I know. I have never worked with a PIC32 MCU.

About the interrupt problem:

you must use extern “C” with the functions that will be ISRs and not in the
prototype of the ISRs wrapper as commonly known, this is for the compilation.

you must use the extern “C” in order to make a function-name in C++ have ‘C’ linkage.

// Individual C linkage declaration
extern "C" void foo();

// Block C linkage declaration
extern "C"
{
  void MyFunc1();
  void MyFunc2(int n);
}

This is, more or less, because since C++ has overloading of function names and C does not, the C++ compiler cannot just use the function name as a unique id to link to, so it mangles the name by adding information about the arguments.

About the interrupt management for STM32, a complete answer will be too long for a single post, but you can look at the sample code coming with the FreeRTOS distribution (there are a lot of STM32 demo) or with my C++ demo (CIrqDrivenTask.cpp). With STM32 you can write your Interrupt Service Routine using a C function.

For the other issues, for example the one with the HardwareInit method, it would be better if you can share a code sample to analyze the problem.

Regards,
Stefano

26

amineos1 wrote on Wednesday, August 06, 2014:

Okay thank you.

27

picwarrior wrote on Monday, December 28, 2015:

Bonjour Aminos,

Je m’intéresse à l’utilisation de FreeRTOS sur un PIC32MZ, en utilisant le C++.
En C, j’arrive très bien à utiliser FreeRTOS, mais le projet que je suis en train d’essayer de porter maintenant en C++ avec FreeRTOS ne compile pas du tout, à cause de FreeRTOS. J’ai déjà passé une journée entière à investiguer ce problème, notamment sur les forum Microchip et de FreeRTOS, et il semblerait que la solution réside dans l’utilisation d’rapper pour freeRTOS tel que FreeRTOS Extension Class.

Vous êtes une des rares personnes sur les forums à utiliser FreeRTOS Extension Class sur un PIC, alors je me permets de vous contacter à ce sujet.

Vous serait-il éventuellement possible de partager un projet exemple montrant comment utiliser FreeRTOS Extension Class sur un PIC ?
En retour, je pourrai vous faire bénéficier de mes résultats sur un PIC32MZ, si celà a de l’intérêt pour vous.

Ou bien, vous serait-il possible au moins de me conseiller sur la direction à explorer afin de réussir à compiler et faire tourner un projet en C++ en utilisant FreeRTOS sur un PIC32 ?

Bien cordialement,

PICwarrior

28

picwarrior wrote on Monday, December 28, 2015:

Bonjour Aminos,

Je m’intéresse à l’utilisation de FreeRTOS sur un PIC32MZ, en utilisant le C++.
En C, j’arrive très bien à utiliser FreeRTOS, mais le projet que je suis en train d’essayer de porter maintenant en C++ avec FreeRTOS ne compile pas du tout, à cause de FreeRTOS. J’ai déjà passé une journée entière à investiguer ce problème, notamment sur les forum Microchip et de FreeRTOS, et il semblerait que la solution réside dans l’utilisation d’rapper pour freeRTOS tel que FreeRTOS Extension Class.

Vous êtes une des rares personnes sur les forums à utiliser FreeRTOS Extension Class sur un PIC, alors je me permets de vous contacter à ce sujet.

Vous serait-il éventuellement possible de partager un projet exemple montrant comment utiliser FreeRTOS Extension Class sur un PIC ?
En retour, je pourrai vous faire bénéficier de mes résultats sur un PIC32MZ, si celà a de l’intérêt pour vous.

Ou bien, vous serait-il possible au moins de me conseiller sur la direction à explorer afin de réussir à compiler et faire tourner un projet en C++ en utilisant FreeRTOS sur un PIC32 ?

Bien cordialement,

PICwarrior

29

rtel wrote on Monday, December 28, 2015:

Generally, if you compile the FreeRTOS source code as C, and the
application code as C++, then it should work ok. Other than that there
are a few third party C++ wrappers for FreeRTOS, for example:
http://interactive.freertos.org/entries/223648-Using-FreeRTOS-with-C-

30

richard_damon wrote on Tuesday, December 29, 2015:

I have put up my wrappers at https://github.com/richard-damon/FreeRTOScpp

It is a simple C++ wrapper for FreeRTOS.