Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

G++

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.

Preet

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?

Preet

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.

Preet


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




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists