Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem



Posted by Preet Kang on March 30, 2010
I am using GNUARM 4.3.2 with Eclipse ARM Plugin. Free RTOS code fails to compile Does anyone know of some sort of a GCC compile flag to turn off this type of strict checking of data type and pointer type conversion? All the errors are related to assignment operator with type conversion:

arm-elf-g++ -Os -Wall -c -fmessage-length=0 -MMD -MP -MF"FreeRTOS/queue.d" -MT"FreeRTOS/queue.d" -mcpu=arm7tdmi -o"FreeRTOS/queue.o" "../FreeRTOS/queue.c"
../FreeRTOS/queue.c: In function 'long int xQueueGenericReceive(xQUEUE*, void*, portTickType, long int)':
../FreeRTOS/queue.c:856: error: invalid conversion from 'void*' to 'signed char*'
../FreeRTOS/queue.c:935: error: invalid conversion from 'void*' to 'void**'
../FreeRTOS/queue.c:935: error: initializing argument 1 of 'void vTaskPriorityInherit(void**)'
../FreeRTOS/queue.c: In function 'void prvCopyDataToQueue(xQUEUE*, const void*, long int)':
../FreeRTOS/queue.c:1058: error: invalid conversion from 'void*' to 'void**'
../FreeRTOS/queue.c:1058: error: initializing argument 1 of 'void vTaskPriorityDisinherit(void**)'

I tried to fix each error manually, however, those more errors appear and I don't want to fix all errors manually in case I want to upgrade the source code of FreeRTOS later. The same FreeRTOS code compiles just fine in Windows Visual Studio.


RE: G++

Posted by Richard Damon on March 31, 2010
Sounds like it is compiling the program as a C++ program instead of a C program. C++ does not allow void* to convert to other types automatically like C does.

RE: G++

Posted by Preet Kang on March 31, 2010
Yes, I'm using g++ as compiler since I want to compile for C++on purpose. Any easy way to resolve this, such as adding a compiler option to over-ride this type of C++ Checking?


RE: G++

Posted by Dave on March 31, 2010
FreeRTOS should be compatible with a C++ build provided you build the FreeRTOS files themselves as C files. They already contain extern "C" statements. Alternatively edit the code to remove the data hiding.

RE: G++

Posted by Richard Damon on March 31, 2010
As davedoors said, FreeRTOS is set up to be compiled as a C program, and is defined in a way that is can link to a C++ program without problems, as the headers are set up to handle that. It would be significant work to edit the files to let FreeRTOS to compile as a C++ program (and these mods would need to be redone on each new release).

The significant issues that need to be handled are that the type for pointers to the various structures that FreeRTOS uses are declared for user code to be void* but pointer to the appropriate structures in FreeRTOS code. This will cause linking errors if the FreeRTOS files are complied as C++ as the user will call a version using void* parameters, while the definition will be with struct xxx* parameters and not match up. I did ask Richard awhile back why he used void* instead of struct xxx*, with xxx being an incomplete type, as allowed by the C standard, and the reason was that for some of the targeted machines, the major available compiler didn't support that feature.

I have been meaning to ask Richard if he would be interested in a submission that would make a (simple) structural change that would allow ports to indicate if they support the incomplete type construct, and if so, use it to better type check parameters, this could also make it simpler to compile with C++ as all C++ compilers will support the incomplete type construct and at least most of the void* would go away (one place I can think of is the task parameter, as FreeRTOS does not know what it points to).

RE: G++

Posted by Preet Kang on March 31, 2010
I fiddled with this a lot today and came to a conclusion that Eclipse ARM Plugin has a bug. I was able to select in the eclipse IDE which folders to use gcc and which folders to use g++, however, somehow it adds -mthumb flag to the folders being compiled with gcc, which kinda breaks apart the whole thing.
I guess the solution to this problem is either go through to fix all the FreeRTOS and typecast each error statement or stick with C compiler. The reason why i wanted C++ is because I wanted my students to be able to have the option about how they compile. I also have to stick with Eclipse IDE since most students do not know about makefiles and building their own set will steal a few weeks of the semester.

I guess, I will go ahead and try to fix error-by-error, see how far I get, and make one template for FreeRTOS C++ Project that everyone can use.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.1 is available for immediate download. MIT licensed, includes 64-bit RISC-V, NXP Cortex-M33 demo, Nuvoton Cortex-M23 demo & STM32H745 dual core (AMP) demo.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers





STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner