Using FreeRTOS with code which has a couple of C++ files

Error :

..\Middlewares\Third_Party\FreeRTOS\Source\tasks.c(2998): error:  #513: a value of type "void *" cannot be assigned to an entity of type "TCB_t *"
  		taskSELECT_HIGHEST_PRIORITY_TASK(); /*lint !e9079 void * is used as this macro is used with timers and co-routines too.  Alignment is known to be fine as the type of the pointer stored and retrieved is the same. */	

I’m using the STM32F767 nucleo-144 (cortexM-7) , when i added RTOS to my code which has a couple of C++ files i get the above errors (have just added one error of that kind in the description ) .
The problem is if i remove --cpp11 from Misc controls , my pre existing code will not compile as it is written in a way to compile with --cpp11 .

when i try to explicitly convert to (void *) i get errors which deal with the object file.

to add to the understanding of the error :
C enables implicit type conversions and C++ does not allow it hence the error with
–cpp11 enabled in Misc controls of the project.

i tried using the cortexM-4 : there seems to be the same problem , is there a workaround for this , to compile the RTOS code with --cpp11 enabled ?

You should compile .c and .cpp files with different compiler flags for instance -std=c11 for C-files and -std=c++11 for C++ files if using GCC.

I’m using keil MDK5.36v with ARM compiler .

Ok. Then just the flags might be named differently.

Yup tried compiling them with different flags for C and C++
Ended up getting the error #65 : expected a ‘;’ - in the RTOS code (.c file)

Seems there is still a mistake in your build setup / compiler flags you have to sort out…
Compare the complete compiler invocations for both kind of files that it matches your expectations.
Or maybe the code where the error occurs gives you a hint what you missed.
I guess you didn’t patch the FreeRTOS files and accidentally introduced a problem e.g. including a C++header file in FreeRTOS C-code.


i get the same errors even when i add it thru the “Manage run-time environment”
where the RTOS code is locked .

Ended up explicitly converting all the pointers which gave errors : it has compiled with zero errors for now .