whenever I generate my code with STM32cubeMX on Iar embedded workbench V8.5
this error is still present
Fatal Error [Pe035]: #error directive: "Unknown target."
The error is unrelated to either downloading or debugging. It is a build error.
The #error is a pre-processor directive in the code. If you double-click on one of those errors it will no doubt take you to the offending code. It is not possible from the image to direct you to the exact cause (you should post the "build Log" text in its entirety, rather then an image of the "build" tab), but will no doubt be code similar to (elided):
#if defined(STM32F405xx)
#include "stm32f405xx.h"
#elif defined(STM32F415xx)
#include "stm32f415xx.h"
#elif
...
#elif defined(STM32F423xx)
#include "stm32f423xx.h"
#else
#error "Unknown Target" <<<< HERE - no target macro has been defined.
#endif
The point being that the HAL code supports multiple STM32 variants and it is necessary to set a macro identifying your target so that the appropriate part specific code will be built.
If you created your project using STM32CubeMX or from the IAR IDE, there will be some place in the configuration where you can specify your target. (in the case of CubeMX I don't think you can do much of anything until you have selected the target). Failing that there will be some place to define command-line build macros in the build configuration.
Related
I have two version of code and I need to switch them as work need to compile each one while keeping two version on an IAR project. I find something like "compile switch" but I don't know how is it doing. Is there anyone tell me a keyword or an advice that can I search?
You can use C preprocessor #define feature to toggle between code versions and use IAR EWARM project's Defined Symbols feature to enable a list of #defines in a specific header file (for example: defines.h) that will be included in all C files.
defines.h
#if defined(PROD_VERSION)
#define SOFTWARE_VERSION_PRODUCT ("1.0-release")
//...whetever specific #defines meant for the release version, for example...
//#define ENABLE_RF_STUB
#define USE_SERIAL_CTS_RTS
#elif defined(TEST_VERSION)
#define SOFTWARE_VERSION_PRODUCT ("1.0-test")
//...whetever specific #defines meant for the test version, for example...
#define ENABLE_RF_STUB
#define USE_SERIAL_CTS_RTS
#elif defined(DEBUG_VERSION)
#define SOFTWARE_VERSION_PRODUCT ("1.0-debug")
//...whetever specific #defines meant for the debug version, for example...
#define ENABLE_RF_STUB
//#define USE_SERIAL_CTS_RTS
#endif
in rf.c
#include "defines.h"
void rfInit(void)
{
#ifndef ENABLE_RF_STUB
//init RF here
#endif
}
In serial.c
#include "defines.h"
CPU_BOOLEAN isCtsRts()
{
#ifdef USE_SERIAL_CTS_RTS
return HAL_SERIAL.isCtsRts();
#else
return DEF_TRUE; //bypass CtsRts check
#endif
}
In your project option > C/C++ Compiler > Preprocessor > Defined symbols: add PROD_VERSION if you want the release version, or add TEST_VERSION if you want the test version or add DEBUG_VERSION if you want the debug version.
You can only choose one of the three configurations above only as IAR will only compile one version via the project compilation. Unless you can create a batch build script to allow building all the three versions under different output files created with three different project setups.
IAR has a configuration in toolbar Project > Edit_Configuration
It makes you set version "switches" via set these tool and it is possible to set preprocessor command for each setup.
I am developing a C application, and using Eclipse CDT IDE, which I find great. The project uses Glib,Gtk,and GStreamer , so whenever I use some of their features in a file, I need to include:
#include <glib.h>
#include <gtk/gtk.h>
#include <gst/gst.h>
The code compiles without any error, since the PATH variable to search those headers is set correctly in a CMakeLists.txt.
However, while working on the project, I found annoying errors highlighting in my code, regarding type definitions like gchar or GValue or GTKApplication; the error outlined is "symbol **** could not be resolved". These definitions are inside a header file that my Eclipse IDE cannot find (included by glib.h), if not at compile time (indeed the program compiles correctly). Instead, the type GError , defined in gst.h , is not highlighted as an error by the pre-compiler.
I would like then that my Eclipse IDE could search on nested headers (#include inside an #inlcude inside...) to find those type definition, in order so to not have those annoying errors highlighting. How can I do so? I would not like to have to include directly all files where the type definitions are done.
EDIT: As Jonah Graham outlined, the problem is not beacuse Eclispe does a "single-step research" on the headers, since it inspects includes inside other includes like any other IDE. It is a CMake bug with c and Eclipse
Thanks in advance.
The problem you are facing is a CMake bug*. CMake adds __cplusplus into the defined symbols unconditionally, which means that glib headers are not parsed properly when in C mode. You can see this clearly by opening gmacros.h around the definition for G_BEGIN_DECLS:
Because CMake told CDT __cplusplus is defined, it thinks G_BEGIN_DECLS is also defined, which makes code like this from gtypes.h parse incorrectly:
G_BEGIN_DECLS
/* Provide type definitions for commonly used types.
* These are useful because a "gint8" can be adjusted
* to be 1 byte (8 bits) on all platforms. Similarly and
* more importantly, "gint32" can be adjusted to be
* 4 bytes (32 bits) on all platforms.
*/
typedef char gchar;
...
Of course with no gchar defined, everything else is going to go badly.
Luckily there is a quick workaround until the problem is resolved in CMake, remove __cplusplus from the info in CDT.
Open Project Properties
C/C++ Include Paths and Symbols
Remove __cplusplus from the list and press OK
(sometimes necessary) Right-click on project -> Index -> Rebuild
* There may be some other workarounds if you know CMake better. The bug says also it will be fixed for the next release of CMake.
I have a project comprised of several source modules and header files. Two of them (s1.c, s2.c) #include the same header file (s3.h). That header file contains conditional compilation construct, based on an externally defined macro:
#ifdef ExtMacro
#define IntMacro 1
#else
#define IntMacro 2
#endif
Now, ExtMacro is defined in s1.c before the #include "s3.h", but is not defined in s2.c.
When opening the header file in the Eclipse editor, the code is parsed for syntax highlighting, and the parts that are excluded from the build are highlighted in gray background.
As you can see, the excluded part of s3.h depends on the context of its inclusion. But Eclipse chooses one of the including modules for the purpose of highlighting the header code.
Is there a way to tell Eclipse to highlight the header code in one context or another?
If you add the header to the list at Preferences -> C/C++ -> Indexer -> "Index all variants of specific headers", then CDT will index both versions of the header.
When you then open the header by following the #include in s1.c, it will show you the version indexed in the context of s1.c. When you open it by following the #include in s2.c, it will show you the version indexed in the context of s2.c.
I don't know of a way to control which version is shown when you open the header without context (e.g. via the Project Explorer).
(Instead of adding the header to the "Index all variants of specific headers" list, you could also just check "Index all header variants". However, I don't recommend this, as it is likely to have an adverse impact of the performance of indexing your project.)
You can set ExtMacro as Symbol in Paths & Symbols. Then you create two build configurations, one where ExtMacro is defined and one where it is not. Then you set the indexer to re-index, when the configuration changes. With the switch of the configuration the indexer will show the correct context.
Then you likely need to exclude the fixed define in s1.c from the indexer. The Eclipse CDT parser generates a preprocessor symbol that you can trigger on and use:
#ifdef __CDT_PARSER__
#else
#define ExtMacro
#endif
This way the symbol ExtMacro is hidden for the CDT parser but not your real compiler and it only picks up the symbol from the build configuration.
I have a region of code in a seperate project that is wrapped in:
#IF MYNICEMONOTOUCHDEFINE
Some non-Monotouch C# code here
#ENDIF
The linker fails when we compile in DEBUG/SIMULATOR saying that that code is not found in monotouch basically.
The linker works fine and ignores that code when compiled to DEBUG|PHONE however.
Does the DEBUG/SIMULATOR build/linker not obey the #IF ? The IDE "ghosts" the code when in Debug|Phone mode, and un-ghosts when we switch to debug|simulator
I have a program that must be compiled only in DEBUG mode. (testing purpose)
How can I have the preprocessor prevent compilation in RELEASE mode?
Place anywhere:
#ifndef DEBUG
#error "Only Debug builds are supported"
#endif
For reference: Diagnostics
C provide a #error statement, and most compilers add a #warning statement. The gcc documentation recommends to quote the message.
Maybe something more sofisticated, but it is only copy&paste of previous solutions. :-)
#ifdef DEBUG
#pragma message ( "Debug configuration - OK" )
#elif RELEASE
#error "Release configuration - WRONG"
#else
#error "Unknown configuration - DEFINITELY WRONG"
#endif
P.S. There is also another way how to generate a warning.
Create an unreferenced label like
HereIsMyWarning:
and don't reference it. During compilation, you will get a warning like
1>..\Example.c(71) : warning C4102: 'HereIsMyWarning' : unreferenced label
You can use a error directive for that. The following code will throw an error at compile time if DEBUG is not defined:
#ifndef DEBUG
#error This is an error message
#endif
If you simply want to report an error:
#ifdef RELEASE
#error Release mode not allowed
#endif
will work with most compilers.
For GCC and Clang (and probably any compiler that supports the _Pragma feature) you can define a macro:
#if ! DEBUG
#define FIX_FOR_RELEASE(statement) _Pragma ("GCC error \"Must be fixed for release version\"")
#else
#define FIX_FOR_RELEASE(statement) statement
#endif
You can use this macro for temporary hacks, for example to get around code that a co-worker hasn't written yet, to make sure you don't forget to fix it once you want to release a build to the public. Either
FIX_FOR_RELEASE()
// Code that must be removed or fixed before you can release
or
FIX_FOR_RELEASE(statement that must be removed or fixed before you can release);
In Code::Blocks, if you don't want the Release mode, you can delete the Release mode. To do this, click on the Project menu, select Properties..., and in the Build targets tab you can click on Release and then click on the Delete button. Deleting the Release mode only does it for the current project, so you can still use it in other projects.
Otherwise, if you really want to use the preprocessor, you can do this:
#ifdef RELEASE
#error "You have to use the Debug mode"
#endif