I'm using Doxygen on a client's source code and Doxygen can't find a symbol UNS_32.
The client's code compiles without errors using the GNU ARM compiler.
I have searched the client's code base and can't find the definition of UNS_32.
I searched the GNU ARM source code tree and can't find it either.
So, where is the symbol UNS_32 defined?
*Note: I'm not looking for the meaning. I want the definition so I can put it in my Doxygen configuration file. *
Example usage:
void lpc_heap_init (void *base_addr, UNS_32 heap_size);
It is defined in lpc_types.h
http://code.google.com/p/32bitmicro/source/browse/trunk/src/nxp/lpc17xx/LPC1700CMSIS/Drivers/include/lpc_types.h?spec=svn226&r=226
/** SMA type for 32 bit unsigned value */
typedef uint32_t UNS_32;
You need also to search and headers in paths specified to the compiler with -I options. You can similarly specify these in Doxygen.
My preferred approach is to use Visual Studio, create a "Makefile Project", add the sources and copy all the project's command line defined macros and include paths to the project settings, then let the Intellisense simplify code navigation - it is a simple case of right-clicking the symbol, and selecting "Goto Definition", or using the "Code Definition" window which shows the defining source for any symbol you place the cursor on. You could even set up the project to actiually build the code too.
Related
I am trying to implement the use of DSP in the STM32 F411RE board, but I cannot seem to include the necessary files without invoking numerous errors.
Background
I have previously had CMSIS and CMSIS-DSP working in Keil uVision, but given the code limit of 32k that puts me over the evaluation limit rather quickly. As such I have been attempting to include CMSIS-DSP into Atollic TrueStudio but this seemingly is difficult to accomplish: there is limited documentation available on the CMSIS-DSP to begin with and even less so for implementation in Atollic TrueStudio.
Some related resources can be found in the
Atollic TrueStudio User Guide
as well as
StackOverflow topic #1
and
StackOverflow topic #2
. Most other related topics I could find just refer to the use of Keil uVision or the User Guide without much further help.
Atollic TrueStudio does incorporate a in-built package manager where the base CMSIS is available for download, but it does not provide this option for the CMSIS-DSP pack.
Attempted solution
I have attempted to manually download the corresponding CMSIS package (STM32Cube_FW_F4_V1.24.0) and place the corresponding DSP package into the project file structure. This then permits the use of the DSP functions such as
#include arm_math.h or arm_rfft_fast_instance_f32 S; which can also be invoked with the use of the autocomplete functionality and as such are thus recognized by the IDE.
However, this process also invokes many errors as the included functions fail to recognize their header dependencies (such as the #include arm_math.h). I find it confusing that the main.c is able to recognize the #include arm_math.h command yet the functions included are not, but I nevertheless try to fix this by adding the CMSIS DSP to the included directories (found at 'Build properties --> C/C++ Build --> Settings --> Tool Settings --> C Compiler --> Directories`). However, this does also not remedy the issue at hand.
Code results
The function cannot find the header
However the main can find the exact same header
And the header is included in the build options -> directories
Just verified that it is also included in the 'path and symbols', which it should do automagically AFAIK once you include it in the build options:
Update
Since my OP I have made some progress, mostly via messing around with the includes, symbols and linker. I have now managed to defeat the original error (though unfortunately I have no idea how), but I have now incurred a large amount of additional errors for the startup_stm32 files.
These all appear to be bad instruction errors referring to the template files included in CMSIS (CMSIS / Device / ST / STM32F4xx / Source / Templates / ARM / ...), which somehow cannot interpret the various commands listed in these templates.
Example errors: bad instruction __heap_base
I have since figured out the issue for my project: including the CMSIS folder as available from the Github repo means that a lot of templates are present throughout the entire folder structure. When attempting to build / compile whilst these templates are still present it causes a lot of issues with invalidated types and re-defining errors.
Most of these templates are in a logical location, but some are buried quite deep down and may thus be difficult to find. I will try to make a video soon describing the process of adding CMSIS (DSP) from the github repo to your project in TrueStudio.
In the meantime, the following steps should make CMSIS and CMSIS-DSP work in your STM32 TrueStudio ProjecT:
Ensure that all templates (folders) are removed from the CMSIS folder. This may require some searching and experimenting: the particularly noxious ones are hidden in
../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/Device/ST/STM32xxxx/Source/{Templates}
whilst there are also other sets at ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Examples} and ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Projects} that I had removed for my project to compile / build succesfully.
Include all the folders that are named include in the folders. AFAIK you cannot just include the main ../Drivers folder, as includes do not appear to also include the underlying structure and it also seems to include errors for my project. Best to just include the folders manually: you can so so by right-clicking on the intended folder to include, click the option near the bottom "Add/Remove include path" and tick both boxes for release and debug before pressing 'OK' to include this folder. Repeat for the other 'include' folders.
Fish up the RTE_Components.h file located at ../STM32Cube_FW_xx_Vx/STM32xxxx-Nucleo\Templates\MDK-ARM\RTE. There are also files with this name (RTE_Components.h) available in the NN (Neural Networks) CMSIS-pack folder, do not touch those. Copy this file to any location that you have previously included (placed mine in ../Drivers/CMSIS/Include), and open it up in your IDE of choice. Add the line #define CMSIS_device_header " DEVICE_NAME.h " before any of the other statements and replace device name with your STM32 board name. For example, my RTE_Components.h file looks like
/*
* Auto generated Run-Time-Environment Component Configuration File
* *** Do not modify ! ***
* Project: 'Project'
* Target: 'STM32F410Tx_Nucleo'
*/
#define CMSIS_device_header "stm32f4xx.h" // define own board header, eg stm32f4xx.h or stm32f7xx.h
#ifndef RTE_COMPONENTS_H
#define RTE_COMPONENTS_H
#endif /* RTE_COMPONENTS_H */
Make sure that the device name for the CMSIS_device_header corresponds to the header .h
file located in ../Drivers/CMSIS/Device/ST/DEVICE_NAME/Include/DEVICE_NAME.h
Add the required symbols (right-click your project, go to properties, C/C++ General, Paths and Symbols; then go to the #Symbols tab) to define the FPU and your Cortex Core type. For me I need to add __FPU_PRESENT (either with no value or value '1') and because I have the Cortex M4 chip on the STM32F411RE I add ARM_MATH_CM4. This means that my list of Symbols looks like:
__FPU_PRESENT
__packed with value __attribute__((__packed__))
__weak with value __attribute__((weak))
-ARM_MATH_CM4
STM32F411xE
USE_HAL_DRIVER though this depends if you want to use the HAL or not
Again make sure that the necessary includes are well defined, as not including only 1 directory can lead to a large amount of errors. These can be found by going to project properties (right-click your project, option at the bottom), going to the C/C++ Build, Settings, then the Tool Settings tab, C Compiler dropdown and to the Directories option.
For my project I have the following include path's inside the project properties:
../Inc (should be by default)
../Drivers/CMSIS/Device/ST/STM32F4xx/Include (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy (should be by default)
../Drivers/CMSIS/Include (should be by default)
"${workspace_loc:/${ProjName}/Drivers/Device/ST/STM32F4xx/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core_A/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/DSP/Include}"
Hopefully this helps and works for you too!
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.
This seems like a noob question, but all my searches return stuff about C++ or C# so I'm going to ask it here.
I have a DLL, SDL.dll, in the directory with my .c file. I want to import it to use.
using is not supported, #import doesn't work.
No directive in the source will help you, you can either
link to the DLL, use a so-called lib file for this. (This is a statically dynamic linking)
use LoadLibrary/FreeLibrary and GetProcAddress to map the addresses of functions to function pointers (true dynamic linking)
In the first case you also need an appropriate header file which matches the platform and version of the DLL used.
The second solution will work if you drop-in a newer version of the DLL as long as the prototypes of the functions used match.
This assumes you are under Windows, which is probably the case if you have a *.dll and not an *.so (shared object) file. (For Linux systems, you can include dlfcn.h and use dlopen/dlclose/dlsym instead of LoadLibrary/FreeLibrary/GetProcAddress with a slightly different syntax, check the doc)
this is quite possible assuming your DLL is in the correct form (the same standards as Windows API DLLs for example)
you need to declare you functions - perhaps in a header file, like this:
typedef void (CALLBACK *functionnameptr)(char *, int),
Then you use LoadLibrary to load the DLL, and provide a Handle to it:
handle = LoadLibrary("SDL.DLL");
Then you use GetProcAddress(handle,"real function name in DLL")
like this:
functionnameptr lptrfunction;
lptrfunction = GetProcAddress(handle,"real function name in DLL");
Now you can use the lptrfunction as you would normally use a function in C
Assuming you're using Visual Studio.
1.) Download http://www.libsdl.org/release/SDL-1.2.15.zip
2.) unzip and install to for example C:\SDL-1.2.15
3.) In Visual Studio open the properties of the project goto C++ general and add C:\SDL-1.2.15\include to "Additional include directories".
4.) Goto the "Linker" tab and add C:\SDL-1.2.15\lib\x86 to "Additional library directories".
5.) Now go to "Input" under the Linker tab and add SDL.lib; SDLmain.lib to "Additional dependencies"
6.) Go to the "Build Events" tab and "Post build event" and add copy /y C:\SDL-1.2.15\lib\x86\SDL.dll "$(OutDir)
That should do get your SDL working for Visual Studio in 32bit
On Linux if SDL is already installed just type "g++ -02 -o foo foo.cpp -lSDL"
I'm using eclipse to work on some c code and it is not indexing code inside conditional compilation blocks like this:
#ifdef USE_FEATURE_A
int feature_a(...) {
some = code(here);
}
#endif
How can I get eclipse to index the feature_a function?
You could tell eclipse that USE_FEATURE_A is defined. Open your project properties and go to the "C/C++ General->Paths and Symbols" page, under the "Symbols" tab click the "Add" button and put USE_FEATURE_A in the name feild and click OK.
Note: this will cause it not to index any #else sides to your preprocessor stuff... so unless they are all like the one in question you can't AFAIK, but if they are they you're good. (Eclipse contains a C preprocessor that it uses to analyize your code all the stuff above does is essentially the same as adding -DUSE_FEATURE_A to your command line so Eclipse's preprocessor will behave differently from the one in your compiler)
This is an easier and in my opinion more elegant solution to the one selected as the solution:
If someone has the same problem (as I had), this can (now?) easily be solved by going to Window->Preference->C/C++/Indexer and enable "Index all header variants".
Then click Project->C/C++ Indexer->rebuild and clean and build your project. This should resolve all error originating from preprocessor commands.
For what it's worth, getting eclipse to parse conditionally compiled code is much harder to do than would appear at first glance. I found a paper on by IBM from 2007 where they said they will prioritize for the "next release".
Handling Conditional Compilation in CDT's Core
I had this same problem, but the code conditionally eliminated by preprocessing was perfectly valid c code and I wanted it formatted... This was my solution:
1) Global find/replace of #if to #JUNKif
2) Ctrl-Shift-F to reformat the source
3) Another global find/replace of #JUNKif to #if
One way to index code under flag in Eclipse(Kepler) c/c++Editor.
You can enable the compilation flags in Eclipse editor so that code under them can be indexed.
Properties > Preprocessor Include Paths > CDT User settings Entries
Click on ADD and add the Preprocessor Macro and you can specify its value.
Best way I guess is to use the Indexer option : Project Properties>C/C++ General>Indexer.
You can choose Enable project specific settings
I prefer choosing "Use active build configuration" so that all files which are actually built in the project are indexed.
Anyhow you can also choose to index all files in the project even if they are not included in the build ...
I am working in existing C code which has a couple of lines with statements similar to this one:
struct collect_conn *tc = (struct collect_conn *)
((char *)c - offsetof(struct collect_conn, runicast_conn));
The struct collect_conn goes along the following lines:
struct collect_conn {
struct runicast_conn runicast_conn;
struct announcement announcement;
const struct collect_callbacks *cb;
struct ctimer t;
uint16_t rtmetric;
uint8_t forwarding;
uint8_t seqno;
};
I am using Eclipse CDT, and it marks the line with an orange squiggly line as 'syntax error'. I think it is marked as such by the CDT indexer.
However, compilation (manually in a terminal) is no problem.
This is a bit inconvenient however, since the elements on the line don't get indexed (so the call hierarchy tree isn't always correct, or the highlighting of elements, etc.)
Why does Ecipse not like the line as it is?
Eclipse CDT contains its own preprocessor/parser for analyzing your code and building an index. However, when you invoke a build CDT calls out to your system compiler, like gcc for example. There may be minor differences between the syntax accepted by the CDT parser and the syntax accepted by your compiler. When this happens the CDT parser can get confused.
On my system the offsetof macro expands into an expression that uses the __offsetof__ keyword. This keyword isn't recognized by CDT so that's why there's a syntax error. To deal with this problem the CDT parser has a macro built in to deal with __offsetof__ which looks like this:
#define __offsetof__(x) (x)
This doesn't appear to be correct, at least on my system the result is the removal of the __offsetof__ keyword from the source which still leads to a syntax error.
I was able to get rid of the syntax error by going to the Paths and Symbols property page and adding a macro for __offsetof__ which maps to 'foo'. This tricks the parser into thinking its just a call to a function it hasn't seen before, but not a syntax error.
Alternatively you can turn off syntax error reporting in the editor by going to Window > Preferences > General > Editors > Text Editors > Annotations and unchecking all the checkboxes for C/C++ Indexer Markers.
I've fixed problem in eclipse CDT with Preferences->C/C++->Language Mappings : Add
Content Type : C-header
Language : C++
Sometimes, although the code compiles with no error, eclipse CDT's real-time code analyzer shows some errors in C/C++ files (eg. 'Function xxx could not be resolved). This is because eclipse CDT uses its own preprocessor/parser for analyzing the code and building the indexes instead of the MinGW's one (or any other GNU compiler). In order to fix this globally for all eclipse projects in the workspace, follow these steps:
(In order to fix this only for a specific project, follow steps 1, 2 and 4 in menu 'Project->Preferences')
1-In menu 'Window->Preferences->C/C++->Language Mappings', add the correct mappings as shown in below: (eg. for content types: C++ Source/Header File, use GNU C++ language and so on)
2-In menu 'Window->Preferences->C/C++->Indexer', set full indexing by checking all checkboxes (but not 'Skip' ones) as shown in below:
3-In each project's specific properties, menu 'Project->Properties->C/C++ general->Indexer', Uncheck 'Enable project specific settings' as shown in below:
4-Rebuild the indexing, menu 'Project->C/C++ Index->Rebuild'.
It seems the CDT parser doesn't like the portion offsetof(struct ...).
If you declare collect_conn using a typedef the error goes away. At least for me, the following code works:
typedef struct {
struct runicast_conn runicast_conn;
struct announcement announcement;
const struct collect_callbacks *cb;
struct ctimer t;
uint16_t rtmetric;
uint8_t forwarding;
uint8_t seqno;
} collect_conn;
...
struct collect_conn *tc = (struct collect_conn *)
((char *)c - offsetof(collect_conn, runicast_conn));
If you can't change the original declaration do something like this:
typedef struct collect_conn collect_conn_t;
It might be confused, check if you have a definition of offsetof in-scope, for instance. Otherwise you might try simplifying the expression, breaking it up using e.g. a #define with the offset of, or something.
I'm thinking the compiler might provide a built-in version of offsetof, while Eclipses's compiler/code-parser might not. If so, you would need to make sure you have the definition, for Eclipse to be able to properly parse your code.
try switching the indexer to "Full c/C++ indexer (complete parse)" in Preferences->c/C++ -> indexer
Iv got the same problem. There is 2 definition of offsetof (one for C and one for C++). IMO the problem come from that
For example if i type
#ifndef __cplusplus
#endif
Eclipse will grey it. It mean __cplusplus is defined, but my project is a C
Unfortunatly i dont find a fix.
I fixed similar problem after checking the tab Error Parsers in Makefile Project in New CDT Project Wizard, removing CDT Visual C Error Parser (I am using gcc)
I ended up solving the problem like this. First I opened the project properties, then the C/C++ general->Paths and Symbols category. Under the Symbols tab I added this entry:
Symbol: offsetof(TYPE,MEMBER)
Value: ((ssize_t) &((TYPE *)0)->MEMBER)
These symbols are used by the indexer but not passed to the compiler (at least in Makefile projects, I haven't tried it in the other kind of C project), so it doesn't override GCC's built-in offsetof
I've seen Eclipse do this some times, and I use it for Java. Usually closing and opening the file again fixes it for me (resets whatever is wrong). It usually seems to be an error that WAS there but has been fixed and the "error cache" isn't updated correctly.