We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Building new firmware application using RTX Kernel and stm32f10x_lib.h generates error because library is not C++ compatible.
Development Board: STM3210E-EVAL OS: RTX Kernel Tools: uVision4
After creating a new uVision project for the STM3210E-EVAL board and a basic startup.cpp file a new compile-able project exits. Next, attempting to use the Keil STMicroelectronics include file and libraries causes compile errors. By specifiying the following in the startup.cpp file: “#include <stm32f10x_lib.h>” errors occur. They are:
C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h(55): error: #65: expected a ";" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h: typedef enum {FALSE = 0, TRUE = !FALSE} bool; C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h: ^ C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h(55): warning: #64-D: declaration does not declare anything C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h: typedef enum {FALSE = 0, TRUE = !FALSE} bool; C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h: ^ C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h(401): warning: #368-D: class "<unnamed>" defines no constructor to initialize the following: C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::CPUID" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: { C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: ^ C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h(467): warning: #368-D: class "<unnamed>" defines no constructor to initialize the following: C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::RESPCMD" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::RESP1" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::RESP2" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::RESP3" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::RESP4" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::DCOUNT" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::STA" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::FIFOCNT" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: { C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: ^ C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h(515): warning: #368-D: class "<unnamed>" defines no constructor to initialize the following: C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::CALIB" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: { C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: ^ C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: startup.cpp: 4 warnings, 1 error
Why are the libraries and header file not C++ compatible. It is only natural to assume that someone would use RTX Kernel and C++ files.
They are ST's libraries, so you need to ask ST - not Keil!
Did ST ever make any claim that they were C++ compatible?
Note that there is already a thread about this on the ST forum...
Since, the libraries are installed with uVision4 and they get copied to C:\Keil, one would assume that they go through a Keil 'filter' (someone takes a look at them before adding them to the uVision Install). However, you are right they are ST files.
What is the link to the thread in the ST Forum?
I don't think so - Keil just provide them "as is"
"What is the link to the thread in the ST Forum?"
I think it was this one (although it's actually about C99 rather than C++):
my.st.com/.../Flat.aspx
Sorry, but ST have really messed-up their forum - including unwieldy topic links like that!
The title of the thread is "Typedef bool C99 conflict in STM32F10x StdPeriph Lib V3.x.x" dated 4/20/2010 3:17 PM
It's annoying, yes, but the "fault" of ST in this case.
However, in RTL.h (definitely a Keil file) there's the function prototype:
extern int frename (const char *old, const char *new);
which causes a C++ compile error because of course "new" is a reserved keyword in C++.
CH ==
Do they claim that RTL.h is usable as C++ ?
Christopher, where did you find the
I've searched back to RLARM version 3.00 with no success. The only definition I can find is this
extern int frename (const char *oldname, const char *newname);
My apologies if I have remembered that wrongly. I just know that every time I reinstall the Keil distributed MDK, RTL and ST libraries, I have to fix the bool thing and fix this "new" problem. I always just change "new" to "newname", so I searched for "newname" in my current installation and that's where I found it.
When I have a moment, or the next time I have to fix this, I'll clarify.
Found it. It's in file_config.h:
extern BOOL fat_rename (const char *old, const char *new, IOB *fcb);
Apologies again for my slightly flaky memory. I don't know if the filesystem library claims any specific C++ compatibility to be fair, but I have not had any problems using it from C++ having changed this line, and having dealt with the usual extern "C" business.
Any clarification of the situation would be welcome.
Yes, that was true for older RLARM versions. In RLARM v4.05 this mistake has been corrected.
http://www.keil.com/update/rl-arm.asp
So it has. Thank you. In this case, could I put in a plea for the function prototypes to be surrounded in
#ifdef __cplusplus extern "C" { #endif // prototypes of functions with C linkage #ifdef __cplusplus } #endif
as has been done in RTL.h. Saves me having to do
extern "C" { #include "blob.h" }
around every #include that might itself #include "file_config.h" after an indefinite number of levels of nesting.